The RFC is very clear on this point; closing the connection is a perfectly
valid way to signal that they payload is done; and the Content-Length is
really rather optional.
I've worked around this problem in the past (but then from a gateway
-man-in-the-middle- perspective) because of stupid (Siemens/Nokkia and
early unwired-planet) http->[smpp/dpu] wap gateways; and simply hacked
the proxy to always ignore the cache,to spool to disk and then resend from
there once you have the whole file. Given the very slow speed (at least in
europe) of WAP of SMS though smpp there was no perceptable speed penalty
:-) :-) The gateways had similar problem with MIME style content; i.e.
where you had a Boundary/-- sort of termination. One even would prefix any
part of the header which was over 4k to the body :-)
Dw
On Tue, 8 May 2001, Bill Stoddard wrote:
> Is it reasonable for a client that claims to support HTTP/1.0 to -require- a content
>length header
> on all responses? The client I am working with will discard a response if it does
>not have a
> content-length header. This doesn't sound reasonable to me as the server can signal
>the end of the
> response by closing the connection. Looking for the definitive answer before I tell
>the client
> maker to fix their code.
>
> Humm..... the client is a wireless device which brings up other issues that can
>muddy the picture,
> specifically issues with starting and maintaining TCP connections to wireless
>devices. Looking for
> brain food here :-)
>
> Bill
>
>
