[PATCH] Not Modified: prefer entity tags over date validators
mdounin at mdounin.ru
Mon Nov 24 15:29:17 UTC 2014
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.
More information about the nginx-devel