start_tls: AssertionError if writing is paused
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- networking
Hướng nghiên cứu
Bắt đầu với tests/test_tcp.py, đặc biệt là test_start_tls_server_1, và tái hiện trường hợp payload lớn được mô tả trong issue. Sau đó kiểm tra uvloop/sslproto.pyx quanh SSLProtocol.resume_writing và start_tls để hiểu quá trình chuyển đổi kiểm soát luồng. Phần hoàn thành cần bao gồm một bản sửa đã được xác nhận cho assertion và một bài kiểm thử hồi quy bao quát trường hợp thao tác ghi bị tạm dừng trong khi khởi động TLS.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Cython
- Star
- 11.9k
- Fork
- 615
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của MagicStack/uvloop
-
License not clear Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
MagicStack/uvloop#759 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
MagicStack/uvloop#741 · 2 reaction ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
MagicStack/uvloop#702 · 8 bình luận · 9 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
MagicStack/uvloop#766 ·
-
Directly constructed subprocess pipe protocols segfault when callbacks use a non-process owner Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
MagicStack/uvloop#765 ·
Tất cả issue của MagicStack/uvloop
Issue tương tự
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
n0-computer/iroh#4550 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
bytecodealliance/rustix#1689 · 2 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
home-assistant/supervisor#7248 ·
-
bug cert blocker needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
project-chip/connectedhomeip#74373 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100