HTTP Protocol question

[Bill Stoddard <bi...@wstoddard.com>]

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

Re: HTTP Protocol question

["Roy T. Fielding" <fi...@ebuilt.com>]

On Tue, May 08, 2001 at 01:42:54PM -0400, 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.

A client can't claim to implement all of HTTP/1.0 (or HTTP/1.1) unless they
allow response messages without a content-length to be used.  However, it is
not unusual for a wireless device network to allow only a subset of HTTP/1.x
(which they can do because they are not on the Internet) and enable that
subset via gateway/proxy devices.

> 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 :-)

Most wireless devices (excluding 802.11b) do not use plain TCP.  Likewise,
HTTP is not restricted to plain TCP.  The best way to handle this is to use
some sort of multiplexing session protocol like SCP or MUX as the transport
for HTTP (just like SSL is a transport for HTTP).  In any case, such a
network requires a proxy/gateway between it and the real Internet.  If they
don't have that, then the device must play by Internet rules.

....Roy

Re: HTTP Protocol question

[James Sutherland <ja...@cam.ac.uk>]

On Tue, 8 May 2001, Jim Winstead wrote:
> On Wed, May 09, 2001 at 06:27:49AM +0100, James Sutherland wrote:
> > Particularly if the thin client is intended to be used with their own ISP
> > only, talking via their proxy server? They are clearly violating the RFC
> > here, but it may not matter in this case - for that matter, it could even
> > be deliberate? (Unlikely, I suspect, but possible...)
>
> i would assume it is deliberate. that doesn't mean they can claim
> that their client supports http/1.0 when it doesn't.

"Never ascribe to maliciousness that which can adequately be explained by
stupidity" :-)

I'd call it an HTTP/1.0 implementation with a very nasty bug: I haven't
read the 1.0 RFC recently, but I doubt it says anywhere "all clients are
REQUIRED to be completely bug-free" - I'm sure if we looked hard enough,
there are still cases where the httpd responds incorrectly in some way...

> they can certainly claim it supports a subset of http/1.0. or a
> protocol that is kind-of-but-not-quite-http/1.0. but someone (hi
> roy) bothered to write down the standard for a reason. :)

Yep - it's a nasty bug they should fix pronto, but unless/until there's
more "evidence", I wouldn't go thinking it's a malicious bug...


James.
-- 
The difference between Microsoft and 'Jurassic Parc':
In one, a mad businessman makes a lot of money with beasts that should be
extinct.
The other is a film.

Re: HTTP Protocol question

[Jim Winstead <ji...@trainedmonkey.com>]

On Wed, May 09, 2001 at 06:27:49AM +0100, James Sutherland wrote:
> Particularly if the thin client is intended to be used with their own ISP
> only, talking via their proxy server? They are clearly violating the RFC
> here, but it may not matter in this case - for that matter, it could even
> be deliberate? (Unlikely, I suspect, but possible...)

i would assume it is deliberate. that doesn't mean they can claim
that their client supports http/1.0 when it doesn't.

they can certainly claim it supports a subset of http/1.0. or a
protocol that is kind-of-but-not-quite-http/1.0. but someone (hi
roy) bothered to write down the standard for a reason. :)

jim

Re: HTTP Protocol question

[James Sutherland <ja...@cam.ac.uk>]

On Tue, 8 May 2001, Jim Winstead wrote:

> On Tue, May 08, 2001 at 01:42:54PM -0400, 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.
>
> well, rfc1945 makes it fairly clear that content-length is
> optional for responses, and section 7.2.2 confirms that dropping
> the connection is a valid way to signal the end of the response
> in the absence of content-length. the http/1.1 specs make this
> even more clear, of course.
>
> anyone requiring content-length on responses is going to be sorely
> disappointed in the number of websites they can actually visit.
> for example, amazon.com, yahoo.com, and ibm.com all don't send
> content-length. (of course, a wireless device may not be expected
> to talk to 'normal' websites.)

Particularly if the thin client is intended to be used with their own ISP
only, talking via their proxy server? They are clearly violating the RFC
here, but it may not matter in this case - for that matter, it could even
be deliberate? (Unlikely, I suspect, but possible...)

-- 
The difference between Microsoft and 'Jurassic Parc':
In one, a mad businessman makes a lot of money with beasts that should be
extinct.
The other is a film.

Re: HTTP Protocol question

[Jim Winstead <ji...@trainedmonkey.com>]

On Tue, May 08, 2001 at 01:42:54PM -0400, 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.

well, rfc1945 makes it fairly clear that content-length is
optional for responses, and section 7.2.2 confirms that dropping
the connection is a valid way to signal the end of the response
in the absence of content-length. the http/1.1 specs make this
even more clear, of course.

anyone requiring content-length on responses is going to be sorely
disappointed in the number of websites they can actually visit.
for example, amazon.com, yahoo.com, and ibm.com all don't send
content-length. (of course, a wireless device may not be expected
to talk to 'normal' websites.)

jim

Re: HTTP Protocol question

[Dirk-Willem van Gulik <di...@COVALENT.NET>]

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
>
>

Re: HTTP Protocol question

[Chuck Murcko <ch...@topsail.org>]

The wireless device should make no difference if the drivers are working 
properly, though you could see the odd link failure on long hops.

RFC 1945 says

For response messages, whether or not an entity body is included with
    a message is dependent on both the request method and the response
    code. All responses to the HEAD request method must not include a
    body, even though the presence of entity header fields may lead one
    to believe they do. All 1xx (informational), 204 (no content), and
    304 (not modified) responses must not include a body. All other
    responses must include an entity body or a Content-Length header
    field defined with a value of zero (0).

On Tuesday, May 8, 2001, at 01:42 PM, 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
>
>

Chuck Murcko
Topsail Group
http://www.topsail.org/