On Wed, Jul 31, 2024 at 7:34 PM Eric Covener <cove...@gmail.com> wrote: > > On Tue, Jul 23, 2024 at 5:35 AM Yann Ylavic <ylavic....@gmail.com> wrote: > > > > On Wed, Jul 17, 2024 at 6:22 PM <bugzi...@apache.org> wrote: > > > > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=69203 > > > > > > --- Comment #6 from Yann Ylavic <ylavic....@gmail.com> --- > > > Created attachment 39817 > > > --> https://bz.apache.org/bugzilla/attachment.cgi?id=39817&action=edit > > > Proxy FCGI nocanon from SetHandler > > > > I'm not sure how we should proceed here, this patch would avoid > > encoding SCRIPT_FILENAME for "SetHandler proxy:fcgi:..." but not > > "ProxyPass fcgi:..." which looks awkward. SetHandler is the > > recommended/most used way to proxy fcgi which is probably why people > > start noticing now that we do the same as with ProxyPass, but I don't > > see why they should be different in this regard.. > > > > If SCRIPT_FILENAME should be decoded (per the spec) I wonder if > > proxy_fcgi_canon() should not encode at all, or maybe only when > > FCGI_MAY_BE_FPM() (so to have an opt-out)? > > > And like in the above patch forbid controls still but not space/tab, WDYT? > > Based on the bug and the japanese path, maybe set the bar even lower > and just ratchet it all the way back to the character we know is > problematic?
So I went with r1919620 which makes the most sense for me. This will forbid control characters (hence allow for space only, not tab anymore) but mainly will *not* re-encode r->filename, irrespective of ProxyPass vs SetHandler (I think that if users want the encoding we should have an opt with ProxyFCGIBackendType, ProxyPass vs SetHandler makes no sense here..). WDYT? Regards; Yann.
