[issue13244] WebSocket schemes in urllib.parse

Senthil Kumaran added the comment: Reading both the RFCs and requirements, I see that this is already taken care. Note: we are actually have unencoded fragment like # and RFCs talk about fragments with # character only. If you want the behavior of parse with urlencoded to match un-urlencoded o

[issue13244] WebSocket schemes in urllib.parse

Tobias Oberstein added the comment: FWIW, WebSocket URL parsing is still wrong on Python 2.7.6 - in fact, it's broken in multiple ways: >>> from urlparse import urlparse >>> urlparse("ws://example.com/somewhere?foo=bar#dgdg") ParseResult(scheme='ws', netloc='example.com', path='/somewhere', par

[issue13244] WebSocket schemes in urllib.parse

Martin Panter added the comment: Suspect this is now fixed in a generic way by Issue 9374. The fix seems to be in 2.7, 3.2 and 3.3. $ python3.3 Python 3.3.2 (default, May 16 2013, 23:40:52) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from url

[issue13244] WebSocket schemes in urllib.parse

Éric Araujo added the comment: This is not committed to any branch yet. -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ __

[issue13244] WebSocket schemes in urllib.parse

Tobias Oberstein added the comment: Is that patch supposed to be in Python 2.7.2? If so, it doesn't work for "ws": "ws://example.com/somewhere?foo=bar#dgdg" F:\scm\Autobahn\testsuite\websockets\servers>python Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32

[issue13244] WebSocket schemes in urllib.parse

Changes by Éric Araujo : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue13244] WebSocket schemes in urllib.parse

Senthil Kumaran added the comment: Similar issue Issue7904 and 7da7f9bfdaac wherein the accepted way to parse x-newscheme://foo.com/stuff was added. Does the new ws:// scheme not fall under that? -- ___ Python tracker

[issue13244] WebSocket schemes in urllib.parse

Éric Araujo 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

[issue13244] WebSocket schemes in urllib.parse

Tobias Oberstein added the comment: The patch as it stands will result in wrong behavior: +self.assertEqual(urllib.parse.urlparse("ws://example.com/stuff#ff"), + ('ws', 'example.com', '/stuff#ff', '', '', '')) The path component returned is invalid for ws/wss an

[issue13244] WebSocket schemes in urllib.parse

Senthil Kumaran added the comment: This kind of suggestion has come up before and easy fix is to add individual schemes as the patch does. 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 def

[issue13244] WebSocket schemes in urllib.parse

Jyrki Pulliainen added the comment: > Alternative: make this bug dependent on fixing urlparse for fragment rules in > generic URI RFC and don't do anything until then? I'd go with this, even though it probably would be a lot bigger work than this. What's Éric's take on this approach?

[issue13244] WebSocket schemes in urllib.parse

Tobias Oberstein added the comment: > I’d say that urlparse should raise an exception when a ws/wss URI contains a > fragment part. Yep, better. > I’m not sure this will be possible; from a glance at the source and a quick > test, urlparse will happily break the Generic URI Syntax RFC and re

[issue13244] WebSocket schemes in urllib.parse

Éric Araujo added the comment: > # must always be escaped, both in path and query components. Agreed. This just follows from the Generic URI Syntax RFC, it’s not specific to WebSockets. > And further: urlparse should raise an exception upon unescaped # within URLs > from ws/wss schemes. I’d