On Wednesday 29 March 2017 20:01:55 Piotr Sikora via nginx-devel wrote: > Hey Valentin, > > > IMHO it's not a good idea to combine style fixes with behavior changes. > > Behavior changing commits are occasionally reverted. > > Fair enough, I'll update both patches shortly. > > > That's why it's still TODO (in other words intentionally skipped). > > We discussed it with QA and decided to be more tolerant here. > > I disagree. Forgiving implementations that allow broken clients to > seemingly "work", even when said clients are not obeying the > specification, are the reason why we have broken clients in the first > place. >
One of the broken clients (not in this place particularly, but in a few others) is Google Chrome. Sometimes it takes year to convince devs to do something about that, even if the issue is obvious. Here is an example: https://bugs.chromium.org/p/chromium/issues/detail?id=546991 And if something isn't working in browser-webserver combination then this is usually us who will be blamed for. Because people need their services working in the first place. As a result, you can see such commits: http://hg.nginx.org/nginx/rev/8df664ebe037 I agree with your arguments about the positive side in enforcing strict validation. On the other hand, the main goal is to keep our users setups working with any clients. The world isn't perfect and neither us, nor our users can fix it. As the 1.11 branch is going to be stable soon, it's a good idea to postpone any changes that explicitly affect interoperability (at least till 1.13). wbr, Valentin V. Bartenev _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
