Re: Last-Modified header in 304 and 206 responses

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?

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.

AYJ

Received on Friday, 13 April 2012 06:55:38 UTC