- From: Niklas Wiberg <e95_nwi@it.kth.se>
- Date: Fri, 24 Mar 2000 14:35:02 +0100
- To: www-jigsaw@w3.org
Roland Mainz wrote: > Nope, don't kill the owner. The "Server:" line contains the source of the > problem. Filing a bug report woud be usefull...or suggest the site admin/owner to > use jigsaw or at least apache :-) It seems as if it's some custom dll that is serving the response. The server ought to do some sanity-checking though (One would think it should catch the "=" at least...) However, I have another page with problems through Jigsaw (proxy) and which works fine without Jigsaw. It's the pictures on http://www.celocom.se/web/celo/d.asp These too work fine with direct client<-->webserver connection. When using Jigsaw as a proxy, the client sometimes get a 504 (An HTTP error occured while getting...) and sometimes a broken picture (you know what I mean). The Jigsaw<-->Webserver request-response for one of the pics, looks fine to me. The server responds with both Content-Length and "Transfer-Encoding: chunked" though, but as far as I understand from RFC2616 section 4.4, the Content-Length should be ignored (by Jigsaw in this case) when a message contains both these headers. However, the connection does not seem to be closed even though all chunks seems to be served... The Client<-->Jigsaw response looks as if Jigsaw serves the first chunk from the webserver response but without any Transfer-Encoding. The response looks something like this: HTTP/1.1 200 OK Cache-Control: private Proxy-Connection: keep-alive Date: Fri, 24 Mar 2000 11:58:15 GMT Via: 1.1 hippo:8001 (Jigsaw/2.0.4) Content-Length: 59771 Content-Type: image/gif Server: Microsoft-IIS/4.0 Content-Disposition: filename=293.gif 2710 GIF89aw..... It shouldn't be chunked of course since Netscape emits 1.0 requests. Is it possible that Jigsaw misinterprets the chunked encoding from the server? Sorry for writing half a book each time i post... Best regards Niklas Wiberg
Received on Friday, 24 March 2000 08:39:16 UTC