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

Piotr Sikora piotr at cloudflare.com
Mon Nov 24 21:57:32 UTC 2014


Hey Maxim,

> 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
interoperability issues.

> 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.

Agreed.

> 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.

Best regards,
Piotr Sikora



More information about the nginx-devel mailing list