On Jul 27, 4:16 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > Ahh, I read the way the patch was being applied the wrong way > around. :-( > > Anyway, one potential reason why using req.uri may be bad is that > Apache does not do complete normalisation on it. Thus, one can get > repeating slashes which can cause the URL not to match a URL pattern > unless Django is at some point normalising it which I don't know if it > does or not. The req.path_info value on the other hand is normalised > properly.
Uh, for mod_python handler, Django is *already* using req.uri. Nearly everywhere in Django, we use request.path, which is filled from req.uri I'm making the change to request.META['PATH_INFO'] which isn't used anywhere (important) in Django anyway. > > Since I changed the url resolver to work with PATH_INFO rather than > > request.path, it won't break reverse resolving even for Request > > handlers which use SCRIPT_NAME. > From memory, one of the issues is that if one is going to have Django > understand the larger concept of SCRIPT_NAME, then it would be > desirable to be able to provide in urls.py URL patterns which are > anchored, but expressed relative to the SCRIPT_NAME mount point. This is exactly why I wrote the patch, and it does it without stepping on toes. URL patterns are archored That > way you can change what the mount point is and urls.py doesn't need to > be changed and everything in Django will just work. At the moment one > has to include the mount point in the URL patterns meaning you have to > change them if you change the mount point, thus making it hard to > provide a Django application as a relocatable WSGI application > component. > > One can't simply make such a change though such that this more > desirable behaviour would be the default, instead for backward > compatibility you would need to retain the existing behaviour and > require a switch to be added to enable the new behaviour. > > The other problem is that although with the better WSGI adapters > SCRIPT_NAME is provided correctly set for you automatically, in > mod_python one cannot actually deduce SCRIPT_NAME automatically with > the way the adapter works and so you push onto the user the need to > define the mount point manually a second time. > > What it comes down to is there are a few sides issues that really need > to be looked at at the same time and the simplistic change may not be > adequate to cover these or not result in the same behaviour on all > hosting solutions. > > Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
