> From: Thierry Agassis [SMTP:thierry.agassis@pub.unicible.ch]
>
> 32: d0f3 0050 82ed 0e4b 763e 8270 7911 5010
> ...P...Kv>.py.P.
> 48: 8000 cb43 0000 4854 5450 2f31 2e31 2032 ...C..HTTP/1.1
>
This is an HTTP 1.1 server, so one would expect it to
give valid contents lengths.
> 144: 2031 323a 3239 3a32 3220 474d 540d 0a43 12:29:22
> GMT..C
> 160: 6f6e 6e65 6374 696f 6e3a 2063 6c6f 7365 onnection:
> close
>
Persistent connections are rejected.
> 224: 0a43 6f6e 7465 6e74 2d4c 656e 6774 683a
> .Content-Length:
> 240: 2030 0d0a 4c61 7374 2d4d 6f64 6966 6965 0..Last-Modifie
>
The contents length is zero.
> 304: 2d47 6f2d 5765 6273 6572 7665 722f 342e
> -Go-Webserver/4.
> 320: 362e 322e 360d 0a0d 0a0a 093c 4854 4d4c 6.2.6......<HTML
>
>
The end of zero bytes of data has been reached. It is
actually followed by gibberish, because we have not been
permitted to pipeline another request, but the fact
remains that the data transmission is complete, according
to the protocol.
> 0.05045 proxy1.domain.ch -> www.europe.ibm.com TCP D=80 S=33517 Fin
> Ack=2
>
As, all of the zero bytes of data have been returned, and
we are not allowed to make another request on the connection,
we close the connection.
In particular, draft 05 of the HTTP 1.1 specification says
"Any Content-Length greater than or equal to zero is a valid
value".
Solution: Fix the web server to comply with the protocol
(specifically, either chunk the output or don't send a
Content-Length at all if the content length is not known
when the header is transmitted.
Received on Tue Nov 09 1999 - 09:10:30 MST
This archive was generated by hypermail pre-2.1.9 : Wed Apr 09 2008 - 11:57:32 MDT