Changes between Version 191 and Version 192 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
07/21/2008 03:01:02 AM (7 years ago)
Author:
mtredinnick
Comment:

SCRIPT_NAME / PATH_INFO fixes

Legend:

Unmodified
Added
Removed
Modified
  • BackwardsIncompatibleChanges

    v191 v192  
    6767 * [7967] July 18, 2008 [#Mergednewforms-adminintotrunk Merged newforms-admin into trunk]
    6868 * [7971] July 18, 2008 [#Movednewformstoforms Moved django.newforms to django.forms]
     69 * [8015] July 19, 2008 [#ChangedthewayURLpathsaredetermined Changed the way URL paths are determined]
    6970
    7071== Database constraint names changed ==
     
    960961
    961962{{{django.oldforms}}} is still available, but really you shouldn't be using it.
     963
     964== Changed the way URL paths are determined ==
     965
     966A long-awaited change was made in [8015] to the way Django works with HTTP URL
     967strings. Web servers separate request URLs into two pieces, the `SCRIPT_NAME`
     968and the `PATH_INFO` (there is also the `QUERY_STRING` for query parameters, but
     969that is not relevant here). Prior to this change, Django was not using the
     970`SCRIPT_NAME` at all, which caused a number of problems, including some
     971portability issues.
     972
     973The main goal of this change is to make it possible to move a Django project
     974from being served under, say, URLs of the form `/mysite/*` to
     975`/my_other_site/*` without needing any changes in the ``URLConf`` file. The
     976prefix (`/mysite/` and `/my_other_site/`) is the `SCRIPT_NAME` portion and
     977Django only really needs to act on the `PATH_INFO` portion (the remainder of
     978the URL).
     979
     980If your Django project handles all the URLs under `'/'`, you shouldn't have to
     981make any changes in most cases. In all other cases, some alterations will be
     982required. This change will have different effects for different web server
     983setups. In all cases, however, you should remove the `SCRIPT_NAME` portion of
     984the URLs from your `URLConf` file (they currently need to be included).
     985
     986=== mod_python ===
     987
     988If you are using mod_python and change nothing (not even `URLConf`), your code
     989will still work and will be as non-portable as before. You may wish to leave
     990things this way.
     991
     992However, if you wish to take advantage of the portability improvements, remove
     993the script prefix from `URLConf` and set the prefix using the `django.root`
     994option in mod_python's configuration. A configuration section that used to look
     995like this:
     996
     997{{{
     998<Location "/mysite/">
     999   ...
     1000</Location>
     1001}}}
     1002
     1003would be altered to look like this:
     1004
     1005{{{
     1006<Location "/mysite/">
     1007   PythonOption django.root /mysite     # New line!
     1008   ...
     1009</Location>
     1010}}}
     1011
     1012Refer to Django's mod_python documentation for more information about this option.
     1013
     1014At the same time, you would edit your `URLConf` file to remove "/mysite" from
     1015the front of all the URLs.
     1016
     1017=== Apache + fastcgi ===
     1018
     1019If you configure your system using either of the Apache and fastcgi methods
     1020described in Django's fastcgi documentation, all you need to change is to
     1021remove the script prefix from the URL patterns in your `URLConf`.
     1022
     1023=== lighttpd + fastcgi (and others) ===
     1024
     1025Due to the way lighttpd is configured to work with fastcgi, it isn't possible
     1026to automatically construct the right script name value. This will be a problem
     1027is you are using the `{% url %}` template tag, or anything else that does
     1028reverse URL construction. To overcome this problem, you can use the
     1029`FORCE_SCRIPT_NAME` Django setting to force the value to whatever you want.
     1030This is a bit of a hacky solution, since it's requires changing the project
     1031settings every time you change the URL prefix. However, there's nothing that
     1032can be done about that in the general case, since Django is simply not passed
     1033the information it needs to determine the original URL (we want to use a small
     1034number of solutions that works for all web servers, rather than have to include
     103525 special cases for each webserver and installation possibility).
Back to Top