Re: Last-Modified header in 304 and 206 responses

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.

> 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)


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

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

Zhong Yu

Received on Friday, 13 April 2012 15:05:55 UTC