« Return to Thread: Last-Modified header in 304 and 206 responses
Re: Last-Modified header in 304 and 206 responses
by Amos Jeffries-2
::
Rate this Message:
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
> 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
« Return to Thread: Last-Modified header in 304 and 206 responses
| Free embeddable forum powered by Nabble | Forum Help |
