[PATCH] Not Modified: prefer entity tags over date validators

[Maxim Dounin]

Hello!

On Sun, Nov 23, 2014 at 03:40:43AM -0800, Piotr Sikora wrote:

> Hey Maxim,
> 
> > Sure.  We do adhere RFC2616 here.  The problem is that RFC7232 is
> > different, and there are no known reasons why it should.
> 
> RFC7232 obsoletes RFC2616, so it should be pretty clear which one to
> respect in places they differ.

Or which one to ignore, if something in it looks wrong/suspicious. 
I'm just trying to say that blindly following an RFC isn't a good 
rationale for a commit.

> > The same applies to RFC2616, but it mandates different behaviour.
> > So what's the problem with checking both date and ETag?
> 
> Checking both validators can easily result in false-negatives, i.e. it
> is possible to send legitimate conditional request that would pass
> strong entity tags validation, but fail weak date validation, because
> clients can send requests with "If-Modified-Since: date of the
> response" that fails on the web servers using stricter than required
> "exact" logic (i.e. nginx).
> 
> Checking only the strongest validator prevents this from happening.

That's the only explanation I can think of, too, but it doesn't 
justify the "MUST" clause used in the RFC7232.  Nothing really bad 
can happen if a server adheres to RFC2616 mandated behaviour and 
checks both validators.  At most, the behaviour will be suboptimal.  
And, AFAIK, all clients do behave in a way compatible with RFC2616 
and don't try to send fake dates in If-Modified-Since.  So the 
question remains.  Or, rather, two questions:

- Why the change was done in RFC7232 compared to RFC2616.

- Do we really need to change anything in our code.

-- 
Maxim Dounin
http://nginx.org/