Subject: Re: A question about Content-Length header

From: "Peter" <[email-masked]>
Date: Sat, 24 Jan 2009 16:12:51 -0800

Hi, Adrien.

I think that what you meant by "in practise" is the *usual* practises in web 
domain where browsers and web servers can send messages of arbitrary media 
types while sometimes they specify the wrong media type.

My application is within a well-defined service-oriented architecture (and 
protocol) -- the TR-69 framework.

In TR-69 domain, messages are text-based SOAP envelopes carried in HTTP 1.1 
messages. The messages are always of text/html type and normally 
syntactically terminated by </soap:Envelope> tag.

If you would argue with "what if the soap msg has syntax errors or the end 
tag got lost?", i would say it is the same situation as "what if a http msg 
has a Content-Length header with incorrect msg body length?".

In any situation, the receiver should be able to recover from error input.

Thanks again for your response.

peter

----- Original Message ----- 
From: "Adrien de Croy" <[email-masked]>
To: "Peter" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 23, 2009 4:12 PM
Subject: Re: A question about Content-Length header

>
> in practise - i.e. in the real world, interoperability I believe will go
> rapidly down-hill if you don't use Content-Length. Some proxies and
> servers may support chunked requests from clients. My feeling is that
> very few servers or proxies will accept a multipart/byteranges request
> with neither chunking nor Content-Length.
>
> RFC2616 section 4.4 isn't specific about which methods are acceptable
> for request or response messages.
>
> However in the case of multipart/byteranges, the implication is that
> this is a response to a request message that had a Range header. Range
> is defined as a request header.
>
> Section 8.2.2 only mentions 2 methods of sending a request body.
>
> The reason chunking was added to HTTP/1.1 was so that messages of
> unknown length could be transmitted without sending Content-Length.
>
> Multipart/form-data any time I've seen this I've also seen a
> Content-Length header.
>
> What is your application? E.g. what's the reason for this question?
>
> Regards
>
> Adrien
>
>
> Peter wrote:
>>
>> Hi, Adrien.
>>
>> Thanks a lot for your response.
>>
>> In Sec 4.4 of RFC 2616, there seems another alternative way (ie.
>> "multipart/...") to decide message length.
>>
>> If there is other alternative than chunking, why would you think
>> chunking is a MUST?
>>
>> Thanks.
>>
>> peter
>>
>> ----- Original Message ----- From: "Adrien de Croy" <[email-masked]>
>> To: "Peter" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Friday, January 23, 2009 11:56 AM
>> Subject: Re: A question about Content-Length header
>>
>>
>>>
>>> there is no other way to signal the end of the message that the client
>>> is sending.
>>>
>>> A server has the option to close the connection to signal end of message
>>> if no Content-Length or chunking is not used. A client for obvious
>>> reasons does not have this option.
>>>
>>> So in short, I would say the answer is yes, if the client message has an
>>> entity body, and it will not send a Content-Length for whatever reason,
>>> it must use chunking.
>>>
>>> Adrien
>>>
>>>
>>> Peter wrote:
>>>>
>>>> Hi, Julian.
>>>>
>>>> Thanks for your response.
>>>>
>>>> Frustratedly, i still did not get an explicit answer from reading the
>>>> section.
>>>>
>>>> Perhaps i should ask it this way:
>>>>
>>>> MUST an HTTP 1.1 *client* transfer-encode a message body in chunks
>>>> and send Transfer-Encoding header if the client can/will not send
>>>> Content-Length header for some reason?
>>>>
>>>> Looking forward to a either "YES" or "NO" answer according to official
>>>> interpretation of RFC 2616.
>>>>
>>>> Thanks!!
>>>>
>>>> peter
>>>>
>>>>
>>>
>>> -- 
>>> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
>>>
>>
>>
>
> -- 
> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
>

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 25 Jan 2009 19:48:32 +0000

> has a Content-Length header with incorrect msg body length?".

The difference is that HTTP message boundaries (Content-Length etc.)
and <soap:Envelope> are normally parsed by different software.

Message boundaries are parsed by proxies, and those should not have
any knowlege of <soap:Envelope> or other non-HTTP message boundary
terminators.  Message boundaries are also often parsed by generic HTTP
agents, before passing individual messages to specific applications.

> In any situation, the receiver should be able to recover from error input.

If HTTP message boundaries aren't clear, it opens a whole bunch of
security holes.  Especially, connections from proxies may carry
messages from multiple unrelated users at the same time.

-- Jamie

---

From: "Peter" <[email-masked]>
Date: Sun, 25 Jan 2009 12:01:20 -0800

----- Original Message ----- 
From: "Jamie Lokier" <[email-masked]>

> agents, before passing individual messages to specific applications.

I won't argue against the difference (software, agent, proxy or app 
implementation), but in TR-69 domain there seems no proxy between server and 
client.

By the way, if in generic HTTP domains there is such security hole, either 
the application should not be extrally layered with a generic HTTP agent 
(library) or RFC should have precisely/clearly mandated at least one of 
Content-Length and chunked encoding.