urllib.parse tries to special-case params, which have been dropped from the general URI syntax back in RFC 2396 (16 years ago).

In most cases this can be worked around by reconstructing the path from both path and params; however this fails for paths that *end* in a semicolon (because it's not possible to distinguish an empty param from an absent param).

Hello Julian,

Can you please provide a test case of this parsing misbehavior? It might be easier to identify with the testcase. Better yet, the patch changing the parsing logic will help identify if we are dealing with any regression.

Thanks!

An example URI for this issue is:

  http://example.com/;

The RFC 3986 path component for this URI is "/;".

After using urllib's parse function, how would you know?

(I realize that changing behavior of the existing API may cause problems, but this is an information loss issue). One ugly, but workable way to fix this would be to also provide access to a "RFC3986path" component.

On Saturday, January 3, 2015 at 12:46 AM, Julian Reschke wrote:
> An example URI for this issue is:
> 
> http://example.com/;
> 
> The RFC 3986 path component for this URI is "/;". 
I think, a stronger argument might be desirable (something like a real world scenario wherein a web app can construct such an entity) for a path that ends in a semi-colon for breaking backwards compatibility. 

OTOH, making it RFC 3986 compliant itself is a good enough argument, but it should be applied in total and the whole module should be made compatible instead of pieces of it. There is a bug to track it. You can mention this instance for the desired behavior in that ticket too (and close this ticket if this desired behavior is a subset).

Marking as Python 3 since you mentioned urllib.parse, rather than just urllib. However you need to be more specific. We already have a urllib.parse.urlsplit() function which seems to do what you want:

>>> urllib.parse.urlsplit("http://example.com/;").path
'/;'

I see that the “params” bit can be dropped by urljoin(). My proposal in Issue 22852 could probably be adapted to help with that.

If the problem was just Julian not being aware of urlsplit(), there is not much to be done for this bug.