W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: A question about Content-Length header

From: Adrien de Croy <adrien@qbik.com>
Date: Sat, 24 Jan 2009 13:12:11 +1300
Message-ID: <497A5CDB.3050709@qbik.com>
To: Peter <cnmjbm@gmail.com>
CC: ietf-http-wg@w3.org


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 Saturday, 24 January 2009 00:10:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:00 GMT