Reject websocket extensions?

[SoylentGraham]

I'm currently routing websocket connections via http-proxy to my own c++ websocket app.
When I send large text frames from my client (chrome), I'm getting some odd opcodes, reserved bits set etc, which I don't recognise, so I kick the client(proxy) from my server (app)

After some debugging, I believe these are opcodes from deflate extensions (still figuring it out).
I don't ever get this problem when I connect directly to my app/websocket code (sending huge frames without missing a beat)

I think the proxy is accepting the deflate extension, although I reject it, and I'm getting deflate-compressed packets(hence the opcodes)

I have 2 questions

1. Is it possible http-proxy ignores my websocket's handshake responses, perhaps to establish a handshake ASAP
2. If so, can I explicitly reject these? (Overriding the handshake in node, seems doable)

Maybe I've overlooked some specific documentation over this, or searched issues for the wrong terms.

[SoylentGraham]

#882 might cover this

[SoylentGraham]

I think this does it, but not sure, (certainly sends blank extensions to my websocket), seems to be hard to get the details of the response in chrome dev tools

function OnProxyWebsocketRequest(proxyReq, req, socket, options, head) 
{
	console.log(`OnProxyWebsocketRequest; ${JSON.stringify(proxyReq,null,'\t')}`);
	proxyReq.setHeader('Sec-WebSocket-Extensions','');
};
const Proxy = httpProxy.createProxyServer(ProxyOptions);
Proxy.on('proxyReqWs',OnProxyWebsocketRequest);

[SoylentGraham]

Was a bug with large packets (I ended up decoding the header twice, but had already eaten header data) in my websocket implementation
NewChromantics/SoyLib@6cce808#diff-25a6634263c1b1f6fc4697a04e2b9904ea4b042a89af59dc93ec1f5d44848a26

I think the above code does still do what I want, but it would be good to know if the proxy does propogate my header changes