mod_python: Why use req.uri, not req.path_info?
Forest Bond
I was trying to set up a site at a URL that is not at the root of the web
server. I am using mod_python, and my apache config looks similar to that
included with the relevant django documentation, which I'll duplicate here:
[from http://www.djangoproject.com/documentation/modpython/]
--------------------------------------------------------------------------------
<Location "/mysite/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonDebug On
</Location>
--------------------------------------------------------------------------------
That documentation correctly adds:
"Restart Apache, and any request to /mysite/ or below will be served by Django.
Note that Django’s URLconfs won’t trim the “/mysite/” — they get passed the full
URL."
So, the problem is that I have to update my urls.py to include the /mysite/
prefix in all URLs.
This is clearly not very DRY. For me, the biggest pain is that I'm actually
trying to deploy the same project at two different URLs (with different host
parts, too). (I have reasons to do this, although they aren't incrediblly
relevevant, so I won't go into that). Since my urls.py has to be so aware of my
apache config, I can't do things the way I want to and use the apache config to
enable & disable access to different application fragments under each base URL.
All of this could be fixed by simply changing ModPythonRequest
(django/core/handlers/modpython.py) to use req.path_info instead of req.uri. Is
there any reason not to do that (aside from breaking backwards compatibility)?
If a change like this is in order, I assume it will be made prior to 1.0. What
do people think about this? I didn't get much from a Google search, but it
seems hard to believe that it hasn't come up yet in the past.
If this can be solved using some crazy middleware-type solution, I'd be open to
that. It doesn't seem ideal to me for the current behavior to be the default,
though.
-Forest
Max Battcher
> So, the problem is that I have to update my urls.py to include the /mysite/
> prefix in all URLs.
>
>
> If this can be solved using some crazy middleware-type solution, I'd be open to
> that. It doesn't seem ideal to me for the current behavior to be the default,
> though.
Fixing the URLs redundancy is easy, create a new mysite_urls.py and
mysite_settings.py for the site at /mysite/. In mysite_settings put
the ROOT_URLCONF to mysite_urls.py and mysite_urls just needs the
simple url pattern ('^mysite/', include('urls.py')) to match the new
"global" prefix. You can do the same for other sites or it would be
easy enough to use a more generic prefix regex and share the same
prefix matching urls and trade off a little regex efficiency... Each
site should have its own settings anyway, at the very least for
separate SITE_IDs. (Settings is just python, so you can easily
inherit some base settings with a line like ``from base_settings
import *``.)
--
--Max Battcher--
http://www.worldmaker.net/
Forest Bond
Yes, that would work, and I've done similar things for other situations, but I'm
really just having a hard time seeing why django even cares about /mysite/ at
all.
The solution you mention here requires me to add two python source files to my
tree, and in the end, if I want to move my app to a different URL, I still have
to change both the apache configuration and mysite_urls.py. It just shouldn't
be that complicated, should it?
I figure I should just have to change the apache configuration, which is where
django instances are mapped to URLs. urls.py is where django views are mapped
to sub-urls of the main django instance, right?
-Forest
Marty Alchin
> (django/core/handlers/modpython.py) to use req.path_info instead of req.uri. Is
> there any reason not to do that (aside from breaking backwards compatibility)?
I'm certainly no expert in this area, but keep in mind that mod_python
is just one available option for deploying Django. There would have to
be some equivalent in the other situations, such as FastCGI, in order
for this to be taken seriously.
Above all, I think the intent here is consistency. It's hardly a Good
Idea to have one way to lay out your URLs for mod_python and a
different one for the rest. I'm not saying it's impossible to do (I
don't know enough to say that), just that they all need to work the
same way.
So if mod_python ends up being the only one that supports this, I'd be
very opposed to making changes for the mod_python case.
-Gul
Forest Bond
>
> On 7/10/07, Forest Bond <for...@alittletooquiet.net> wrote:
> > All of this could be fixed by simply changing ModPythonRequest
> > (django/core/handlers/modpython.py) to use req.path_info instead of req.uri.
> > Is there any reason not to do that (aside from breaking backwards
> > compatibility)?
>
> I'm certainly no expert in this area, but keep in mind that mod_python
> is just one available option for deploying Django. There would have to
> be some equivalent in the other situations, such as FastCGI, in order
> for this to be taken seriously.
Is this kind of change relevant for all of the other methods? I have not used
any of the others. Certainly, if a change like this is made, the other handlers
would need to be updated for consistency. I agree with you there.
If there was some way to tell apache/mod_python to pass the URL sans the prefix
in to django, I would simply do that. I have not been able to find any such
thing.
But really, the prefix is a deployment detail that I should be able to make my
application agnostic to. I don't have to include my domain name in my urls.py,
why should I have to include a prefix?
Maybe this behavior could be determined by something in settings.py.
-Forest
doug.na...@gmail.com
> signature.asc
> 1KDownload
Your applications should be root url agnostic. Each app should have
its own urls.py and the root site urls.py (and its accompanying
settings.py) should have the site specific information including the
root. Then the apps are included in the site specific root urls.py
You might want to check out this thread for more information:
http://groups.google.com/group/django-developers/browse_thread/thread/e9d92bceab679f6a/#
Here is an example of having the root urls.py get its bases from
settings.py (though not a very good one):
https://svn.python.org/conference/django/trunk/pycon/urls.py
Hope that helps!
-Doug
Forest Bond
> On Jul 10, 5:02 pm, Forest Bond <for...@alittletooquiet.net> wrote:
> > Is this kind of change relevant for all of the other methods? I have not used
> > any of the others. Certainly, if a change like this is made, the other handlers
> > would need to be updated for consistency. I agree with you there.
> >
> > If there was some way to tell apache/mod_python to pass the URL sans the prefix
> > in to django, I would simply do that. I have not been able to find any such
> > thing.
> >
> > But really, the prefix is a deployment detail that I should be able to make my
> > application agnostic to. I don't have to include my domain name in my urls.py,
> > why should I have to include a prefix?
> >
> > Maybe this behavior could be determined by something in settings.py.
> >
> > -Forest
> >
> > signature.asc
> > 1KDownload
>
> Your applications should be root url agnostic. Each app should have
> its own urls.py and the root site urls.py (and its accompanying
> settings.py) should have the site specific information including the
> root. Then the apps are included in the site specific root urls.py
Pardon me for mis-speaking. I meant that I felt my site-specific urls.py should
be root URL agnostic. Actually, I am pushing for that URL prefix to only be
mentioned in the apache config. While I appreciate your assistance in helping
me do things how you would do them, I am really hoping someone can answer my
question: why use req.uri instead of req.path_info? Is there a good reason?
> You might want to check out this thread for more information:
> http://groups.google.com/group/django-developers/browse_thread/thread/e9d92bceab679f6a/#
A quick scan of that thread doesn't turn up much relevant info. What am I
looking for there?
> Here is an example of having the root urls.py get its bases from
> settings.py (though not a very good one):
> https://svn.python.org/conference/django/trunk/pycon/urls.py
Thanks; I won't be needing further assistance with Python, however.
-Forest
Kevin Menard
whatever, had to care where it was being deployed. Or rather, why one
has to go out of his way to make URLs work in different contexts.
Coming from the Java world, this was something I had never run into,
and I was pretty put off by it. I could map an application to any
context and things just work. On IRC, I have seen this as a recurring
"problem" over the past two years of my participation there. Most
people respond with "configure a new subdomain *shrug*", which clearly
is not appropriate for all circumstances. Alas, that's exactly what
I've deferred to for simplicity's sake.
So, if the change is simple enough to make, I'm +1 (non-binding) for it.
--
Kevin
On 7/10/07, Forest Bond <for...@alittletooquiet.net> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGk8pFRO4fQQdv5AwRArNzAJ9jur9ar1+vVtAgR2/+EaGsgyksvgCfZCub
> 3P41eIxMRdCx/5pO7xGNCQA=
> =2t4f
> -----END PGP SIGNATURE-----
>
>
Graham Dumpleton
> On 7/10/07, Forest Bond <for...@alittletooquiet.net> wrote:
>
> > All of this could be fixed by simply changing ModPythonRequest
> > (django/core/handlers/modpython.py) to use req.path_info instead of req.uri. Is
> > there any reason not to do that (aside from breaking backwards compatibility)?
>
> I'm certainly no expert in this area, but keep in mind thatmod_python
> is just one available option for deploying Django. There would have to
> be some equivalent in the other situations, such as FastCGI, in order
> for this to be taken seriously.
>
> Above all, I think the intent here is consistency. It's hardly a Good
> different one for the rest. I'm not saying it's impossible to do (I
> don't know enough to say that), just that they all need to work the
> same way.
>
> very opposed to making changes for themod_pythoncase.
Django has problems in related areas with CGI and WSGI type hosting
solutions as well. For example, mod_wsgi, FastCGI, SCGI, and CGI. This
is because Django ignores SCRIPT_NAME variable which defines the mount
point of the application. A well behaved WSGI application should not
be ignoring it and should really allow URLs to be expressed relative
to the mount point, thus making it easily relocatable. Where a full
absolute URL is required, an application should be using SCRIPT_NAME
in part of the calculations.
I grumble a bit about the problems in:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
Referenced in there are a number of Django tickets which relate to the
problem.
http://code.djangoproject.com/ticket/285
http://code.djangoproject.com/ticket/2407
http://code.djangoproject.com/ticket/1516
Thus, not only mod_python is affected and since development server
expects things to be mounted at root and this is only thing not
possibly affected, would seem that no solution quite works as one
would expect where not mounted at root. FWIW, I personally don't see
using mod_rewrite hacks as a suitable solution.
Graham
Malcolm Tredinnick
[...]
> Django has problems in related areas with CGI and WSGI type hosting
> solutions as well. For example, mod_wsgi, FastCGI, SCGI, and CGI. This
> is because Django ignores SCRIPT_NAME variable which defines the mount
> point of the application
I guess this is the best post to reply to in the thread: Most of the
problems mentioned here sort of hinge of this issue that Graham raises.
At some point I want to work out a fix for that in a way that doesn't
break every existing installation on the planet (I have a bad feeling
it's going to add another setting, unfortunately). If I was ever rude
enough to create a "most annoying things about Django" list, this would
be near the top for me, but it's a matter of finding time to work on it
and coming up with a non-sucky design.
So, yeah, it's a wart and I personally would like to fix it. Before 1.0.
It's certainly on my list.
Regards,
Malcolm
--
Depression is merely anger without enthusiasm.
http://www.pointy-stick.com/blog/
Yuri Baburov
Check out http://www.djangosnippets.org/snippets/307/
I think it's best solution for this problem. I'm already happy.
Looking forward to including this in django itself.
On Tue, 2007-07-10 at 23:45 +0000, Graham Dumpleton wrote:
[...]
> Django has problems in related areas with CGI and WSGI type hosting
> solutions as well. For example, mod_wsgi, FastCGI, SCGI, and CGI. This
> is because Django ignores SCRIPT_NAME variable which defines the mount
> point of the application
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
doug.na...@gmail.com
work with sitemap, absolute rul's and reverse url lookups? doesn't it
break all of those, or am I missing something?
-Doug
Yuri Baburov
Can't do experiments now, but my admin interface (django trunk) began
to work right after this middleware addition, that meant reverse url
were resolved somehow.
Snippet exactly change req.uri to req.script_name+req.uri, that gives
req.path. Am I right? If I'm not, you can change it to set
request.path to what you need.
Snippet change will be absolutely transparent if request.path is not
cached in some variable.
Second, I feel req.path_info wouldn't help you, and you guys
apparently need something like this anyway:
SERVER_PREFIX = '/prefix' # or os.environ('SOME_MOD_PYTHON_VAR')
ROOT_URLCONF = 'urlconf'
PREFIXED_URLCONF = 'urlconf2'
in ROOT_URLCONF:
urlpatterns = patterns('', ('^'+SERVER_PREFIX, include(PREFIXED_URLCONF))
Please correct me if I misunderstood something.
2007/7/12, Forest Bond <for...@alittletooquiet.net>:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGlXNSRO4fQQdv5AwRAobkAKDKQp7pT4LxMAtc3WztwGRQ68pDLgCglc38
> Obe9eiSeRceYWS7GNEXqIxc=
> =gRcE
> -----END PGP SIGNATURE-----
Forest Bond
> Can't do experiments now, but my admin interface (django trunk) began
> to work right after this middleware addition, that meant reverse url
> were resolved somehow.
> Snippet exactly change req.uri to req.script_name+req.uri, that gives
> req.path. Am I right? If I'm not, you can change it to set
> request.path to what you need.
Yeah, I think my urls.py situation would be resolved by setting request.path to
req.path_info, but that would break {% url %} and admin pages for me, I believe,
although I haven't put too much thought into it yet.
Really, as Malcolm & Graham pointed out, this is something that Django needs a
little help with...
Thanks for pointing out where the hack is best placed, though :)
-Forest