Apologies in advance for a message not about WPAD. I found this mildly
entertaining.
I went to fetch the new HTTP/1.1 RFC (2616) using one of my favorite
Web clients called 'wget'. It kept doing this:
5050K -> .......... .......... .......... .......... ..........
5100K -> ..
18:11:40 (19.95K/s) - Connection closed at byte 5224761. Retrying.
--18:11:40-- http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2616.ps
(try: 4) => `rfc2616.ps'
Connecting to kitty:3128... connected!
HTTP proxy request sent, fetching headers... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 done.
Length: 5,529,857 [application/postscript]
0K -> .......... .......... .......... .......... ..........
This repeated a number of times.
As you can can probably guess, the request goes through a Squid cache.
I initially suspected some Squid bug or setting that limits large
downloads.
However, just a little investigation showed that the reply header's
content-length (5,529,857) does not match the actual content length
(5,224,761). Its short by about 305,096 bytes. Of course 'wget'
believed the transfer got cut off and so it kept trying to get the
whole thing.
So, 305,096 is very close to the number of LINES in the file. The ISI
HTTP server (GN/2.14) must be stripping CR characters from each line,
but using the on-disk file size for the content-length.
I just had to laugh when I realized this was happening on the document
that defines what Content-length means in an HTTP response.
I suspect that many (most?) caching products will not cache this rather
large file (and others) from the ISI server because the content length
is wrong.
Can we get the GN server listed in John's Known Problems draft?
Or, can we get it fixed at ISI??
Duane W.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST