Nicolas Lehuen writes:
> a) Handlers and published modules seem to behave the same way, so the
> computation of path_info must come from above, i.e. either from mod_python
> or from Apache.
>
> b) We've got req.uri == req.subprocess_env.get("SCRIPT_NAME") +
> req.subprocess_env.get("PATH_INFO"). Cool, but who does the split ? I'm
> guessing that it's Apache who does it thanks to the AddHandler directives ;
> it knows that the .py extension must be served by mod_python, hence it
> deduces that /test.py must be the script name and /subpath some path info to
> provide the script with.
This is how I conceptualize what apache does: apache takes the PATH
component from the uri and appends it to DocumentRoot, it then
searches down this path, starting with the first path component after
DocumentRoot, testing to see if it exists on the filesystem. If it
exists it continues to the next path component. If it doesn't exist
and the previous component was a file, then PATH up to, but not
including the current component is the "script" and this component to
the end of PATH is the path_info. If the previous component was a
directory, however, then the script goes up to and including the
current component, the path_info starting with the next component
ending with the end of the PATH. Confused? I was and still am, but
that was what I discovered.
DocumentRoot/dir1/dir2/dir3/file/some/thing/else
With the above, "/dir1/dir2/dir3/file" would be the "base_uri" and
"/some/thing/else" would be the path_info...but...
DocumentRoot/dir1/dir2/dir3/some/thing/else
will have "/dir1/dir2/dir3/some" as the script (yes, even though no
such thing exists on the filesystem) and "/thing/else" becomes the
path_info.
Odd behaviour, no? It just about killed me discovering it, but it's
what allows some handlers to work with clean urls (no file
extensions), so I'm not complaining. :-)
Daniel Popowich
---------------
http://home.comcast.net/~d.popowich/mpservlets/
