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/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel