No good access to SCRIPT_NAME

[ianb@…]

While Django properly parses only PATH_INFO in a WSGI request, it doesn't give good access to SCRIPT_NAME, so applications cannot create proper URLs. A good application should always prefix all non-relative URLs with SCRIPT_NAME, so that should be easier to do that not to do.

In other frameworks this is sometimes done with a URL generation helper, so that url('foo', x=1) means SCRIPT_NAME+'/foo'+urllib.urlencode({'x': '1'})

[Chris Beaven]

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?

[ianb@…]

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.

[Malcolm Tredinnick]

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

[anonymous]

Related: #285

[darrint]

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.

[darrint]

patch to expose mod_python SCRIPT_NAME through request.META

[Malcolm Tredinnick]

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.

[ianb@…]

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).

[Malcolm Tredinnick]

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.

[Malcolm Tredinnick]

(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.