OWB and gzip doesn't work

I noticed a bug in OWB when visiting this page: www.turnetransport.se

In IB (which doesn't request gzip data) it displays fine but OWB only displays binary garbage, no page at all and it is because OWB announces that it can handle gzip (Accept-Encoding: deflate, gzip) but it obviously can't handle it when it gets it (Content-Encoding: , gzip, gzip) but displays raw binary instead.

Edit: This is OWB 3.23 for OS4.

@Deniil

The page works with AWeb ( the relavence being that AWeb <b>does</b> support gzip encoding) so looks like it's a bug in OWB not the webpage...

@broadblues

here are the returned headers:

The headers returned are the same for IBrowse 2.4 too, which does have gzip encoding support (unless disabled in the prefs).

@broadblues

The headers with OWB are slightly different since it also requests deflate:





Could it be this string: Content-Encoding: , gzip, gzip
starting with a comma that is confusing OWB? Or can it simply not handle gzip data properly?

@Deniil

Maybe it confuses it indeed (or CURL), because OWB certainly handles other gzipped pages.

@Deniil

Yes, it is a server bug. It looks like the server has double gzipped the content for some reason, so when OWB unzipped the result is still a gzip stream. Probably the server does not recognise "deflate" because...

FYI, IBrowse normally sends:

Accept-Encoding: gzip, deflate

and receives:

Content-Encoding: gzip

But, after changing IBrowse to send:

Accept-Encoding: deflate, gzip

just like OWB does, then IBrowse encounters the same problem:

Content-Encoding: , gzip, gzip

Along with binary jibberish being displayed.

@Futaura

Quote:

...the spec was not implemented as intended by certain web server software, leading to nobody really knowing what they ought to be sending or receiving when it is specified?

@Chris

Oh, I dunno... the RFCs are actually pretty clear on this. Although I remember cases of servers sending gzip encoded data anyway, even when the client did not say it could support that, but that's something different obviously.

I doubt Apache itself is at fault in this case, and it's most likely a site specific mis-configuration of Apache, it's modules and/or a PHP script issue that is causing the Content-Encoding header to get mangled. Can't really blame OWB just because it is sending the accepted encodings in a different order than "expected" by the site - in theory clients are allowed to use whatever ordering they want.

@Futaura

Apache is probably behaving correctly wrt defalte encoding, it was our friends at Microsoft who misinterpreted the spec and IIRC treated deflate the same as gzip (deflate should be gzip data without the gzip header). As such, deflate is not to be trusted and accept-encoding: deflate is horribly unpredictable.

OWB is sending the right headers, the server will be probably using the first in the list it can handle - ie. "deflate" (with no weighting on them I have a feeling the server can choose, but if not the first will be used).

I'd be interested to see if Accept-encoding: deflate only (no gzip at all) also causes the server to return the dodgy encoding which, as you say, is most likely set by a PHP script or module.

@Chris

Just tried with "Accept-Encoding: deflate" and the server returned uncompressed text. Although it also returned an empty "Content-Encoding: " header - don't think that is quite right either.