On Thu, Aug 18, 2016 at 4:26 AM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote:
> > > -----Original Message----- > > From: Yann Ylavic [mailto:ylavic....@gmail.com] > > Sent: Donnerstag, 11. August 2016 22:40 > > To: httpd-dev > > Subject: Re: HTTP/1.1 strict ruleset > > > > On Thu, Aug 11, 2016 at 6:56 PM, William A Rowe Jr <wr...@rowe-clan.net> > > wrote: > > > > > > I haven't dug terribly deeply into the proxy mechanics yet, but the > same > > > parser for headers is used for response header processing as well as > the > > > request processing. > > > > They don't share the same code, though, ap_proxy_read_headers() would > > need the same "strictification" than ap_get_mime_headers(_ex)() > > currently, or be replaced by the latter. > > > > > It seems that the two need some potentially different > > > rulesets. If you are running a forward proxy, you would want to be > quite > > > strict about the responses. If you are only a gateway of trusted > backend > > > servers and apps, you might want to be more tolerant (although Roy and > > > Jim may disagree with me on this.) > > > > +1, behind 2.2 proxies (but possibly 2.4 too), there are some outdated > > backends/applications (supporting SSLv3 only...) that don't receive > > many (if any) maintenance but just work, and for that reason where > > placed behing a proxy. > > So I guess we should be strict on the client side on every branch, but > have an opt out > for the backend of a gateway in 2.2 / 2.4. > That's my read, we need to be more strict in what we accept by default, and provide administrators various 'outs' to otherwise still consume the branch (2.2 or 2.4) that they have build their infrastructure around, at least until they are able to clean up their local messes. Some rules can and should be unavoidable. RFC7230 calls out several of these, while remaining relaxed around others. That's why it took me four different HttpProtocolOptions behavior toggles, in the latest parser commit a couple hrs ago, to satisfy these varying layers of significance. I even found one we could relax under 3.5 and chose not to do so (that section is really clear that leading and trailing whitespace might be parsed, but why introduce a new incorrect behavior we never offered before?) When I re-crafted HttpProtocolOptions yesterday, I'd already foreseen the need for all four of these current options, and more as we apply these rules to the response from a forward-proxied server (which we probably want to enforce a distinct ruleset on). It is probably necessary for us to create an HttpProxyProtocolOptions for back-end response handling, rather than overloading this directive with extra-wordy components. But I'm also anticipating that by popular demand, we will end up relaxing one or more rules based on yet another independent toggle, based on the frequency that never-before-valid behaviors are present in the ecosystem. All productive suggestions are welcome, I'm not strongly tied to any of the http://httpd.apache.org/docs/trunk/mod/core.html#httpprotocoloptions keywords, except in as much as I tried to borrow the precise language used in RFC7230 when it applied. Edits for legibility are also welcome. Maybe an example for good measure :) Cheers, Bill
