Subject: Last-Modified header in 304 and 206 responses

From: Zhong Yu <[email-masked]>
Date: Fri, 6 Apr 2012 18:28:15 -0500

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"?

Zhong Yu

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 13 Apr 2012 18:55:06 +1200

> 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

---

From: Zhong Yu <[email-masked]>
Date: Fri, 13 Apr 2012 10:05:23 -0500

On Fri, Apr 13, 2012 at 1:55 AM, Amos Jeffries <[email-masked]> wrote:
> 1) including headers on 304 means they *have* changed from the request being
> tested.
>
> For example;
> 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.
>
>
> When sent on a 206 they indicate the 206 entity details. Not some previous
> 200 responses.
>
> 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

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

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 14 Apr 2012 21:31:01 +1200

On 14/04/2012 3:05 a.m., Zhong Yu wrote:
> On Fri, Apr 13, 2012 at 1:55 AM, Amos Jeffries<[email-masked]>  wrote:

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.

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

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

> concatenation. Nonetheless, it's harmless to include these headers in

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Apr 2012 15:16:56 +1000

Thanks for noticing. This appears to be a leftover from <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/345>, which I've just reopened.

Cheers,

--
Mark Nottingham   http://www.mnot.net/