Hi all!
Apologies if this I miss any conventions here, I've been working with Django for a long time now but this is my first message here. I'm here to chat about... *(Closed) Ticket #28609 <https://code.djangoproject.com/ticket/28609> - Request URI* I recently submitted a PR for a change which would make the original / raw URI of a request available to the development server's WSGI processing, as a parameter REQUEST_URI. This would allow the creation of WSGI middleware which needs access to this information that can be used universally between both development with devserver and production with Nginx or similar. Tim Graham suggested I post here if I disagree with it being flagged as wontfix on grounds of being something that would need to be discouraged as it enabled practices which are "not recommended". I do disagree as there was a lack of any explanation or data around how this is a universal bad and whilst I agree it could be misused if a developer were naive of the details of how it can be used, I don't think that is sufficient justification. Lack of access to this means using very basic WSGI middleware with Django requires hugely disproportionate levels of effort. (eg. some suggestions offered were "write an alternative runserver" or "replace it with Apache", both likely measured in days of work for our team, in order to avoid a trivial code change which took 5 minutes and brings the dev server further in line with other commonly used WSGI servers) *Reasoning* I would like to enable access to this parameter so that we can continue to use runserver when working locally on the API for https://www.broadsheet.com.au - an Australian city guide and mid-sized publisher. The specific use case we have for the raw URI is simple – there is a fairly universal form of search URL where spaces are replaced with + rather than URL encoded and in order to enable "+required" style binary operators, any literal + characters in the search query are URL encoded. (Attached is a screenshot of Google, Youtube, Bing, DuckDuckGo, Amazon all using this behaviour) So a search for "test search +banana" (typically a query which requests results for "test search" but limits results to pages including the word "banana") is encoded as test+search+%2Bbanana The benefits are clear: cleaner, human-friendly URLs, use of the same query format in places where spaces are used as delimiters, and maintaining use of + for binary modifiers, all with one syntax. The WSGI middleware which performs this replacement is trivial, but impossible to use with runserver currently as it does not provide the information. *Alternatives* It is not possible to implement this as a library or add-on as the dev server does not pass this data downstream. Replacing the development server is a high cost if it is for this reason alone. Alternative implementations within dev server could include full support for WSGI parameters, which seems excessive, or custom query string processing for this use case, which would be less compatible and may break other expected behaviours. *Potential Downsides* *Could be used inappropriately and may need to be cautioned against* I don't see why there is any need for it to be documented, it is providing optional access to an internal, as is the case with WSGI parameters in other web servers. That aside, I disagree that requiring caution invalidates the value in making a tool available to users. *REQUEST_URI is not actually a standard * This is true but it has become a de facto standard which is supported by most major web servers and in many cases enabled by default. Enabling it allows consistent WSGI middleware use. *Cluttering the WSGI environment* Given a very similar mechanism is being used to pass information like color highlighting status around it seems inconsistent to call this a concern. *The implementation is flawed* I would be very happy to receive feedback here, this is my first time submitting a patch / PR. *Code* See https://github.com/django/django/pull/9101 – the change involved is minimal, it simply has the dev server add the raw URI as a parameter in the WSGI environment so that middleware can use it: - return super(WSGIRequestHandler, self).get_environ() + environ = super(WSGIRequestHandler, self).get_environ() + environ[str("REQUEST_URI")] = self.path + return environ We have been using a branch with this change applied to 1.11 in both development and production since the PR was submitted, though the related WSGI middleware is not yet in production. Thanks for your time! Jay Lynch <https://lh3.googleusercontent.com/-CNGVs5lMux4/Wcx4cjKFaaI/AAAAAAAByz8/m61DbaHR3ug7oy-76RoxGUTooIaL6E24QCLcBGAs/s1600/test-search-plusbanana_s.jpg> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b5008401-5445-4b6c-9436-685584b1d0c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
