Response parser requires support for HEAD responses without body
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu tại HttpResponseParser.feed_data(self, data: bytes) và theo dõi cách các ranh giới response và kỳ vọng về body được xử lý đối với pipelined responses. Công việc hoàn tất khi có thể phân tích HEAD responses mà không có body, bao gồm cả các header Content-Length, đồng thời các pipelined HEAD và GET responses vẫn được tách biệt chính xác.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
According to the specification of HTTP/1.1 ...
Responses to the HEAD request method never include a message body because the associated response header fields (e.g., Transfer-Encoding, Content-Length, etc.), if present, indicate only what their values would have been if the request method had been GET.
Source: RFC 7230 (Section 3.3)
... responses to HEAD requests do not have a body. Even if e.g. the Content-Length header is present.
However, the response parser cannot know based on the data it receives whether the corresponding request was using the HEAD or another method and whether to expect a body or to just ignore any header flags about the content.
Suggestion:
Add an additional boolean flag to HttpResponseParser.feed_data(self, data: bytes) to tell the parser that it should not expect a body (or even throw a parser exception if there is one present).
Because HTTP/1.1 also allows pipelining, this additional parameter should also rather be a list of "body presence" flags. Here's why:
If you send multiple requests to a server without waiting for the responses (= pipelining), you are going to receive back a bunch of responses together. Without them being parsed yet, one cannot identify the message boundaries and therefore they cannot be fed to the parser one by one. So the parser has to support that the whole stack of responses is fed to it and it needs a list of the "expected body presence".
Example:
If the pipelined requests were something like {HEAD, GET, HEAD, GET}, the "body presence" flags need to alternate as well.
For convenience, it may be good to have a parameter that can be set using both types, a single flag and a list of flags.
- Ngôn ngữ chính
- Python
- Star
- 1.3k
- Fork
- 107
- 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/httptools
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
MagicStack/httptools#136 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
MagicStack/httptools#140 · 1 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
MagicStack/httptools#127 · 2 bình luận · 1 reaction ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
MagicStack/httptools#126 ·
-
Python 3.10 Armv7 version Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
MagicStack/httptools#125 ·
Tất cả issue của MagicStack/httptools
Issue tương tự
-
essnmx good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
-
[Feature] 奇物选择添加优先级 Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
syfoud/Simulated_Scepter#174 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Giskard-AI/giskard-oss#2840 · 1 bình luận ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Đang mởarea: repo bug perceived difficulty: 2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
yeti-platform/yeti#1380 ·