On Thu, Aug 11, 2016 at 7:20 AM, Jim Jagielski <j...@jagunet.com> wrote:
> > > On Aug 4, 2016, at 6:21 PM, Roy T. Fielding <field...@gbiv.com> wrote: > > > > > > 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. > > +1 > Just to be clear, that is now 2 votes for eliminating the 'classic parser' from all of trunk, 2.4.x and 2.2.x branches, and using only the strict parser, unconditionally. That's actually 3 votes for removing it from trunk, which I planned to do already, after 2.4 and 2.2 backports are in-sync with trunk. I'm a little concerned that oddball back-ends will be seriously disrupted by this change and unable to otherwise upgrade or adopt the rest of our worthwhile bug fixes. But I don't think that the oddball behavior should be a default, I like the suggestion that this whole mess be renamed HTTPUnsafe rather than HTTPStrict. Let their configuration directive be a warning that it's not a good idea to enable it. Since I've heard little support in these past weeks for leaving an HTTP strict 'logging-only' option, I'm going to rip that out, but replace it with options to independently toggle HTTPUnsafe and HTTPResponseUnsafe values, so that the server can continue to deliberately process oddball backends that don't conform, while requiring strict behavior of originating user-agents. But if there is a third vote against retaining the legacy support, on any branch, the answer is to drop all of these toggles and rip out the old code.
