httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: HTTP/1.1 strict ruleset
Date Thu, 04 Aug 2016 22:02:28 GMT
On Thu, Aug 4, 2016 at 3:46 PM, Roy T. Fielding <> wrote:

> > On Aug 3, 2016, at 4:33 PM, William A Rowe Jr <>
> 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
while doing all enhancement in their next release. This isn't that project.

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

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

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.

View raw message