[issue43991] asyncio lock does not get released after task is canceled
Jonathan Schweder added the comment: a.niederbuehl tasks are free of context, meaning that the task does not know what was done inside it, and by consequence is impossible to know when or not release a lock. This is by design and normally in these cases you need to be aware of the lock, by for example checking if the lock was released before cancelling the task. -- nosy: +jaswdr ___ Python tracker <https://bugs.python.org/issue43991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43806] asyncio.StreamReader hangs when reading from pipe and other process exits unexpectedly
Jonathan Schweder added the comment: @kormang this is an expected behaviour, this is a problem even for the OS level, just because it is impossible to know when the reader needs to stop waiting, the best option here is to implement some timeout mechanism. -- nosy: +jaswdr ___ Python tracker <https://bugs.python.org/issue43806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43742] tcp_echo_client in asyncio streams example does not work. Hangs for ever at reaser.read()
Jonathan Schweder added the comment:
I was able to execute the example in Debian 10 + Python 3.10+
Did you execute the server too? You need to create two files, one for the
client code and one for the server code, the server as specified by the example
should be something like the code below, try to save it to a file, then execute
it, after that execute the client example that you have cited.
import asyncio
async def handle_echo(reader, writer):
data = await reader.read(100)
message = data.decode()
addr = writer.get_extra_info('peername')
print(f"Received {message!r} from {addr!r}")
print(f"Send: {message!r}")
writer.write(data)
await writer.drain()
print("Close the connection")
writer.close()
async def main():
server = await asyncio.start_server(
handle_echo, '127.0.0.1', )
addr = server.sockets[0].getsockname()
print(f'Serving on {addr}')
async with server:
await server.serve_forever()
asyncio.run(main())
--
nosy: +jaswdr
___
Python tracker
<https://bugs.python.org/issue43742>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43742] tcp_echo_client in asyncio streams example does not work. Hangs for ever at reaser.read()
Jonathan Schweder added the comment: @jcolo Awesome to hear that you were able to run the example, in fact I got in the same trap, thinking the same that the example should carry the server and client side, I guess we can improve the documentation to avoid it, I'll sent a PR to make the improvement. -- ___ Python tracker <https://bugs.python.org/issue43742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43742] tcp_echo_client in asyncio streams example does not work. Hangs for ever at reaser.read()
Change by Jonathan Schweder : -- keywords: +patch pull_requests: +24563 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25889 ___ Python tracker <https://bugs.python.org/issue43742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44107] HTTPServer can't close http client completely
Jonathan Schweder added the comment: @ueJone according to the (RFC)[https://datatracker.ietf.org/doc/html/rfc6455#section-1.4] the FIN/ACK is not normative, in other words is recommended but not required, I've checked the syscalls of the server, see it below: ``` ... 1561 15143 write(2, "127.0.0.1 - - [11/May/2021 20:08"..., 60) = 60$ 1562 15143 sendto(4, "HTTP/1.0 200 OK\r\nServer: SimpleH"..., 154, 0, NULL, 0) = 154$ 1563 15143 sendto(4, " <https://bugs.python.org/issue44107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44104] http.cookies.CookieError: Illegal key
Jonathan Schweder added the comment: Simple example to reproduce the issue: from http import cookies C = cookies.SimpleCookie() C["ys-api/mpegts/service"] = "blabla" print(C.output()) @ra1nb0w so far as I have found [1][2], the "/" not a valid character for the Cookie name, [3] defines the list of valid characters and [4] is where the exception is raised, I also found that even with the RFC browsers have different rules for the Cookie name definitions, this could be reason why Python has, for example, the ":" character in the list. My conclusion is that the rule for the cookie name is not well-defined, there are some ambiguities here and there, but if we consider purely this case and the RFC, the "/" still is not a valid character for the cookie name, so I guess the best option for you is to filter it out any http.cookies.CookieError that happen. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes [2] https://datatracker.ietf.org/doc/html/rfc2616#section-2.2 [3] https://github.com/python/cpython/blob/main/Lib/http/cookies.py#L162 [4] https://github.com/python/cpython/blob/main/Lib/http/cookies.py#L353 -- nosy: +jaswdr ___ Python tracker <https://bugs.python.org/issue44104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43813] Denial of service on http.server module with large request method.
Jonathan Schweder added the comment: @demonia you are more than welcome to send a PR, sent it and add a reference to this issue, so it could be reviewed. -- nosy: +jaswdr ___ Python tracker <https://bugs.python.org/issue43813> ___ ___ 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)
Jonathan Schweder added the comment: @op368 I don't think that this is a bug, [1] literally uses this exact example and shows the expected behaviour. [1] https://datatracker.ietf.org/doc/html/rfc3986#section-5.4.2 -- nosy: +jaswdr ___ 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)
Jonathan Schweder added the comment: Not exactly, in the RFC example they use a/b/c for the path, but when using http:g there is no nested path, so it should be http:///g, 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
[issue38193] http.client should be "runnable" like http.server
Change by Jonathan Schweder : -- keywords: +patch nosy: +jaswdr nosy_count: 1.0 -> 2.0 pull_requests: +25361 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26775 ___ Python tracker <https://bugs.python.org/issue38193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34629] Python3 regression for urllib(2).urlopen(...).fp for chunked http responses
Jonathan Schweder added the comment: Hello @tkruse, I have made some research and found that when using the Chunked transfer encoding [1], each chunk is preceded by its size in bytes, something that really happen if you check the content of one downloaded file from the example you provided [2]. So far, I would say that this is not a bug, it is just how the transfer encoding works. [1]: https://en.wikipedia.org/wiki/Chunked_transfer_encoding [2]: https://gist.github.com/jaswdr/95b2adc519d986c00b17f6572d470f2a -- nosy: +jaswdr ___ Python tracker <https://bugs.python.org/issue34629> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
