[Web-SIG] Standardising containment.
py-web-sig at xhaus.com
Mon Sep 6 14:46:13 CEST 2004
>>1. Temporary storage/scratch directory.
On thinking further about the temp directory issue, I see now that it is
but one example of a class of problems relating to accessing physical
resources on the local machine.
The other main one that springs to mind is how WSGI applications
discover the file-system path name that corresponds to an URI.
CGI defines a "PATH_TRANSLATED" variable for this purpose, but
"PATH_TRANSLATED" is a poor solution to the problem, IMHO. In order to
explain what I mean, I'm going to go through an example.
Say I have an Apache installation, running CGI scripts. Assume that my
cgi-bin directory is at the root level of my document root, so my
document root looks like this (I'm using DOS path names, to illustrate a
DOCUMENT_ROOT = "c:\\htdocs\\"
CGI_BIN = "c:\\htdocs\\cgi-bin\\"
Now, say I receive a request for the following URI
The CGI variables for this request would be set as follows:-
SCRIPT_NAME = ""
PATH_INFO = "/images/stars.jpg"
PATH_TRANSLATED = "c:\\htdocs\\images\\stars.jpg"
And I want to introduce another variable, giving the path to the actual
CONTEXT_PATH = "c:\\htdocs\\cgi-bin\\my_application.py"
There are a few points to make here
1. The contents of the PATH_TRANSLATED variable are not necessarily what
I want. The standard definition for PATH_TRANSLATED is
PATH_TRANSLATED = DOCUMENT_ROOT + PATH_INFO, i.e.
PATH_TRANSLATED = 'c:\\htdocs\\' + '/images/stars.jpg', i.e.
PATH_TRANSLATED = 'c:\\htdocs\\images\\stars.jpg'
But what happens if I really want the path translated to a point
relative to my cgi script, for example, not relative to the document
root, i.e. what I really want is
PATH_TRANSLATED = CONTEXT_PATH + PATH_INFO, i.e.
PATH_TRANSLATED = 'c:\\htdocs\\cgi-bin\\application.py' + \
PATH_TRANSLATED = 'c:\\htdocs\\cgi-bin\\images\\stars.jpg'
2. Because of the platform (i.e. windoze, *nix) specific path names
returned for PATH_TRANSLATED, it is a hassle to write path manipulation
functions which will reliably deliver the final path name that I am
seeking. I could take the content of the PATH_TRANSLATED variable,
subtract PATH_INFO from it again (being careful to deal correctly with
"\" vs. "/"), and then work out my own path to the physical resource.
But this is just going to cause all kinds of portability problems.
Therefore I propose that WSGI somehow attempt to standardise access to
local resources on the disk. This could be done, perhaps, by providing a
function which resolves a logical URI to a physical resource. J2EE has
just such a function (surprise ;-), called ServletContext.getRealPath(),
which returns a file-system path name which is relative to the
CONTEXT_PATH mentioned above.
Without WSGI providing such local mapping functions, I don't see how
WSGI applications/middleware can map URIs to files, without undertaking
platform specific tricks.
I know it might look like I'm trying to drag WSGI into being more
container-oriented, more like J2EE for example. But I think the above
issues are sufficiently commonplace/universal that it is worth dealing
with them in a standardised way.
More information about the Web-SIG