R. David Murray added the comment: That's why I referred to it as an optimization (as does the RFC, according to you). As such, *normally* we wouldn't add it to a maintenance release. The question is, is it acceptable to do so because it addresses, in a backward compatible way, an issue that arises because people are changing their web sites to be more security conscious?
I don't see a likelyhood that the switch from two to one requests is likely to break anything (though I'm sure it could), because web sites already need to deal with clients that only send one request. The only place the change is likely to be breaking is in a custom client/ap situation (ie: something internal corporate, most likely) or in a test framework. I suspect these are acceptable possibilities in the current context, but I want other core committer opinions. On the other hand, introducing a new class *is* a visible API change, and thus *cannot* go into a maintenance release, absent a PEP 466 style exception, and I don't see how this raises to that level, since it doesn't result in a security vulnerability, just an inability to talk to security conscious web sites. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19494> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
