multipart/byteranges - was A question about Content-Length header

I just read through section 19.2 of RFC2616, and it raises some more
questions for me.

1. Does anyone use multipart/byteranges without Content-Length?

Theoretically if you are a server, and you got a request for a bunch of
defined-length ranges, you should be able to calculate a Content-Length,
including wrappers for the multipart boundaries.

2. What's the best way for a proxy to deal with this?

A proxy trying to keep track of messages going back and forth it seems
has to keep track of message boundaries 3 ways

a) Content-Length
b) Chunking
c) multipart/byteranges without Content-Length

Is this really the intent? It seems needless work is being required of
the proxy to parse multiple parts to determine the message end (e.g.
just like chunking but different), when the server arguably could ./
should be simply providing a Content-Length header. Section 4.4. implies
the Content-Length header is not required. It doesn't discuss
combination of Content-Length + multipart/byteranges, or proxies.

It seems the easiest way for a proxy to deal with this is to strip
Ranges from any request message.

Especially if a proxy is passing data through a chain of filter processes.

Thanks

Adrien

Adrien de Croy wrote:
> 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:40:09 UTC