David Binger wrote:
> On Aug 11, 2005, at 12:07 PM, Shahms King wrote:
>
>> I should have piped up earlier, but this behavior also occurs with
>> mod_python.  I can't speak for mod_scgi's SCRIPT_NAME and PATH_INFO
>> behavior, but as of Quixote 2.0 (haven't tried 2.1 yet, though I
>> need to
>> get rolling on the Fedora Extras packages...) the "abort on an empty
>> PATH_INFO" behavior essentially means that Quixote will append a
>> trailing slash onto any directory except the root, leading to
>> situtions
>
> If your environment always has the full path in SCRIPT_NAME, and
> nothing in PATH_INFO, then the redirect to SCRIPT_NAME + '/' requires
> all urls to end in a trailing slash.  I think this is what you are
> saying, anyway, and I agree that it is undesirable.
>
> If you *can* trust your environment to have a correct SCRIPT_NAME,
> then the redirect to SCRIPT_NAME + '/' (when PATH_INFO is empty) is
> nice.
>
> Should Quixote's publisher require a correct SCRIPT_NAME?  I think so,
> since this can be provided either through the use of the SCGIMount or
> through the command-line argument to scgi_server.py.
>
> Should Quixote's publisher give the same result
> when PATH_INFO is 'foo/bar' that it gives
> when PATH_INFO is '/foo/bar' ?
> I don't know what to think about this, but it does seem good to
> do something other than trip on the assert.

Well, what else could "foo/bar" mean?  It's really the fault of the
server, but we might as well make Quixote flexible for misplaced slashes,
especially when the specs are not as clear as they should be.

FWIW, Apache does allow a blank URL.  Telnet to port 80 of your favorite
server with a static homepage and type "GET  " + Enter, and Apache returns
the home page.  So it also adds an implicit slash.  But the following
produce "400 Bad Request":
    GET index.html
    GET ''
    GET ""

More SCGI troubleshooting in my next e-mail.

--
-- Mike Orr