Hi Jay,
First, I'd like to say that your post was very nicely done. You did not miss
any conventions as far as I could see. I believe the only reason you got no
responses so far is that the issue is relatively fringe, and your message was
relatively long.
For the subject matter, though, it seems like your use case could be easily
served by using the stdlib's urllib.parse.quote_plus (or urllib.quote_plus, if
you're on Python 2) in your WSGI middleware. This should give you the
parameters of interest in the format you're looking for, without changing
Django's code, and while still enjoying the other benefits of URL
normalization. It seems you have considered only alternatives for passing the
original data into your code, and passed over the idea of reconstructing from
available data. Or, if this is what you meant by
> [...] custom query string
> processing for this use case, which would be less compatible and may break
> other expected behaviours.
I think you'll need to give a little more details for the argument to be
convincing.
Of your other comments, this caught my attention:
> *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.
If a feature is not documented, it means you should not rely on it.
Undocumented APIs are usually added because they are required for implementing
some documented feature; adding undocumented APIs on their own makes little
sense.
> That aside, I disagree that requiring caution
> invalidates the value in making a tool available to users.
Requiring caution, in and of itself, does not invalidate the value of making a
tool available to users -- but it does detract from it. We then ask ourselves
if we can recommend safer alternatives, and I believe I have.
Hope this helps,
Shai.
