"Andrew M. Bishop" wrote:
> 
> "Paul A. Rombouts" <[EMAIL PROTECTED]> writes:
> 
> > Andrew M. Bishop wrote (subject was: Re: Bug#140617: wwwoffle: zlib problem with
> > groups.yahoo.com):
> >
> > > We have discussed before on this list servers that cannot send
> > > correctly compressed data using the deflate method.  It does seem
> > > problematic for some people.
> >
> >
> > I've had a problem with the website abcnews.go.com that also turned to be
> > deflate-compression related.
> > When I use Mozilla the site displays OK, but the Internet Explorer users on my
> > LAN got a blank page.
> 
> WWWOFFLE should detect that it cannot inflate the data it gets back
> from the server and send an appropriate error message, not a blank page.

Well I agree that's what WWWOFFLE *should* do, but that's not what happens.
WWWOFFLE sends the headers of the reply back to the browser, but no content. The
only way I can tell what has gone wrong is to look at the syslog (or run
WWWOFFLE under debug mode).
It's not so easy to fix this, in my opinion, because by the time WWWOFFLE has
detected a problem with inflating the content, it has already sent the reply
headers to the browser, so it's too late to send an appropriate HTTP response
code. But it should be possible to delay sending the reply headers until the
first chunk of data from the remote server has been successfully read and
decompressed. This gives you the possibility of sending an informative error
message to the browser, with an appropriate HTTP response code, in case
something goes wrong.
I've noticed that WWWOFFLE does store an error message in the cache, but you
don't get to see that error message when you request the same page again unless
WWWOFFLE is offline, and I'm not offline very often (I'm connected to the
internet via cable modem).

> > It turns out the server recognizes Mozilla by the User-Agent string and avoids
> > sending compressed data in that case. It does "deflate" the content for
> > other browsers, but WWWOFFLE can't "inflate" it.
> 
> What does Internet Explorer ask for and what does the site send if
> WWWOFFLE is not used?

OK, this is the request of Internet Explorer 5.5 (without using a proxy):

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
 application/vnd.ms-excel, application/msword, */*
Accept-Language: nl,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; T312461)
Host: abcnews.go.com
Connection: Keep-Alive


By the way, isn't it ironic that Internet Explorer identifies itself as
"Mozilla/4.0"?
This is the header of the response:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Set-Cookie: SWID=2481AFA9-5A69-4892-9E0D-B699F717BE7A; path=/; expires=Wed,
03-Jul-2022 18:50:17 GMT; domain=.go.com;
Cache-Expires: Wed, 03 Jul 2002 18:51:45 GMT
Cache-Control: max-age=300
Date: Wed, 03 Jul 2002 18:50:17 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 03 Jul 2002 18:46:45 GMT
ETag: "f857bcfac122c21:953"
Vary: Accept-Encoding, User-Agent
Content-Encoding: deflate
Warning: 214 abcnews.go.com "Redline Networks Densitron active"
Transfer-Encoding: chunked
Via: 1.1 abcnews.go.com (Redline Networks Accelerator 2.0.7A3)


Here's a hex dump of the first 64 bytes of the content:

0001151 33 32 36 43 0d 0a ed 7d 7b 57 e2 c8 16 ef df ed
0001171 5a fd 1d aa 33 6b 14 8f f2 56 7c 62 2f 04 54 66
0001211 14 3c 80 ed f4 9c 7b 16 2b 40 80 4c 07 c2 24 41
0001231 db 99 d3 1f e8 7e cb fb db 55 95 a4 02 41 d1 ee

I can't judge if this a valid deflate header. I'm not in the mood to spend time
studying compression methods in detail right now.

> > Can someone give me an example of a site that deflates its content correctly, so
> > that WWWOFFLE can inflate it?
> > Maybe it sounds a bit cynical, but up to now I have only seen examples to the
> > contrary.
> 
> Me too.
> 
> I blame Mozilla for this state of affairs.  They have been asking for
> deflated content, but have not been able to inflate it when they get
> it back.  (This is Mozilla bug number 105292, it was certainly still
> there in version 0.9.8).

I've had a look at bugzilla.mozilla.org. Judging by what I read there, the bug
still hasn't been fixed.
The target milestone is "mozilla 1.2alpha" so it doesn't seem the bug will be
resolved very soon.
I've checked the request header that Mozilla 1.0 uses. It still contains 
"Accept-Encoding: gzip, deflate, compress;q=0.9".
You'd expect that they would simply use "Accept-Encoding: gzip" until they get
decompression working for all three methods.
Of course the source code of mozilla is freely available, so it shouldn't be too
difficult to change the "Accept-Encoding" line yourself, if only it didn't take
ages to compile mozilla...

> If the server is trying to work around this
> problem then it should still send gzipped data, since it knows that
> Mozilla can handle that.

I agree totally.
 
> On the other hand if Internet Explorer asks for deflated content and
> they can inflate it while WWWOFFLE cannot then I blame Microsoft.
> 
> I have examined the data that comes back from some of these servers
> and I cannot see a deflate header in it.  I have implemented in
> WWWOFFLE the deflate/inflate method that is described in the HTTP RFC
> documents.  If anybody thinks that Microsoft or the server is correct
> and I am wrong then please tell me why.

I'm afraid I can't comment on this at this stage.


-- 
Paul A. Rombouts <[EMAIL PROTECTED]>
Vincent van Goghlaan 27
5246 GA  Rosmalen
Netherlands

Reply via email to