⚠️ WARNING: This release removes the hard-coded content-type header from the upgrade request. If you were relying on this you'll need to manually add it now, but since there's no body it shouldn't be required
Some WebSocket servers use the Content-Type header to determine which serialization format to use for its WebSocket messages. However, HTTPInitialRequestHandleradds a hard-coded Content-Type: text/plain; charset=utf-8 header to the WebSocket client’s HTTP upgrade request, so the client cannot customize the header value.
Given that the HTTP upgrade request body is empty, there is no need for HTTPInitialRequestHandler to add the Content-Type header. This will allow the client to add their own, if desired.
⚠️ WARNING: This release removes the hard-coded
content-type
header from the upgrade request. If you were relying on this you'll need to manually add it now, but since there's no body it shouldn't be requiredSome WebSocket servers use the
Content-Type
header to determine which serialization format to use for its WebSocket messages. However,HTTPInitialRequestHandler
adds a hard-codedContent-Type: text/plain; charset=utf-8
header to the WebSocket client’s HTTP upgrade request, so the client cannot customize the header value.Given that the HTTP upgrade request body is empty, there is no need for
HTTPInitialRequestHandler
to add theContent-Type
header. This will allow the client to add their own, if desired.Fixes #126.