[Web-SIG] Standardising containment.

[Alan Kennedy]

[Alan Kennedy]
 >>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 
point)

DOCUMENT_ROOT = "c:\\htdocs\\"
CGI_BIN       = "c:\\htdocs\\cgi-bin\\"

Now, say I receive a request for the following URI

http://localhost/cgi-bin/my_application.py/images/stars.jpg

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 
script

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' + \
     '/images/stars.jpg', i.e.
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.

Regards,

Alan.