On Thu, 2009-07-23 at 13:19 +1000, Graham Dumpleton wrote: > 2009/7/23 Malcolm Lalkaka <[email protected]>: > >> > And here's the output when I request this application from the web > >> > server. > >> > > >> > ----- http://<domain>/~mlalkaka/wsgitest/ ----- > >> > REQUEST_URI: /~mlalkaka/wsgitest/ > >> > SCRIPT_NAME: /~mlalkaka/wsgitest > >> > >> That is okay. I was getting my logic round the wrong way. The problem > >> case is where people were expecting SCRIPT_NAME to reflect that WSGI > >> application was mounted at root of web site. In your case you don't > >> want that, so all is okay. > > > > I didn't even know this information was available. This is great, in > > fact, because it can be used to solve one of my other problems. Since > > the WSGI applications are hosted at 'dynamic' URLs, the web applications > > never know their absolute URL. I can never hard-code any absolute URL > > links on web pages. I've been using a hacky system, where I check in > > which directory on the server the WSGI application is hosted, and then, > > based on that, guess at what the request URI is, so that I can build an > > absolute link to put in web pages. > > > > But with this, I don't need to do that anymore. Thanks, again! Is there > > some documentation on the WSGI site about these two WSGI environment > > variables? I want to make sure that they will always be what I expect > > them to be. > > WSGI inherits what CGI is supposed to provide. See: > > http://hoohoo.ncsa.illinois.edu/cgi/env.html > > REQUEST_URI is Apache specific and other WSGI servers will not > necessarily provide it. It also is the original request URI and what > is in the end used to map to application may be different if Apache > rewrite rules in play. As a rule, you shouldn't ever use REQUEST_URI. > > One can quite happily use SCRIPT_NAME however and under normal > conditions it would be the mount point of the WSGI application.
Ok, I'll stick to using SCRIPT_NAME, if I have to use anything at all. > Also see: > > http://www.python.org/dev/peps/pep-0333/#url-reconstruction > > Any decent web framework should provide a function that work along > those lines but which allows you to provide as input a URL relative to > your application route and thereby construct a full URL, with > protocol, host, port etc. This assumes that when using proxy front > ends that tweaks are in place to pass through original host connection > information. It turns out Django, the web framework I'm using, does have this functionality, through the url template tag and the django.core.urlresolvers module. So I won't even need to use SCRIPT_NAME directly. Just thought I'd mention that for the mailing list record. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
