Re: Updating Entity Headers with 304s

lör 2007-02-10 klockan 16:41 +1100 skrev Mark Nottingham:

> However, an implementer has interpreted the stated intent to mean  
> that a cache should not allow entity headers to be updated by 304s.  
> See: <http://issues.apache.org/bugzilla/show_bug.cgi?id=39647>.

Well.. that's clearly not what the RFC means, but at the same time
updating some things doesn't make much sense like Content-Length and
maybe Content-Type.

There is one quite relevant paragraph which could apply here. 10.3.5
304, second last paragraph

   If a 304 response indicates an entity not currently cached, then the
   cache MUST disregard the response and repeat the request without the
   conditional.

now, content-type doesn't really identify the entity in terms of HTTP,
but a change in content-type is pretty good indication that something
important has changed and that the cached entity probably no longer is
valid..

> There's a certain logic to both positions. Does anyone recall what  
> the original intent was, and do we need a clarification here?

I don't think clarification is needed unless we want to clarify more in
detail when a 304 should be discarded by the 10.3.5 paragraph above.

We are here in the area of how caches should behave when receiving
non-compliant responses. In this area cache implementers have three
choices

  a) Trust the response and blame the non-compliant origin server if
someone complains about the result.

  b) Discard the response and try again without the conditional as per
10.3.5 paragraph above.

  c) Try to make something which makes sense out of the non-compliant
response.

I think 'b' is what the RFC wants implementers to choose, but I also
think most will select 'c' for efficiency reasons and not sure that's a
bad thing..

Regards
Henrik