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.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
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:
Futaura wrote: Probably the server does not recognise "deflate" because...
...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?
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.
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.
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.