You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When constructing a boutique HTTP HEAD request with a non-empty body, Isahc will assume that the server will also return a body in kind. This breaks when the server returns a response with a Content-Length header, which is totally legal, but then Isahc tries to read a response payload of that size and fails.
Isahc should not be assuming that the server is going to break the HTTP spec just because the user making the request is! According to RFC 7230, Section 3.3 HEAD requests should never return a response body regardless of what headers are given. We should probably return Body::empty() for all responses to HEAD requests even if the server does include some garbage data after the response headers. Though it might differ exactly depending on whether HTTP/2 is in use or not since that has explicit frames for body data.
Here is a sample program demonstrating this issue (reproduced on Isahc 1.5.0, but also reproducible on 0.9.14 and likely older):
When constructing a boutique HTTP HEAD request with a non-empty body, Isahc will assume that the server will also return a body in kind. This breaks when the server returns a response with a
Content-Length
header, which is totally legal, but then Isahc tries to read a response payload of that size and fails.Isahc should not be assuming that the server is going to break the HTTP spec just because the user making the request is! According to RFC 7230, Section 3.3 HEAD requests should never return a response body regardless of what headers are given. We should probably return
Body::empty()
for all responses to HEAD requests even if the server does include some garbage data after the response headers. Though it might differ exactly depending on whether HTTP/2 is in use or not since that has explicit frames for body data.Here is a sample program demonstrating this issue (reproduced on Isahc 1.5.0, but also reproducible on 0.9.14 and likely older):
This program prints the following sexy error:
Though on 0.9.14 it apparently produces a much more confusing and ambiguous error:
The text was updated successfully, but these errors were encountered: