I may have messed up, but this change is meant to return 400 early for requests with a fully qualified URI that is not http/https and that no forward-proxy module wants to handle (i.e. none did set r->proxyreq = PROXYREQ_PROXY at post_read_request time, like forward proxy modules do).
Those requests end up being handled by the http module as if they were http, which looks wrong to me. Regards; Yann. On Tue, Dec 14, 2021 at 6:26 PM Roy T. Fielding <field...@gbiv.com> wrote: > > This is a little confusing. It looks from the comment and code like the > change is restricting the request target that can be sent through a proxy, > which would be wrong. > > OTOH, it would make sense that the proxy itself (the thing to which the > proxied request is being sent) is limited to http(s) because that is a feature > of HTTP. Is that what was intended? > > ....Roy > > > On Dec 14, 2021, at 9:10 AM, Roy T. Fielding <field...@gbiv.com> wrote: > > > > I am pretty sure that this isn't correct, or at least seems like overkill. > > We should definitely block unix: from being forwarded, but why would > > we want to block things like a urn: resolver? > > > > To be clear, I'd rather remove all proxy functionality from httpd than > > suggest to the world that http(s) schemes are the only names that > > can be proxied through HTTP. It would break the Web architecture, > > so -1 to that. > > > > ....Roy >
