[issue40938] urllib.parse.urlunsplit makes relative path to absolute (http:g -> http:///g)

Open Close added the comment: I tried hard (even read RFC1630), but I think no. -- ___ Python tracker <https://bugs.python.org/issue40938> ___ ___ Python-bug

[issue40938] urllib.parse.urlunsplit makes relative path to absolute (http:g -> http:///g)

Open Close added the comment: 'http:///g' has absolute path '/g', and as urljoin shows: >>> urljoin('http://a/b/c/d', 'http:///g') 'http://a/g' # 'a' is netloc So you are proposing third interpreta

[issue40938] urllib.parse.urlunsplit makes relative path to absolute (http:g -> http:///g)

Open Close added the comment: hello, @jaswdr, but I can't understand what's wrong with my point. What is 'the expected behaviour'? -- ___ Python tracker <https://bug

[issue41002] HTTPResponse.read with amt is slow

Open Close added the comment: @bmerry yah, sorry, don't bother. I have mistaken. (I thought somehow 'MB/s' was simple speed, not std). I confirmed your tests. httpclient-read: 2504.5 ± 10.6 MB/s httpclient-read-length: 871.5 ± 4.9 MB/s httpclient-read-raw: 25

[issue41002] HTTPResponse.read with amt is slow

Open Close added the comment: @bmerry check the test results again. (perhaps 'MB/s's are wrong). httpclient-read: 3019.0 ± 63.8 MB/s httpclient-read-length: 1050.3 ± 4.8 MB/s --> httpclient-read-raw: 3150.3 ± 5.3 MB/s --> socket-read: 3134.4 ± 7.9 MB/s ---

[issue40594] urljoin since 3.5 incorrectly filters out double slashes

Open Close added the comment: To Senthil Kumaran: https://bugs.python.org/issue40594#msg371092 > As far as I know, the browsers remove them, combine them as a single URL. > (Tested on Chrome with some URLs to confirm on June 2020) How did you test them? -- nosy:

[issue40938] urllib.parse.urlunsplit makes relative path to absolute (http:g -> http:///g)

Change by Open Close : -- components: +Library (Lib) ___ Python tracker <https://bugs.python.org/issue40938> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22852] urllib.parse wrongly strips empty #fragment, ?query, //netloc

Open Close added the comment: I found another related issue (issue37969). I also filed one myself (issue 40938). --- One thing against the 'has_netloc' etc. solution is that while it guarantees round-trips (urlunsplit(urlsplit('...')) etc.), it is conditional on

[issue37969] Correct urllib.parse functions dropping the delimiters of empty URI components

Open Close added the comment: This is a duplicate of issue22852 ('urllib.parse wrongly strips empty #fragment, ?query, //netloc'). Also note that three alternative solutions have already proposed. (1) Add 'None' type to Result objects members like this one. But i

[issue40938] urllib.parse.urlunsplit makes relative path to absolute (http:g -> http:///g)

New submission from Open Close : path 'g' in 'http:g' becomes '/g'. >>> urlsplit('http:g') SplitResult(scheme='http', netloc='', path='g', query='', fragment='') >>> urluns

[issue39799] Never return base's fragment from urljoin (urllib.parse)

Change by Open Close : -- pull_requests: +18069 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18710 ___ Python tracker <https://bugs.python.org/issu

[issue39799] Never return base's fragment from urljoin (urllib.parse)

Open Close added the comment: Uploaded the patch (1.patch). -- keywords: +patch Added file: https://bugs.python.org/file48935/1.patch ___ Python tracker <https://bugs.python.org/issue39

[issue39799] Never return base's fragment from urljoin (urllib.parse)

New submission from Open Close : According to RFC3986 5.2.2., target fragment is always reference fragment (T.fragment = R.fragment;). This is different from RFC1808 (4. and 5.2.). And it is not mentioned in Modifications section in RFC2396 and RFC3986. Current: >>> import url

[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29

Open Close added the comment: For me, since GH-14080, It's been fixed. (arch linux) -- ___ Python tracker <https://bugs.python.org/issue35998> ___ ___ Pytho

[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29

Open Close added the comment: I updated my PC (OpenSSL 1.1.1b). the same TimeoutError as before. $ ./python -m test.pythoninfo | grep ssl ssl.HAS_SNI: True ssl.OPENSSL_VERSION: OpenSSL 1.1.1b 26 Feb 2019 ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 2, 15) ssl.OP_ALL: 0x8054 ssl.OP_NO_TLSv1_1

[issue35031] test_asyncio test_start_tls_server_1 fails in AMD64 FreeBSD CURRENT buildbots

Open Close added the comment: Am I wrong with something? But test_start_tls_server_1 in newly made cpython fails on my plain intel linux personal PC. If I comment out the FreeBSD conditional (to apply ssl.OP_NO_TLSv1_3), the test passes. If I change HELLO_MSG to 1*1024*1024 (msg328157

[issue35031] test_asyncio test_start_tls_server_1 fails in AMD64 FreeBSD CURRENT buildbots

Change by Open Close : -- nosy: +op368 ___ Python tracker <https://bugs.python.org/issue35031> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29

Open Close added the comment: uploading stderr-op368.txt. (basically the same as Stéphane and Karthikeyan.) -- Added file: https://bugs.python.org/file48185/stderr-op368.txt ___ Python tracker <https://bugs.python.org/issue35

[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29

Open Close added the comment: It may be openssl 1.1.1a specific. I don't understand most of what they say, but the changelog (to 1.1.1b) 'looks' suspicious. https://www.openssl.org/news/changelog.html#x1 ...Actually Archlinux updated openssl to 1.1.1b about 4 days ago, so I ca

[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29

Open Close added the comment: I have the same TimeoutError on Arch linux PC (openssl 1.1.1a). It is random, but for now running test continuously at most 5 times successfully brings about the fail. So I think msg335635 needs re-checking. He saids PR 10011 makes this test pass in fedora 29