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
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: