httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?
Date Thu, 14 Sep 2017 15:43:31 GMT
On Thu, Sep 14, 2017 at 4:50 AM, Nick Kew <> wrote:
> On Wed, 13 Sep 2017 08:29:44 -0500
> William A Rowe Jr <> wrote:
>> So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
>> our HTTP/1.1 server? Do we really want people to configure their
>> server to speak "other"?
> Did you mean to say "stop accepting ..."?
>> I'm starting to collect
>> based on searching google for instances where users have toggled
>> HttpProtocolOptions Unsafe, in response to specific application
>> behavior.
> Perhaps a useful exercise, but could take us in to a bad cycle
> of application workarounds that long-outlive the application
> being fixed.
>> From this list, we might decide to allow non-HTTP/1.1 input in
>> specific cases, and perhaps have multiple grades of protocol
>> correctness, as I first proposed.
> You mean something like Options or AllowOverride?  Things that looked
> like a good idea at the time but led to all sorts of issues as the
> server evolved!
> OK, perhaps that's unduly harsh: this will be less problematic to
> maintain.  Are you enumerating cases?

I'm strictly taking a survey of reported conflicts with the newer
HttpProtocolOptions Strict behaviors.

My goal isn't to work around them, simply find out their prevalence
in order to make a binary decision over dropping all legacy GIGO
behavior (actually, garbage in, as we have generally done a nice job
of normalizing the request to the backend or response to the client,
which is what leads to splitting/injection vectors.)

Tomcat and other servers and proxies are taking serious steps
toward accepting only valid input. won't be here for
some time, leaving lots of chances for authors to fix the defects
in the client or upstream/app server or custom clients.

My question is whether HttpProtocolOptions Unsafe is needed,
beyond the 2.4.x lifespan of our project? Conversely, did Unsafe
still block some inadvisable but tolerable requests or responses?
That's the purpose of the wiki incompatibilities page.

View raw message