> On Aug 4, 2016, at 3:02 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Aug 4, 2016 at 3:46 PM, Roy T. Fielding <field...@gbiv.com > <mailto:field...@gbiv.com>> wrote: > > On Aug 3, 2016, at 4:33 PM, William A Rowe Jr <wr...@rowe-clan.net > > <mailto:wr...@rowe-clan.net>> wrote: > > > > So it seems pretty absurd we are coming back to this over > > three years later, but is there any reason to preserve pre-RFC 2068 > > behaviors? I appreciate that Stefan was trying to avoid harming > > existing deployment scenarios, but even as I'm about to propose > > that we backport all of this to 2.4 and 2.2, I have several questions; > > In general, I don't see a need for any "strict" options. The only changes we > made to parsing in RFC7230 were for the sake of security and known failures > to interoperate. This is exactly the feature we are supposed to be handling > automatically on behalf of our users: secure, correct, and interoperable > handling and generation of HTTP messaging. We should not need to configure > it. > > Note that the MUST requirements in RFC7230 are not optional. We either > implement > them as specified or we are not compliant with HTTP. > > Understood. And that describes my attitude toward 2.6/3.0 next release. > > We live in an ecosystem with literally hundreds of thousands of legitimate > custom http clients asking httpd server for datum. Most projects would > effectively declare their last major.minor release static, and fix the defects > while doing all enhancement in their next release. This isn't that project.
By that logic, we can't make any changes in minor versions. I disagree that we have ever treated versioning in that way. If a user doesn't like a bug fix, they don't have to install the new version, or they have the code to unfix it. > Because httpd fixes and introduces dozens of bugs each major.minor > subversion release, and we truly agree that we want every user to move > to the most recently released major.minor, breaking hundreds of these > applications with *no recourse* in their build or configuration is > frustrating. Leaving existing users in a broken state of non-compliance with the primary Internet standard we are claiming to implement just because of unsubstantiated FUD is far more frustrating. Bugs get fixed. Users choose whether or not to install. If we find a real problem in a deployed client that causes the bug fix to be intolerable, then of course we will need to configure workarounds. But we are not in that place. > If consensus here agrees that no out-of-spec behavior should be tolerated > anymore, I'll jump on board. I'm already in the consensus block that says > we should not ship a new major.minor without disallowing all of this garbage. > > It would be helpful if other PMC members would weigh in yea or nay on > dropping out-of-spec behaviors from 2.4 and 2.2 maintenance branches. That would be weird. One of us is going to create a patch. That specific patch is going to be voted upon for backport. If anyone wants to veto it, they are free to do so with justification. ....Roy
