You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Holsman <li...@holsman.net> on 2006/01/05 10:24:09 UTC

[patch] FCGI -- pass path-info to FCGI process

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.

Index: mod_proxy_fcgi.c
===================================================================
--- mod_proxy_fcgi.c    (revision 366086)
+++ mod_proxy_fcgi.c    (working copy)
@@ -28,6 +28,7 @@
 static int proxy_fcgi_canon(request_rec *r, char *url)
 {
     char *host, sport[7];
+    char *path;
     const char *err;
     const char* scheme;
     apr_port_t port = 8000;
@@ -62,8 +63,13 @@
             host = apr_pstrcat(r->pool, "[", host, "]", NULL);
         }
         
-        r->filename = apr_pstrcat(r->pool, "proxy:", scheme, host, 
sport, "/",
+        path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 
0, r->proxyreq);
+        if (path == NULL)
+            return HTTP_BAD_REQUEST;
+
+        r->filename = apr_pstrcat(r->pool, "proxy:", scheme, host, 
sport, "/", path,
                                   NULL);
+
     }
     else if (strncmp(url, "local://", 8) == 0) {
         url += 6;
@@ -130,6 +136,7 @@
 {
     const apr_array_header_t *envarr;
     const apr_table_entry_t *elts;
+    char *path;
     struct iovec vec[2];
     fcgi_header header;
     apr_size_t bodylen;
@@ -143,6 +150,18 @@
     ap_add_common_vars(r);
     ap_add_cgi_vars(r);
 
+    if (r->path_info) {
+        apr_table_setn(r->subprocess_env, "PATH_INFO", r->path_info);
+    }
+    else {
+        path = ap_strchr_c( r->filename,'/');
+        if (path) {
+            path = ap_strchr_c( path,':');
+        }
+        if (path) {
+            apr_table_setn(r->subprocess_env, "PATH_INFO",  
ap_strchr_c(path, '/'));
+        }
+    }
     /* XXX are there any FastCGI specific env vars we need to send? */
 
     /* XXX What if there is over 64k worth of data in the env? */


Re: [patch] FCGI -- pass path-info to FCGI process

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/8/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 1/7/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > On 1/5/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > > On 1/5/06, Ian Holsman <li...@holsman.net> 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

Re: [patch] FCGI -- pass path-info to FCGI process

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/7/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 1/5/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > On 1/5/06, Ian Holsman <li...@holsman.net> 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

Re: [patch] FCGI -- pass path-info to FCGI process

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/5/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 1/5/06, Ian Holsman <li...@holsman.net> 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.

-garrett

Re: [patch] FCGI -- pass path-info to FCGI process

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/5/06, Ian Holsman <li...@holsman.net> 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?

-garrett