On Jul 27, 1:32 pm, SmileyChris <[EMAIL PROTECTED]> wrote: > On Jul 27, 2:51 pm, Graham Dumpleton <[EMAIL PROTECTED]> > wrote: > > > > > On Jul 27, 12:34 pm, SmileyChris <[EMAIL PROTECTED]> wrote: > > > > Reading through the mod_wsgi docs [1], I came to a section explaining > > > a problem with Django's core HTTP handling (search for "SCRIPT_NAME"). > > > > I have reopened #285 [2] and attached a patch which seemingly fixes > > > this. Could I please have some people more expert than me check it out > > > and provide some feedback? > > > > [1]http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango > > > [2]http://code.djangoproject.com/ticket/285 > >From memory, your patch to mod_python handler will possibly break > > things. This is because even when application is hosted at root of > > server, for certain setups path_info is not the whole URI but has a > > leading component missing because of how Apache matches URLs to > > resources. > > I understand that. That's why I propose changing PATH_INFO to match > mod_python_request_object.uri. Nothing in the previous discussion has > brought up why this is a bad idea. > In fact, ModPythonRequest currently sets path = self._req.uri > currently anyway.
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. > > There are also various other impacts on Django from making the changes > > which I cant remember right now. > > I read through all other references to PATH_INFO in Django. Nothing > else which jumps out at me that would break. > > 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. 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 -~----------~----~----~----~------~----~------~--~---
