Re: A question about Content-Length header

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" <adrien@qbik.com>
To: "Peter" <cnmjbm@gmail.com>
Cc: <ietf-http-wg@w3.org>
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" <adrien@qbik.com>
>> To: "Peter" <cnmjbm@gmail.com>
>> Cc: <ietf-http-wg@w3.org>
>> 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
>

Received on Sunday, 25 January 2009 00:16:45 UTC