classification
Title: request_uri method of wsgiref module does not support RFC1808 params.
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: orsenthil Nosy List: Timothy.Gates, orsenthil, pje, r.david.murray
Priority: normal Keywords: patch

Created on 2010-12-21 23:42 by Timothy.Gates, last changed 2010-12-29 14:18 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
issue10753.patch orsenthil, 2010-12-29 06:32
Messages (8)
msg124468 - (view) Author: Timothy Gates (Timothy.Gates) Date: 2010-12-21 23:42
Consider the URL making use of the RFC1808 param syntax...

http://www/path;cookie=1234

The entire section '/path;cookie=1234' is passed in as PATH_INFO and so under the request_uri implementation it will be quoted

> import wsgiref
> wsgiref.request_uri({'wsgi.url_scheme': 'http', 'HTTP_HOST': 'www', 'PATH_INFO': '/path;cookie=1234'})
'http://www/path%3Bcookie%3D1234'
msg124469 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-22 00:20
Presumably all that is needed is to add ';' to 'safe' in the call that encodes PATH_INFO?
msg124587 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-24 03:52
On Wed, Dec 22, 2010 at 12:20:24AM +0000, R. David Murray wrote:
> Presumably all that is needed is to add ';' to 'safe' in the call
> that encodes PATH_INFO?

Well, that is what is required in order for the quote function call to
ignore it, but I am not sure what it the intention passing
/path;params as the PATH_INFO and how it is useful in wsgiref context.

Also there is this note in the PEP 333

Note that such a reconstructed URL may not be precisely the same URI
as requested by the client. Server rewrite rules, for example, may
have modified the client's originally requested URL to place it in a
canonical form.
msg124592 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-24 04:52
Well, if the parameters aren't part of the path info, what are they part of?

They are passed as part of path info now, just incorrectly encoded.  I haven't found anything so far to make me think they belong anywhere else.
msg124721 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-27 18:05
I agree that semi-colon separated segments (params) can be in PATH portion of the url. I was trying to find out, how a path;params would be useful in wsgiref request_uri's PATH_INFO variable , wherein I assumed PATH_INFO should be a file-system path or a method name.

After doing a bit of study, I find that ';' can be part of PATH_INFO in wsgiref compliant servers. I find a couple of bugs related to issues where ';' in PATH_INFO is not handled properly in other systems - http://bit.ly/g4UHhX

So, I think, we can have ';' as safe character so that it is prevented from quoting.

Also, RFC 3986 in Section 3.3 says that ';' '=' and ',' can be considered safe in the PATH component. Should we include those too?
msg124723 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-27 18:35
If the RFC says they are safe it seems like we should include them in the safe list.
msg124844 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-29 06:32
r87564 (py3k), r87565 (release31-maint) and r87566 (release27-maint).

Just a Note.

These kind of minor changes have many a times resulted in regression for developers who relied upon previous bad behavior.  I have added NEWS to explain this change clearly and hopefully it gets noticed and accommodate this change in their code.

Thanks.
msg124850 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-29 14:18
In this case I think it is safe enough, since it only results in the ;,= not getting encoded.  If an application were doing anything with the encoded chars, it would probably be decoding them, and now that step will simply become a noop.  Of course, breakage is always possible, but this change seems worth what appears to be a relatively small risk.
History
Date User Action Args
2010-12-29 14:18:32r.david.murraysetnosy: pje, orsenthil, r.david.murray, Timothy.Gates
messages: + msg124850
2010-12-29 06:32:31orsenthilsetstatus: open -> closed
files: + issue10753.patch

assignee: orsenthil
keywords: + patch
nosy: pje, orsenthil, r.david.murray, Timothy.Gates
messages: + msg124844
resolution: fixed
stage: resolved
2010-12-27 18:35:28r.david.murraysetnosy: pje, orsenthil, r.david.murray, Timothy.Gates
messages: + msg124723
2010-12-27 18:05:13orsenthilsetnosy: pje, orsenthil, r.david.murray, Timothy.Gates
messages: + msg124721
2010-12-24 04:52:33r.david.murraysetnosy: pje, orsenthil, r.david.murray, Timothy.Gates
messages: + msg124592
2010-12-24 03:52:16orsenthilsetnosy: pje, orsenthil, r.david.murray, Timothy.Gates
messages: + msg124587
2010-12-22 00:20:21r.david.murraysetnosy: + pje, r.david.murray, orsenthil

messages: + msg124469
versions: - Python 3.3
2010-12-21 23:42:24Timothy.Gatescreate