Remove content-length header from 101 Switching Protocols response

[chadbarth]

RFC 9110-8.6 (and RFC 7230 before it) states:

A server MUST NOT send a Content-Length header field in any response with a status code of 1xx
(Informational) or 204 (No Content).

The websocket connect response is 101 (Switching Protocols) and should not contain Content-Length as specified above. Drogon's response incorrectly included the Content-Length header.

This causes an issue with the .NET websockets client implementation as described in this Stack Overflow question.

Using setPassthrough on Switching Protocols response suppresses the Content-Length header as well as Content-Type, Date, and Server. I added explicit code to add back the Server header. I'm not sure how desirable that actually is.

And there is a test added that fails without the code changes.

[an-tao]

@chadbarth Thank you very much for your patch. However, I think modifying the makeHeaderString function of the HttpResponseImpl class seems to be a better solution, as it would conveniently exclude cases where the status code is 1xx or 204.

[chadbarth]

@an-tao Thank you for reviewing. I modified the solution as suggested. Please let me know if you would like me to squash commits or anything else.

[an-tao]

@chadbarth Sorry for the late reply. I missed your changes, I've merged them now. Thank you very much!

[tripleslash]

This PR seems to break websockets in chrome

[Mis1eader-dev]

This PR seems to break websockets in chrome

According to my tests this PR isn't the one that broke WebSockets in Drogon, it's the PR after this one that it starts not working #2170

[tripleslash]

I can confirm this PR is the one that breaks websockets in Chrome