On Thu, 2007-04-05 at 15:12 +0200, Bram - Smartelectronix wrote: > Malcolm Tredinnick wrote: > > On Thu, 2007-04-05 at 14:36 +0200, Bram - Smartelectronix wrote: > >> Hello everyone, > >> > >> > >> mod_python 3.3.1 > >> apache 2.0.52 > >> python 2.5 > >> django trunk, updated 5 minutes ago > >> > >> I go to http:/example.com/a/b/c/d/ and PATH_INFO returns /b/c/d/ losing > >> the first bit! This for any URL. > > > > We need some more information to determine if this is really a bug. Is > > Django responsible for everything under http://example.com/ or is it > > only serving resources under http://example.com/a/ ? In the latter case, > > the contents of PATH_INFO is correct. > > It's responsable for everything. Here's the apache config: > > <VirtualHost *:80> > ServerName XXXXXXXXX.com > ServerAlias django > AcceptPathInfo On > <Location "/"> > AllowOverride None > AuthName "XXXXXXX" > AuthUserFile XXXXXXXX > AuthType Basic > require valid-user > Order allow,deny > Allow from All > SetHandler python-program > PythonHandler django.core.handlers.modpython > SetEnv DJANGO_SETTINGS_MODULE XXX.settings > SetEnv LD_LIBRARY_PATH /usr/local/lib:/usr/local/pgsql/lib > PythonDebug On > PythonPath "['/opt/XXXX/'] + sys.path" > </Location> > <Location "/crossdomain.xml"> > Satisfy Any > Allow from All > </Location> > </VirtualHost>
This looks correct. Not sure why it isn't working, sorry. If you wanted to do some more poking around, we set up PATH_INFO in django/core/handlers/modpython.py, so you could put some debugging in there to see what the value we get from modpython is. I'm reluctant to think this would be a modpython problem, either ...something strange is going on though. I don't really have any obvious ideas about what could be going on here. I'm hesitant to point to really old email (given that Apache, modpython and Django are all actively developed technologies), but I did come across this: http://www.modpython.org/pipermail/mod_python/2003-July/013949.html which shows somebody else having a similar problem a few years back. Like I said, almost ancient history in Open Source terms, but it might give you something to search for more information about. > > It should be possible to join SERVER_NAME, SERVER_PORT, SCRIPT_NAMEand > > PATH_INFO together with the right separators and reconstruct the > > originally requested URL > > What's the best way to handle these kind of things...? For example, > after a login, one wants to be redirected to the correct page (the page > where you were before) so you set the "next" value. We using PATH_INFO > for it (and were so in the previous server where we had django > installed), and it worked just fine. The reason is works for your setup is that in setups like the one you have above, PATH_INFO by itself is basically the absolute portion of the URL, minus the server name. So for reasonably normal server configurations, you don't need to worry about SERVER_NAME and SERVER_PORT -- they will be attached by the client's browser and SCRIPT_NAME is empty. So using just PATH_INFO in your case is fine. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
