On 1/8/06, Garrett Rooney <[EMAIL PROTECTED]> wrote: > On 1/7/06, Garrett Rooney <[EMAIL PROTECTED]> wrote: > > On 1/5/06, Garrett Rooney <[EMAIL PROTECTED]> wrote: > > > On 1/5/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > > > this allows you to pass a 'path' to the fast cgi process > > > > to use: > > > > ProxyPass /forum fcgi-tcp://127.0.0.1:8005/foruX > > > > > > > > request > > > > /forum/zx will have a path_info of /foruX/zx > > > > > > > > posting it as a patch, as the code is a bit fugly. > > > > > > The question is, what should PATH_INFO actually be set to. Your way > > > of doing things gives some interesting flexibility, but intuitively it > > > seems to me that it would be the portion of the request URI after > > > /forum (for this example), not include /forum at all. > > > > > > Also, I'm not sure about this syntax because I'm not clear how it > > > would work for local fcgi processes that use a unix domain socket. > > > I've assumed that the fcgi-local:// scheme would do something like > > > fcgi-local://localhost/path/to/socket, and in that case how can you > > > tell the difference between the socket and the path extension? > > > > FWIW, here's my alternate patch to implement PATH_INFO. It seems to > > give results that match what I'd assume (i.e. for a ProxyPass on > > /fcgi, and a request to /fcgi/foo?bar&baz you'd get PATH_INFO = "foo", > > QUERY_STRING = "bar?baz"), and I imagine you can play mod_rewrite > > tricks to get more interesting behavior if you're so inlined. > > I discussed this with Ian briefly today, and we decided to go with > this patch for now, since it's likely that the other behavior can be > replicated with mod_rewrite if necessary. This can of course be > revisited in the future if it turns out there's a more correct > behavior we should be implementing.
And then there was more discussion, and it's now clear to me that we really do need to be able to stick portions of the path info on the end of the back end URLs, the ability already exists for mod_proxy_http, and we will want at least feature parity with that backend in this sort of thing. See r367208 for the implementation of this, which is similar to iholsman's initial patch, but a bit simpler. I promise, this is the last time I'll reply to myself in this thread ;-) -garrett
