Code

Changes between Version 191 and Version 192 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
07/21/08 01:01:02 (6 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).