durusmail: quixote-users: SCGI + Quixote, Location / ?
SCGI + Quixote, Location / ?
2005-08-10
2005-08-10
2005-08-10
2005-08-10
2005-08-10
2005-08-10
2005-08-10
2005-08-10
2005-08-10
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-12
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-11
2005-08-11
RELEASED: scgi-1.6
2005-08-11
2005-08-11
SCGI + Quixote, Location / ?
Mike Orr
2005-08-11
Michael Best wrote:

> Redirect isn't going to do anything in my case I already have a
> trailing slash.  I'm going to http://www.example.com/ in my browser.
>
> 
> SCGIMount / localhost:4000
> 
>   Order allow,deny
>   Allow from all
> 
> 
>
> Traceback contains:
> PATH_INFO
> QUERY_STRING
> REQUEST_URI     /
> SCGI            1
> SCRIPT_NAME     /
> SCRIPT_URI      http://www.example.com/
> SCRIPT_URL      /
>
> Doesn't this piece of code from mod_scgi.c tell the story though?
> SCRIPT_NAME is set to r->uri when there isn't r->path_info.  Perhaps
> something like if (PATH_INFO="" and REQUEST_URI="/") then
> SCRIPT_NAME=""?  It's late and I just making a stab in the dark.
>
> And isn't the second add_header(t, "SCRIPT_NAME", r->uri); in the else
> redundant, since it gets set before the if and gets set in the else so
> it happens either way?
>
>     add_header(t, "SCRIPT_NAME", r->uri);
>     if (r->path_info) {
>         int path_info_start = find_path_info(r->uri, r->path_info);
>         add_header(t, "SCRIPT_NAME", apr_pstrndup(r->pool, r->uri,
>                                                   path_info_start));
>         add_header(t, "PATH_INFO", r->path_info);
>     }
>     else {
>         /* skip PATH_INFO, don't know it */
>         add_header(t, "SCRIPT_NAME", r->uri);
>     }
>
> Here is a discussion about something similar on the Web-SIG mailing
> list in a thread titled WSGI tests:
> http://mail.python.org/pipermail/web-sig/2004-September/000925.html
>
> Looking in Python Web Server Gateway Interface v1.0 doesn't give me
> much info either.
> http://www.python.org/peps/pep-0333.html



I guess SCGIMount '/' is a special case.   With my subdirectory example,
the mount point is the *parent* of the root URL (=application home
page).  It's in a never-never land where neither Apache nor Quixote can
handle it, hence the need for the redirect.  But with "SCGIMount '/'",
the mount point *is* the root URL, and there is no parent.  "SCGIMount
''" looks invalid but there doesn't seem to be any other way, especially
since Ian's WEB-Sig message suggests it should translate to:
    SCRIPT_NAME=""  PATH_INFO="/"
which would be consistent with how Quixote normally traverses the path.

So the question is whether users should put "SCGIMount ''" literally in
their configs, or mod_scgi should implicitly convert it.  Either way is
problematic:

SCGIMount '':  the URI between this and the corresponding  is
no longer identical, which makes it slightly more difficult to verify
they are correct.   is needed because some directives cannot
be outside it, and to make it easier to move an application between
different mount points.

SCGIMount '/': the user has to remember this is a special case,
otherwise they'll do "SCGIMount '/foo/'" for subdirectories.  Of course,
it's arbitrary which convention we follow, as long as it's consistent
with  and doesn't leave a slashless URI in never-never land.


>> SCRIPT_NAME
>>     The initial portion of the request URL's "path" that corresponds
>> to the application object, so that the application knows its virtual
>> "location". This may be an empty string, if the application
>> corresponds to the "root" of the server.
>> PATH_INFO
>>     The remainder of the request URL's "path", designating the
>> virtual "location" of the request's target within the application.
>> This may be an empty string, if the request URL targets the
>> application root and does not have a trailing slash.
>

This rule for SCRIPT_NAME is consistent with the above.  The part about
PATH_INFO being blank sounds like an error; it should be translated to
'/'.  But "somebody" really has to send a redirect rather than just
converting the value; otherwise the base URL will be wrong for relative
HREFs within the document.
reply