httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: HTTP/1.1 strict ruleset
Date Thu, 18 Aug 2016 09:56:56 GMT
On Thu, Aug 18, 2016 at 4:26 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pluem@vodafone.com> wrote:

>
> > -----Original Message-----
> > From: Yann Ylavic [mailto:ylavic.dev@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 <wrowe@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

Mime
View raw message