Original request URI is not available to development server

[Jay Lynch]

When using the default development server using manage.py runserver the value settings.WSGI_APPLICATION may be used to configure the WSGI application which is executed.

If trying to use this feature to apply WSGI middleware, however, there is no way to access the original URI of the request, leaving the user unable to detect certain specific URLs they may wish to respond to, eg:

https://localhost:8000/search/test+search and
https://localhost:8000/search/test%2Bsearch appear identical to the WSGI application.

In production this is typically addressed with a uWSGI parameter passing the original request URI as REQUEST_URI, the WSGIRequestHandler has the information and can perform the same function.

[Tim Graham]

I'm not sure if Django should emulate the behavior. Maybe Graham Dumpleton can advise.

[Graham Dumpleton]

Some web servers do provide REQUEST_URI and to be compatible with them you could add it, but anyone using it should be well warned that it can be somewhat dangerous to rely on it.

The reason is that it is the raw path that appears in the HTTP request. This is before the web server would normalise it. It for example has not had repeating slashes removed, nor path elements such as ../. If a user doesn't clean up the URL they can put themselves at risk if they then use the path to do things like map to a filesystem path. That is, it could be used in path traversal attacks.

Often the reason people want access to REQUEST_URI is based on wanting to do things which are considered bad practice. For example, wanting to be able to see repeating slashes because they used a URI as part of the path. Or trying to see raw url encoding escape sequences such as in this case.

So you could definitely add it, but I would discourage people using it.

[Tim Graham]

Thanks. Graham. Given that explanation, I don't see a compelling reason to make the change in Django (adding a feature that's discouraged doesn't seem wise). Of course, users can write their own runserver implementation if they require it (or even use a different server in development, e.g. #21978). Jay, feel free to open a discussion on the DevelopersMailingList if you disagree with this conclusion. Thanks!

[Graham Dumpleton]

You can use mod_wsgi-express as a development server for Django if need access to REQUEST_URI.

• ​http://blog.dscpl.com.au/2015/04/using-modwsgi-express-with-django.html
• ​http://blog.dscpl.com.au/2015/05/using-modwsgi-express-as-development.html

Since it still uses Apache under the covers, Apache will set the variable.

[Jay Lynch]

Ignoring the other devserver benefits that it seems likely we'd miss out on, we don't use Apache anywhere else in the organisation at present, forcing everyone to use it in development just for this feels excessive.

I'll write up the use case properly so people can see the justification - I suspect it might not be as niche as it seems.

[Graham Dumpleton]

What devserver benefits do you think you are missing out on? Using mod_wsgi-express you can enable hot reloading. It also provides other support for development which the local devserver doesn't, such as integrated pdb debugger mode and various others things. Plus, you get ability to run under model closer to a production system, such as multi threading and/or multiprocessing, and no obscuring of issues because of things devserver does on startup that production deployments don't do. Just curious.

[Jay Lynch]

My mistake, sorry! I hadn't realised it was all that, I assumed based on the name it would just be an easier way to get started with mod_wsgi.

It looks quite cool. Unfortunately doesn't help much though, I don't really want to get Apache involved when we don't use it for anything else.

It feels like an awkward middle ground, adding a third incompatible environment - if we were going to go that far I'd rather go all the way and use Kubernetes to actually mirror production and have universally consistent environments. It's a while away on our current plan though, and not a project I'm keen on pulling forward for something this minor.

[Graham Dumpleton]

Hopefully when you look at Kubernetes, you will look at OpenShift as well. Can give lots of guidance on running Python apps in containers using OpenShift (Kubernetes) :-)

Anyway, getting off topic.

[Jay Lynch]

Replying to Graham Dumpleton:

Hopefully when you look at Kubernetes, you will look at OpenShift as well. Can give lots of guidance on running Python apps in containers using OpenShift (Kubernetes) :-)

Anyway, getting off topic.

OpenShift looks awesome, may well reach out when we do, cheers!