MagicStack / MagicStack/uvloop
start_tls: AssertionError if writing is paused
Personne n'a encore pris cette issue.
- Langage dominant
- Cython
- Étoiles
- 11.9k
- Forks
- 616
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
First found in the CPython port of sslproto (see https://github.com/python/cpython/issues/109051 but disregard the title, it's not platform-specific), and it can be reproduced in uvloop.
Traceback
protocol.resume_writing() failed
protocol: <uvloop.loop.SSLProtocol object at 0x1033910c0>
transport: <TCPTransport closed=False reading=True 0x1098351c0>
Traceback (most recent call last):
File "uvloop/handles/basetransport.pyx", line 96, in uvloop.loop.UVBaseTransport._maybe_resume_protocol
run_in_context(
File "uvloop/loop.pyx", line 101, in uvloop.loop.run_in_context
return context.run(method)
File "uvloop/sslproto.pyx", line 922, in uvloop.loop.SSLProtocol.resume_writing
assert self._ssl_writing_paused
AssertionError
Simplest way to reproduce is to increase payload size in test_start_tls_server_1. Send will block and transport will request to pause writing. After start_tls(), the transport will attempt to resume the now-switched protocol, which was not aware it was ever supposed to be paused.
I commented further in the original bug with some notes. The CPython implementation is a bit different (it has a redundant buffering mechanism with a deque which I believe is unnecessary) but the fundamental issue is the same.
Question: what is the motivation for the extra flow control layer in SSLProtocol? It seems it was introduced in uvloop first. I suggested it can be removed and let the original protocol and original transport deal with flow control (which would also fix the bug). But it wouldn't be a good idea to remove it if it's solving a known problem.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par tests/test_tcp.py, en particulier test_start_tls_server_1, et reproduisez le cas de charge utile importante décrit dans l’issue. Examinez ensuite uvloop/sslproto.pyx autour de SSLProtocol.resume_writing et start_tls afin de comprendre la transition du contrôle de flux. Le travail terminé doit inclure un correctif confirmé pour l’assertion et un test de régression couvrant une écriture mise en pause pendant le démarrage de TLS.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- networking
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 35/100