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'

Presumably all that is needed is to add ';' to 'safe' in the call that encodes PATH_INFO?

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.

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.

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?

If the RFC says they are safe it seems like we should include them in the safe list.

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.

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.