Re: Last-Modified header in 304 and 206 responses

On 14/04/2012 3:05 a.m., Zhong Yu wrote:
> On Fri, Apr 13, 2012 at 1:55 AM, Amos Jeffries<squid3@treenet.co.nz>  wrote:
>> On 7/04/2012 11:28 a.m., Zhong Yu wrote:
>>> In RFC2616, Last-Modified header was not allowed in 304 and 206(to an
>>> If-Range request)
>>>
>>>    http://tools.ietf.org/html/rfc2616#section-10.3.5
>>>    http://tools.ietf.org/html/rfc2616#section-10.2.7
>>>
>>> In draft 19, Last-Modified is allowed/required in 206/If-Range, but
>>> still forbidden in 304
>>>
>>>
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-19#section-4.1
>>>    http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19#section-3.1
>>>
>>> Any reason for the asymmetry?
>>>
>>> Furthermore, why must we exclude other entity headers in 304 and
>>> 206/If-Range? There are only 3 of them: Content-Encoding,
>>> Content-Language, Content-Type. They can't have any meaningful impact
>>> on performance if they are included in the response. Do they really
>>> deserve a "SHOULD NOT be included"?
>>
>> Turning that on its head. What use case needs including them?
>>
>> Two reasons for not including them:
>>
>> 1) including headers on 304 means they *have* changed from the request being
>> tested.
>>
>> For example;
>>   when testing/validating a text/html English language object modified
>> 2012-04-10 12:00am
>>
>> Would you expect the 304 response assertion that "yes this binary/gif object
>> with Greek text has not changed since 2012-04-11 12:00am" to *ever* be
>> valid?
> What if the resource has two representations, English html and Greek
> gif. Server selects one of them based on the client IP address. And
> the client uses some dynamic proxy with world-wide deployment (Tor?)
>
> Inherently Last-Modified is an unreliable validator.

Yes last modified alone is unreliable when variants exist.

By itself in that case yes, for exactly that reason you state. The 
server should have been issuing "Vary: *" to indicate non-HTTP details 
vary the response. And ETag etc can assist with correlation.

>
>> For the 304 response to be valid those headers MUST be fixed constant values
>> with no possibility for corruption after the 200 response with entity.
>>
>>
>> 2) those headers are specifically defined as being related to the entity
>> attached to the response.
>>
>> When sent on a 206 they indicate the 206 entity details. Not some previous
>> 200 responses.
>>
>> It is reasonable to expect a range request which asked for example bytes
>> 0-256 of a 4KB object without specifying which variant (gzip, identity, etc)
>> forms of the object is held already. The 206 entity might therefore vary
>> from one already held. This may not even matter for display/use/caching
>> purposes, but it is *very* important to know whether merging of the ranges
>> is or is not safe.
> My original question is about a 206 response to a range request with
> *If-Range* header. In the latest draft, Last-Modified header MUST be
> included in the response. This is different from rfc2616, where the
> header SHOULD NOT be included in the same situation. I'm trying to
> understand the reason behind the change, and why the same change is
> not applied to 304. (Also note that If-Range (with date) is stricter
> than If-Modified-Since; If-Range requires exact match)

There is an important "if the header field would have been sent in a 200 
response to the same request" sitting right after the list of headers.

Its not saying the header must always be present, just that the 200/206 
must be consistent in what they send or omit from that list of headers.

>
>
> Your argument also proves that we MUST include Content-Encoding header
> in a 206 response, regardless of the If-Range header in the request.
> The same goes for Content-Language and Content-Type. All 3 headers may
> vary while Last-Modified remains the same. Therefore this section
> needs reconsideration
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19#section-3.1

I would have thought they were commons sense. But perhapse for clarity 
something needs to be said.

>
> The argument cannot be extended to 304, which doesn't do bytes
> concatenation. Nonetheless, it's harmless to include these headers in
> 304.

Indeed. But why waste the bandwidth? the details being sent needs must 
already be held by the client.
http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-19#section-4.1 
paragraph 3.


Amos

Received on Saturday, 14 April 2012 09:31:36 UTC