Re: WGLC: p5 MUSTs

[Alex Rousskov <[e-mail]>]

On 05/01/2013 07:33 AM, Ken Murchison wrote:
> On Tue, 30 Apr 2013 19:18:49 -0600,
> Alex Rousskov wrote:
>> > Clients MUST NOT use an entity-tag marked as weak in an If-Range
>> > field value and MUST NOT use a Last-Modified date ...
>>
>> Please replace "use" with "generate" to explicitly exclude proxies from
>> policing these headers (i.e., to allow proxies to forward these headers
>> "as is"). This was already done for other If-Range header rules, but
>> these two MUST NOTs have slipped through the cracks.
>>   
> Clients don't generate ETags, they just use what they have seen in
> responses from servers.  I think the sentence would have to be reworded
> to something like:
> 
> "Clients MUST NOT generate an If-Range field value containing an
> entity-tag marked as weak and MUST NOT generate an If-Range field value
> containing a Last-Modified date..."

Sounds good. The term "generate" is indeed overloaded in this context
and your wording is better.


>> > 4.1 206 Partial Content
>>
>> Since HTTPbis no longer allows multipart/byteranges media type to
>> determine the message body length, perhaps it would be a good idea to
>> explicitly mention that a server MAY generate a 206 Partial Content
>> response (with single or multiple ranges) without a Content-Length
>> header and may use chunked encoding? I bet many clients will break when
>> this starts happening, and there are currently no examples or warnings
>> that would prepare developers for that possibility.
>>   
> A HTTP/1.1 server can always use chunked encoding for a response and any
> HTTP/1.1 client that can't handle chunked or doesn't expect it for a
> certain response code is already broken.  I don't see the need to
> specifically call this out for a 206 response.

Agreed. I did not realize RFC 2616 already placed chunked above
multipart/byteranges in Message Length rules, so chunked
multipart/byteranges were already possible.


Thank you,

Alex.