"Paul A. Rombouts" <[EMAIL PROTECTED]> writes:
> "Andrew M. Bishop" wrote:
> >
> > "Paul A. Rombouts" <[EMAIL PROTECTED]> writes:
> >
> > > 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).
I thought that WWWOFFLE did send an error message to the user, but it
only stores it in the cache (as you mention below). The same
behaviour is presented to the user as when there is a timeout; the
data stream just stops.
> 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.
Yes, this should be possible but would require some re-organisation of
the program.
> 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).
> > 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
> 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.
I am very interested to see that the first six characters of the reply
data look like a DOS format line, terminated with CR, LF.
326C^M^J
I don't know if it means anything or is just coincidence.
In RFC 2616 (HTTP/1.1) the deflate content encoding is defined as:
-------------------- RFC 2616 --------------------
deflate
The "zlib" format defined in RFC 1950 [31] in combination with
the "deflate" compression mechanism described in RFC 1951 [29].
-------------------- RFC 2616 --------------------
The deflate compression method is defined in RFC 1951 and the zlib
format in RFC 1950 defines the header and checksum to use for deflate
compressed data. The first byte is defined as:
-------------------- RFC 1950 --------------------
CMF (Compression Method and flags)
This byte is divided into a 4-bit compression method and a 4-
bit information field depending on the compression method.
bits 0 to 3 CM Compression method
bits 4 to 7 CINFO Compression info
CM (Compression method)
This identifies the compression method used in the file. CM = 8
denotes the "deflate" compression method with a window size up
to 32K. This is the method used by gzip and PNG (see
references [1] and [2] in Chapter 3, below, for the reference
documents). CM = 15 is reserved. It might be used in a future
version of this specification to indicate the presence of an
extra field before the compressed data.
CINFO (Compression info)
For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
size, minus eight (CINFO=7 indicates a 32K window size). Values
of CINFO above 7 are not allowed in this version of the
specification. CINFO is not defined in this specification for
CM not equal to 8.
-------------------- RFC 1950 --------------------
The value of CM must be 8 for deflate and the value of CINFO depends
on the compression, but 7 indicates maximum compression. The first
byte of the zlib/deflate data stream is therefore 0x78.
The first bytes of a gzip data stream are defined in RFC 1952 and are
always 0x1f, 0x8b.
> > 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...
I don't know why the Mozilla people can't just apply this workaround
themselves rather than polluting the internet with claims that they
can handle deflate when they can't.
The interesting thing to see will be whether the deflate that they do
handle when they fix the problem is the same as the one that WWWOFFLE
handles.
--
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop [EMAIL PROTECTED]
http://www.gedanken.demon.co.uk/
WWWOFFLE users page:
http://www.gedanken.demon.co.uk/wwwoffle/version-2.7/user.html
