Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#1516 closed defect (fixed)

No good access to SCRIPT_NAME

Reported by: ianb@… Owned by: darrint
Component: Core (Other) Version: master
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: UI/UX:

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 8 years ago.
patch to expose mod_python SCRIPT_NAME through request.META

Download all attachments as: .zip

Change History (24)

comment:1 Changed 9 years ago by adrian

  • Component changed from Admin interface to Core framework

comment:2 Changed 9 years ago by SmileyChris

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 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by mtredinnick

  • Owner changed from adrian to mtredinnick

comment:5 Changed 8 years ago by Simon G. <dev@…>

  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 8 years ago by mtredinnick

  • Triage Stage changed from Design decision needed to Accepted

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

comment:7 Changed 8 years ago by anonymous

  • Cc sam@… added

comment:8 Changed 8 years ago by anonymous

  • Cc jumo@… added

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

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

comment:10 Changed 8 years ago by anonymous

Related: #285

comment:11 Changed 8 years ago by anonymous

  • Owner changed from nobody to anonymous
  • Status changed from new to assigned

comment:12 Changed 8 years ago by darrint

  • Owner changed from anonymous to darrint
  • Status changed from assigned to new

comment:13 Changed 8 years ago by 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.

Changed 8 years ago by darrint

patch to expose mod_python SCRIPT_NAME through request.META

comment:14 Changed 8 years ago by darrint

  • Has patch set

comment:15 Changed 8 years ago by Simon G. <dev@…>

  • Triage Stage changed from Accepted to Ready for checkin

comment:16 Changed 8 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

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 Changed 8 years ago by ianb@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 Changed 8 years ago by mtredinnick

  • Has patch unset
  • Triage Stage changed from Ready for checkin to Accepted

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 Changed 8 years ago by anonymous

  • Cc hv@… added

comment:20 Changed 8 years ago by anonymous

  • Cc remco@… added

comment:21 Changed 8 years ago by anonymous

  • Cc matt@… added

comment:22 Changed 7 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from reopened to closed

(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 Changed 7 years ago by guettli

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