[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-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 interpretation.
"http:g"= "http:g" ; for strict parsers
/ "http://a/b/c/g; ; for backward compatibility
/ "http://a/g; ; (yours)
--
___
Python tracker
<https://bugs.python.org/issue40938>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue40938> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: 2528.3 ± 3.6 MB/s socket-read: 2520.9 ± 3.6 MB/s -- ___ Python tracker <https://bugs.python.org/issue41002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -- nosy: +op368 ___ Python tracker <https://bugs.python.org/issue41002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: +op368 ___ Python tracker <https://bugs.python.org/issue40594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 'urlunsplit' getting 'SplitResult' object.
When 'urlunsplit' gets a normal tuple, it is helpless.
--
nosy: +op368
___
Python tracker
<https://bugs.python.org/issue22852>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 it is considering not only query and fragment, but also netloc,
which may solve many other issues.
(2) Add 'has_netloc', 'has_query' and 'has_fragment' attribute.
(3) like (1), but conditional on 'allow_none' argument (similar to
'allow_fragments')
--
nosy: +op368
___
Python tracker
<https://bugs.python.org/issue37969>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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='')
>>> urlunsplit(urlsplit('http:g'))
'http:///g'
>>> urlsplit('http:///g')
SplitResult(scheme='http', netloc='', path='/g', query='', fragment='')
>>> urljoin('http://a/b/c/d', 'http:g')
'http://a/b/c/g'
>>> urljoin('http://a/b/c/d', 'http:///g')
'http://a/g'
The problematic part of the code is:
def urlunsplit(components):
[...]
if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
--->if url and url[:1] != '/': url = '/' + url
url = '//' + (netloc or '') + url
Note also that urllib has decided on the interpretation of 'http:g' (in test).
def test_RFC3986(self):
[...]
#self.checkJoin(RFC3986_BASE, 'http:g','http:g') # strict parser
self.checkJoin(RFC3986_BASE, 'http:g','http://a/b/c/g') #relaxed parser
--
messages: 371179
nosy: op368
priority: normal
severity: normal
status: open
title: urllib.parse.urlunsplit makes relative path to absolute (http:g ->
http:///g)
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue40938>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 urllib.parse
>>> urllib.parse.urljoin('http://a/b#f', '')
'http://a/b#f'
Should return:
'http://a/b'
---
https://tools.ietf.org/html/rfc3986#section-5.2.2
https://tools.ietf.org/html/rfc1808.html#section-4
https://tools.ietf.org/html/rfc1808.html#section-5.2
--
components: Library (Lib)
messages: 362983
nosy: op368
priority: normal
severity: normal
status: open
title: Never return base's fragment from urljoin (urllib.parse)
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39799>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: 0x1000 -- ___ Python tracker <https://bugs.python.org/issue35998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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), the test passes. I reported the details in https://bugs.python.org/issue35998#msg336986 and the following. -- ___ Python tracker <https://bugs.python.org/issue35031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue35998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 can 'test' 1.1.1b. But which means I may not be able to reproduce the fail after that. -- ___ Python tracker <https://bugs.python.org/issue35998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 VM,
but thinking about that it only adds an conditional to FreeBSD, it is not
likely.
if sys.platform.startswith('freebsd'):
client_context.options |= ssl.OP_NO_TLSv1_3
And indded, if commenting out the conditional line,
the test actually passes.
So I also think the commit needs re-considering.
f777fa5f2bd16ac8d60416eaa64eb9d2cf84ffac (Opt out of TLS 1.3 only on FreeBSD)
---
$ uname -a
Linux 4.20.4-arch1-1-ARCH #1 SMP PREEMPT Wed Jan 23 00:12:22 UTC 2019
x86_64 GNU/Linux
(native, not venv nor vm)
$ ./python -m test.pythoninfo | grep ssl
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1a 20 Nov 2018
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 1, 15)
ssl.OP_ALL: 0x8054
ssl.OP_NO_TLSv1_1: 0x1000
$ ./python -X tracemalloc -m unittest -v
test.test_asyncio.test_sslproto.SelectorStartTLSTests.test_start_tls_server_1
...
==
ERROR: test_start_tls_server_1
(test.test_asyncio.test_sslproto.SelectorStartTLSTests)
--
Traceback (most recent call last):
File "/home/philo/me/git/cpython/Lib/test/test_asyncio/test_sslproto.py",
line 510, in test_start_tls_server_1
self.loop.run_until_complete(run_main())
File "/home/philo/me/git/cpython/Lib/asyncio/base_events.py", line 589, in
run_until_complete
return future.result()
File "/home/philo/me/git/cpython/Lib/test/test_asyncio/test_sslproto.py",
line 503, in run_main
await asyncio.wait_for(
File "/home/philo/me/git/cpython/Lib/asyncio/tasks.py", line 461, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError
--
Ran 1 test in 60.076s
--
nosy: +op368
___
Python tracker
<https://bugs.python.org/issue35998>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
