Websocket-over-HTTP content-type charset

[Aboisier]

Hi,

Context

I've been working on implementing the Websocket-over-HTTP/GRIP protocol with ASP.NET Core recently.

Even though I set my response Content-Type to ASP.NET application/websocket-events core appends the charset; this means the response looks like this.

HTTP/1.1 200 OK
Content-Type: application/websocket-events; charset=utf-8
Sec-WebSocket-Extensions: grip

OPEN\r\n

Actual behaviour

It looks like pushpin acts as a pass-through proxy.

> ~$ wscat -c ws://localhost:7999/hub
error: Unexpected server response: 200

Expected behaviour

I expected the connection the handshake to be successful.

> :~$ wscat -c ws://localhost:7999/opportunity/hub
Connected (press CTRL+C to quit)

[jkarneges]

Hi,

Yes, it seems Pushpin expects Content-Type to be exactly application/websocket-events. Technically, the response body is binary rather than pure text, so a charset doesn't make much sense. For example, you can send arbitrary bytes with some frame types like BINARY and CLOSE.

If there's no way to omit the charset part in ASP.NET, then maybe the check could be relaxed for compatibility purposes.

Note that Pushpin might send non-UTF-8 to the backend as well, if the WebSocket client provides such bytes. Hopefully that's not a problem.

[Aboisier]

It is possible to alter the Content-Type header in a middleware or a output formatter. It kind-of feels dirty, but I guess it makes sense that Pushpin wants exactly application/websocket-events. I hadn't realized the body was binary.

I'll close. Thanks for your answer!