[PATCH] Not Modified: prefer entity tags over date validators
piotr at cloudflare.com
Mon Nov 24 21:57:32 UTC 2014
> 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.
Yeah, but not following and/or doing exactly the opposite (like in
this case) without good reason just leads to edge cases and
> 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.
The thing is that neither RFC says what date should be used in
"If-Modified-Since" header, both only advise to use the one from
"Last-Modified" for best interoperability. However, the semantics of
it suggest that any date is fine, really, and a lot of web servers
implement this quite literally (i.e. using nginx's "before" logic).
> 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.
I don't think you have a good enough reason to justify not adhering to RFC7232.
More information about the nginx-devel