durusmail: quixote-users: SCRIPT_NAME vs. SCRIPT_URL in get_path()
SCRIPT_NAME vs. SCRIPT_URL in get_path()
2004-09-13
2004-09-13
2004-09-14
SCRIPT_NAME vs. SCRIPT_URL in get_path()
Martin Maney
2004-09-13
On Sun, Sep 12, 2004 at 10:44:18PM -0400, Roman Rodyakin wrote:

[description of the rewrite problem omitted]

> Looking at http_request, I see that SCRIPT_NAME is set to
> /my/complicated/path/demo.fcgi whereas SCRIPT_URL is set to
> /quixote/demo.fcgi/form_demo.
>
> Is this a bug in get_path() or is there a reason why it has to be
> SCRIPT_NAME + PATH_INFO, and not SCRIPT_URL?

If I had to take a position and defend it, I think I would have to go
with "it's an apache bug".  The Apache docs (1.x release) reference
http://hoohoo.ncsa.uiuc.edu/cgi/env.html as defining the CGI spec for
environment variables, and there it says of SCRIPT_NAME:

   A virtual path to the script being executed, used for
   self-referencing URLs.

I'm glad I don't actually have to defend any one position, because this
doesn't exactly make Apache's behavior wrong; you *can* use the
rewritten URL to access the script. (1)  The problem is that at least in
my world, rewriting is used mostly to hide the mechanics of CGI (the
script may be required to be named with ".cgi", be in a particular
directory, etc.).  So I would prefer not to have the real (physical,
more or less) path used, more as a matter of appearance, but also with
an eye towards decoupling the access URL from the implementation.  Is
this a plain CGI, fastCGI, or SCGI setup?  With rewriting, users don't
have any need (or way) to know.

Provided you can get back to the original, un-rewritten URL (what I seem
to want to call the access URL) for non-relative links within the app.
One problem with a flexible URL that can contain options: it's not
always trivial to compose a relative URL from an access that has
arbitrary optional components.  I've worked around this (and the
rewrite problem) by having the driver script provide the access URL of
the application's base, and composing app-relative URLs using that.  It
becomes just one more of those arbitrary things that depend on external
forces.

This set of issues was part of what I wanted to address in the as yet
unwritten wiki page I was talking about last weekend.  Unfortunately,
I've been wrestling with other things all week and haven't had any time
to pursue it this weekend.  I would be interested in seeing how other
folks are dealing with this - sometimes I catch myself wondering if
it's worth the trouble to keep the ".cgi" and so forth hidden...


(1) at least with Apache rewriting, I think the rewritten URL *has* to
be valid - after all, the rwriting is explicitly of the URL: it's not a
magical mapping from public URL to some other name space.  Though I
suppose you could block the translated URL from public access with more
rewriting and careful use of the "last" flag in the rules.

--
If there is a lesson to be learnt from Adobe's eBook
fiasco, it is that litigation is no substitute for
well-designed software.  -- The Economist


reply