[issue13244] WebSocket schemes in urllib.parse

[Éric Araujo]

Éric Araujo <merwok at netwok.org> added the comment:

> Is urlparse meant to follow the generic URI RFC?
No, it predates it.

> IMHO, the patch at least should do the equivalent of
> urlparse.uses_fragment.extend(wsschemes)
> so users of urlparse can do the checking for fragment != "", required for ws/wss on their own.
That’s probably the most urllib.parse can do, sadly.

> Alternative: make this bug dependent on fixing urlparse for fragment rules in generic
> URI RFC and don't do anything until then?
I’m not sure we can fix urllib.parse that way, because of backward compatibility concerns.  We might change the default handling (i.e. when parsing an unknown scheme) to comply with the RFC, but I’d much rather have a new, clean module.

> This kind of suggestion has come up before
I recall some discussion on that too.  Maybe we should bring it up again on python-dev?  I think I read a discussion from years ago where Guido learned that the URI syntax was now generic and that urlparse’s design was obsolete.  There was also someone else who had a new module (was it Nick?) implementing the RFC.  IIRC this module was not discussed for inclusion because urllib gained many tests for RFC compliance and was thought Good Enough™.

> There is a number of limitations if want to make the parser generic for any scheme. The
> difficult thing being the parsing behavior and requirements as defined by scheme. 
I don’t understand what you need.  If I get the RFC correctly, the point is that parsing rules are the same for any and all schemes, then it’s up to the application to refuse some component or do any other scheme-specific handling of the components.  But the parsing of a URI into components is the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________