No good access to SCRIPT_NAME

Adrian has put a lot of work into a reverse URLconf script (see the google group discussion here: http://tinyurl.com/lbemo).

It's not finished yet, but is this a step towards what you want?

If the URL reversing uses SCRIPT_NAME as the base, that would certainly help. Though the value of SCRIPT_NAME should still be available *somewhere* for people who want to generate links manually. Any app that is even slightly portable should be using SCRIPT_NAME -- directly or indirectly -- for every non-relative URL it generates.

We should be filling in SCRIPT_NAME. Not to do so is running against normal CGI-variables practice.

Related: #285

It appears to me that wsgi apps get SCRIPT_NAME through meta, but this was turned off on purpose for mod_python. I'm attaching a patch for the modpython.py handler which exposes the mod_python view of SCRIPT_NAME. If this isn't what was wanted, mod_python allows setting of SCRIPT_NAME via PythonOption?.

patch to expose mod_python SCRIPT_NAME through request.META

One good reason not to set SCRIPT_NAME for mod_python is that it's likely to be incorrect. This was confirmed recently by Graham Dumpleton.

We do want to make Django more accurate in this respect, including using SCRIPT_NAME (or a manually configured proxy) when constructing every URL and doing URL parsing. However, it needs a more holistic solution than presented here. Supplying a likely-to-be-inaccurate value in the environment is not helping the user. Closing as wontfix for that reason, although we are working on the larger problem.

Can you fix SCRIPT_NAME in the mod_python adapter? SCRIPT_NAME means something very specific -- that mod_python sets it incorrectly doesn't mean you have to propagate that incorrectness or ignore its meaning.

This came up in CherryPy? too, where they didn't want to use SCRIPT_NAME because it wasn't always correct. But I don't understand why you can't just make it correct (e.g., overwriting it early on using a configuration parameter).

Okay, I closed this too quickly. We are going to do exactly as you say: make it work throughout (and it will be called SCRIPT_NAME). I'm actually rejecting the patch out of hand, because it's wrong. The ticket is something we're going to do. I confused problem and solution.

I need to read more carefully. Sorry.

(In [8015]) Changed/fixed the way Django handles SCRIPT_NAME and PATH_INFO (or equivalents). Basically, URL resolving will only use the PATH_INFO and the SCRIPT_NAME will be prepended by reverse() automatically. Allows for more portable development and installation. Also exposes SCRIPT_NAME in the HttpRequest instance.

There are a number of cases where things don't work completely transparently, so mod_python and fastcgi users should read the relevant docs.

Fixed #285, #1516, #3414.