Re: A fresh stale response

[Mark Nottingham <[e-mail]>]

Hi Alex,

This is now <https://github.com/httpwg/http-core/issues/23>. 

I've put some thoughts down there.

Cheers,


> On 13 May 2016, at 10:21 am, Alex Rousskov <[e-mail]> wrote:
> 
> Hello,
> 
>    I need help navigating a pair of semi-conflicting RFC 7234 MUSTs.
> 
> Imagine a cache that has a stored response A with a Date value X. The
> cache sends a conditional request to validate that cached response. The
> cache receives a 200 OK response B with a Date value of Y.
> 
> If X <= Y, then the situation is clear -- A is stale and the cache
> should use B.
> 
> What if X > Y? In other words, what if the cache receives a 200 OK
> response B that appears to be older (i.e., even more stale) than the
> response A the cache is trying to validate? Should the cache trust the
> sender's staleness decision or its own date comparison logic?
> 
> * RFC 7234 section 4 says "a cache MUST use the most recent response (as
> determined by the Date header field)". That means A wins.
> 
> * RFC 7234 section 4.3.3 says "the cache MUST use the full response [it
> just received]". That means B wins.
> 
> * RFC 2616 section 13.2.5 says "If a client performing a retrieval
> receives a non-first-hand response for a request that was already fresh
> in its own cache, and the Date header in its existing cache entry is
> newer than the Date on the new response, then the client MAY ignore the
> response". That means A wins if A was fresh and B came from a cache.
> 
> 
> If I have to guess, I would use B if it does not have an Age header,
> boldly assuming that it is a first-hand response. Otherwise, use A. With
> more time/effort, revalidating with max-age=0 would be a good option
> (but it may result in the same conundrum).
> 
> 
> Is this a gray area, or did I miss a specific HTTPbis rule that resolves
> this conflict? Was the quoted RFC 2616 MAY replaced with something
> equally specific? If this is a gray area, what do you recommend?
> 
> 
> Thank you,
> 
> Alex.
> 

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