Similar to issue #1797 hyper should not set a content-length header for a number of different scenario's. Quoting RFC 7230, section 3.3.2 6th paragraph:
A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content). A
server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 4.3.6 of
[RFC7231]).
At this moment the content-length header is set for 101 Switch Protocols responses. The resulting issue is that e.g. with a warp WebSocket server, a .Net client will drop the connection after 100 seconds: https://stackoverflow.com/a/44553521/85514 .
I believe the solution should be similar to [b342c38], and I'm willing to make a PR to do that. However, I'm not familiar enough with the code base to see if that would fix the problem / has any other implications.
The text was updated successfully, but these errors were encountered:
psmit
added a commit
to psmit/hyper
that referenced
this issue
Jun 3, 2020
Similar to issue #1797 hyper should not set a content-length header for a number of different scenario's. Quoting RFC 7230, section 3.3.2 6th paragraph:
At this moment the content-length header is set for 101 Switch Protocols responses. The resulting issue is that e.g. with a warp WebSocket server, a .Net client will drop the connection after 100 seconds: https://stackoverflow.com/a/44553521/85514 .
I believe the solution should be similar to [b342c38], and I'm willing to make a PR to do that. However, I'm not familiar enough with the code base to see if that would fix the problem / has any other implications.
The text was updated successfully, but these errors were encountered: