Opened 18 years ago

Closed 16 years ago

Last modified 16 years ago

#1516 closed defect (fixed)

No good access to SCRIPT_NAME

Reported by: ianb@… Owned by: darrint
Component: Core (Other) Version: dev
Severity: normal Keywords:
Cc: ianb@…, sam@…, jumo@…, densetsu.no.ero.sennin@…, remco@…, matt@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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'})

Attachments (1)

patch.txt (751 bytes ) - added by darrint 17 years ago.
patch to expose mod_python SCRIPT_NAME through request.META

Download all attachments as: .zip

Change History (24)

comment:1 by Adrian Holovaty, 18 years ago

Component: Admin interfaceCore framework

comment:2 by Chris Beaven, 18 years ago

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?

comment:3 by ianb@…, 18 years ago

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.

comment:4 by Malcolm Tredinnick, 17 years ago

Owner: changed from Adrian Holovaty to Malcolm Tredinnick

comment:5 by Simon G. <dev@…>, 17 years ago

Triage Stage: UnreviewedDesign decision needed

comment:6 by Malcolm Tredinnick, 17 years ago

Triage Stage: Design decision neededAccepted

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

comment:7 by anonymous, 17 years ago

Cc: sam@… added

comment:8 by anonymous, 17 years ago

Cc: jumo@… added

comment:9 by Densetsu no Ero-sennin <densetsu.no.ero.sennin@…>, 17 years ago

Cc: densetsu.no.ero.sennin@… added

comment:10 by anonymous, 17 years ago

Related: #285

comment:11 by anonymous, 17 years ago

Owner: changed from nobody to anonymous
Status: newassigned

comment:12 by darrint, 17 years ago

Owner: changed from anonymous to darrint
Status: assignednew

comment:13 by darrint, 17 years ago

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.

by darrint, 17 years ago

Attachment: patch.txt added

patch to expose mod_python SCRIPT_NAME through request.META

comment:14 by darrint, 17 years ago

Has patch: set

comment:15 by Simon G. <dev@…>, 17 years ago

Triage Stage: AcceptedReady for checkin

comment:16 by Malcolm Tredinnick, 17 years ago

Resolution: wontfix
Status: newclosed

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.

comment:17 by ianb@…, 17 years ago

Resolution: wontfix
Status: closedreopened

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

comment:18 by Malcolm Tredinnick, 17 years ago

Has patch: unset
Triage Stage: Ready for checkinAccepted

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.

comment:19 by anonymous, 16 years ago

Cc: hv@… added

comment:20 by anonymous, 16 years ago

Cc: remco@… added

comment:21 by anonymous, 16 years ago

Cc: matt@… added

comment:22 by Malcolm Tredinnick, 16 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:23 by Thomas Güttler, 16 years ago

Cc: hv@… removed
Note: See TracTickets for help on using tickets.
Back to Top