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. -garrett
