On Wed, Dec 15, 2021 at 7:54 AM Roy T. Fielding <field...@gbiv.com> wrote: > > > On Dec 14, 2021, at 2:22 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > > > > 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. > > > > Yeah, the hunk I pointed to in the other message is doing this and I'm > > going to fix it. > > Thanks.
Restored in r1895981, with some changes in ap_proxy_pre_request() to preserve the original URI when forward proxying. Up to some interested proxy module to catch it now, otherwise an error 500 is returned. Btw, 500 looks like the correct error status when reverse proxying (because we set the scheme according to the configuration in this case), but not really for the forward proxy case. Should we return something else for PROXYREQ_PROXY if no module handles the request? Maybe HTTP_NOT_IMPLEMENTED (but it's not about the method here..) or a client error like HTTP_NOT_ACCEPTABLE (not an Accept/Accept-Encoding thing either..) or yet HTTP_NOT_FOUND or the generic HTTP_BAD_REQUEST? Regards; Yann.
