MyBB Community Forums

Thank you for your bug report.

This bug has been fixed in our internal code repository. Please note that the problem will not be fixed here until these forums are updated.

I'm still suspicious of the clear_overflow function, which is being called from within a loop. You can't echo gzencode'd data in chunks like that - you have to gzencode it all at once.

(2008-08-10, 08:55 AM)ZiNgA BuRgA Wrote: [ -> ]I'm still suspicious of the clear_overflow function, which is being called from within a loop. You can't echo gzencode'd data in chunks like that - you have to gzencode it all at once.

Nope. I've successfully downloaded, with my Content-Encoding fix a 400 MB download which was extracted 100% in both IE 7 and Fx 3.

Yes, the download size and the size of a backup saved into the backups/ directory will indeed be different but that's because we use gzencode for downloads and gzwrite for saving to the backups directory.

The backups/ directory download is smaller because we use w9 compression (the highest level of compression) but we use the default level for downloads because we don't want to make it too slow.

(2008-08-10, 04:39 PM)Ryan Gordon Wrote: [ -> ]

(2008-08-10, 08:55 AM)ZiNgA BuRgA Wrote: [ -> ]I'm still suspicious of the clear_overflow function, which is being called from within a loop. You can't echo gzencode'd data in chunks like that - you have to gzencode it all at once.

Nope. I've successfully downloaded, with my Content-Encoding fix a 400 MB download which was extracted 100% in both IE 7 and Fx 3.

Yes, the download size and the size of a backup saved into the backups/ directory will indeed be different but that's because we use gzencode for downloads and gzwrite for saving to the backups directory.

The backups/ directory download is smaller because we use w9 compression (the highest level of compression) but we use the default level for downloads because we don't want to make it too slow.

No, I'm not referring to size. I'm referring to the fact that it's "illegal" to keep gzencoding data, since gzencode chucks in a 10 byte GZ header and a 4 byte CRC at the end (from memory), and from my work with zlib/gzip, I know this isn't proper (it's why you need to use stream processing in C to gzip/deflate data).
If you keep echo'ing gzencode, you're going to get an initial chunk which will be the gz file. After that, the browser *should* ignore the rest of the data (either that, or the gz inflater should) since it's receiving illegal data.

Maybe Firefox 3 tries to fix this, but I'm doubtful whether all browsers support this.

Also, with sending a Content-Encoding: gzip header, this may cause the browser to inflate the data before giving it to the user. From memory, Firefox doesn't do it, but others do (had a problem with mod_deflate compressing attachments, so I know).

My latest figures are:



What do you want to do about the path to the file being wrong?

I already fixed the path being wrong for 1.4.1

(2008-08-12, 07:09 AM)ZiNgA BuRgA Wrote: [ -> ]

(2008-08-10, 04:39 PM)Ryan Gordon Wrote: [ -> ]

(2008-08-10, 08:55 AM)ZiNgA BuRgA Wrote: [ -> ]I'm still suspicious of the clear_overflow function, which is being called from within a loop. You can't echo gzencode'd data in chunks like that - you have to gzencode it all at once.

Nope. I've successfully downloaded, with my Content-Encoding fix a 400 MB download which was extracted 100% in both IE 7 and Fx 3.

Yes, the download size and the size of a backup saved into the backups/ directory will indeed be different but that's because we use gzencode for downloads and gzwrite for saving to the backups directory.

The backups/ directory download is smaller because we use w9 compression (the highest level of compression) but we use the default level for downloads because we don't want to make it too slow.

No, I'm not referring to size. I'm referring to the fact that it's "illegal" to keep gzencoding data, since gzencode chucks in a 10 byte GZ header and a 4 byte CRC at the end (from memory), and from my work with zlib/gzip, I know this isn't proper (it's why you need to use stream processing in C to gzip/deflate data).
If you keep echo'ing gzencode, you're going to get an initial chunk which will be the gz file. After that, the browser *should* ignore the rest of the data (either that, or the gz inflater should) since it's receiving illegal data.

Maybe Firefox 3 tries to fix this, but I'm doubtful whether all browsers support this.

Also, with sending a Content-Encoding: gzip header, this may cause the browser to inflate the data before giving it to the user. From memory, Firefox doesn't do it, but others do (had a problem with mod_deflate compressing attachments, so I know).

Well it seems to work just fine

(2008-08-12, 02:36 PM)Ryan Gordon Wrote: [ -> ]I already fixed the path being wrong for 1.4.1

Thanks.

My latest 1.2 version forums also stopped working as far as the database backup goes with my firefox 3.0.1, in fact I have never been able to download zip files for mybb upgrades with FF, instead having to use MSIE. MSIE still backsup and does a save file as far as the DB goes, so if you can login to your admin forums with msie and download and save the file that still works. I know that about 1.2.12 was still working, not sure what problems changed though.

Thanks. This thread is all about making it work with FF as well as IE which it now does.