> Am 14.09.2017 um 17:43 schrieb William A Rowe Jr <[email protected]>: > > On Thu, Sep 14, 2017 at 4:50 AM, Nick Kew <[email protected]> wrote: >> On Wed, 13 Sep 2017 08:29:44 -0500 >> William A Rowe Jr <[email protected]> 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 https://wiki.apache.org/httpd/Applications >>> 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. 2.next/3.0 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.
+1 to giving applications the chance to make their case. +1 to remove all Unsafe cruft from trunk. Personally, I'd be tempted to remove even more, all the 0.9 stuff, for example, and make this into a 2.6.x release line. As a security focus release line for a) people who do not need the backward complications b) people who want to verify that their app/clients no longer need the compat code -Stefan
