Changes between Version 191 and Version 192 of BackwardsIncompatibleChanges

Timestamp:

Jul 21, 2008, 3:01:02 AM (17 years ago)

Author:

Malcolm Tredinnick

Comment:

SCRIPT_NAME / PATH_INFO fixes

BackwardsIncompatibleChanges

@@ -67 +67 @@
  * [7967] July 18, 2008 [#Mergednewforms-adminintotrunk Merged newforms-admin into trunk]
  * [7971] July 18, 2008 [#Movednewformstoforms Moved django.newforms to django.forms]
+ * [8015] July 19, 2008 [#ChangedthewayURLpathsaredetermined Changed the way URL paths are determined]
 
 == Database constraint names changed ==
@@ -960 +961 @@
 
 {{{django.oldforms}}} is still available, but really you shouldn't be using it.
+
+== Changed the way URL paths are determined ==
+
+A long-awaited change was made in [8015] to the way Django works with HTTP URL
+strings. Web servers separate request URLs into two pieces, the `SCRIPT_NAME`
+and the `PATH_INFO` (there is also the `QUERY_STRING` for query parameters, but
+that is not relevant here). Prior to this change, Django was not using the
+`SCRIPT_NAME` at all, which caused a number of problems, including some
+portability issues.
+
+The main goal of this change is to make it possible to move a Django project
+from being served under, say, URLs of the form `/mysite/*` to
+`/my_other_site/*` without needing any changes in the ``URLConf`` file. The
+prefix (`/mysite/` and `/my_other_site/`) is the `SCRIPT_NAME` portion and
+Django only really needs to act on the `PATH_INFO` portion (the remainder of
+the URL).
+
+If your Django project handles all the URLs under `'/'`, you shouldn't have to
+make any changes in most cases. In all other cases, some alterations will be
+required. This change will have different effects for different web server
+setups. In all cases, however, you should remove the `SCRIPT_NAME` portion of
+the URLs from your `URLConf` file (they currently need to be included).
+
+=== mod_python ===
+
+If you are using mod_python and change nothing (not even `URLConf`), your code
+will still work and will be as non-portable as before. You may wish to leave
+things this way.
+
+However, if you wish to take advantage of the portability improvements, remove
+the script prefix from `URLConf` and set the prefix using the `django.root`
+option in mod_python's configuration. A configuration section that used to look
+like this:
+
+{{{
+<Location "/mysite/">
+   ...
+</Location>
+}}}
+
+would be altered to look like this:
+
+{{{
+<Location "/mysite/">
+   PythonOption django.root /mysite     # New line!
+   ...
+</Location>
+}}}
+
+Refer to Django's mod_python documentation for more information about this option.
+
+At the same time, you would edit your `URLConf` file to remove "/mysite" from
+the front of all the URLs.
+
+=== Apache + fastcgi ===
+
+If you configure your system using either of the Apache and fastcgi methods
+described in Django's fastcgi documentation, all you need to change is to
+remove the script prefix from the URL patterns in your `URLConf`.
+
+=== lighttpd + fastcgi (and others) ===
+
+Due to the way lighttpd is configured to work with fastcgi, it isn't possible
+to automatically construct the right script name value. This will be a problem
+is you are using the `{% url %}` template tag, or anything else that does
+reverse URL construction. To overcome this problem, you can use the
+`FORCE_SCRIPT_NAME` Django setting to force the value to whatever you want.
+This is a bit of a hacky solution, since it's requires changing the project
+settings every time you change the URL prefix. However, there's nothing that
+can be done about that in the general case, since Django is simply not passed
+the information it needs to determine the original URL (we want to use a small
+number of solutions that works for all web servers, rather than have to include
+25 special cases for each webserver and installation possibility).