permessage-deflate

[manuel-rubio]

Hello, looks like now (at least for Google Chrome) it's a required extension. I checked the code and I guess that's the same as x-webkit-deflate-frame (or should be), what do you think?

[yurrriq]

Thanks for the report! I'm not familiar, but that seems plausible to me. Do you think we should treat x-webkit-deflate-frame and permessage-deflate the same way then? Hopefully someone who knows more can help us out here.

[manuel-rubio]

@yurrriq I've tried to add the "permessage-deflate" as "x-webkit-deflate-frame", but looks like the compression is made in a different way, it's not working and the bad news are this kind of extension is activated by default in browsers like Chrome. Anyway, cowboy works fine so, I had to move to cowboy instead.

[yurrriq]

Ah, that's unfortunate.. Thanks for checking!

[tsloughter]

@manuel-rubio any chance you could compare what cowboy sends to what elli sends so we might be able to fix this?

[manuel-rubio]

@tsloughter the compression using WebSockets is a bit weird, I have no experience with that sorry, I was only tracing (6 months ago) how worked this. Sorry, I have no idea at this moment what I was trying to do :-D ... but if I have some spare time in the following weeks I promise I'll try to provide more information about it.

[tsloughter]

Thanks, no worries if not, I just figured I'd ask before seeing if I can reproduce when I get some time.

[starbelly]

I have run into this issue with recent ventures with elli_websocket. The problem appears to be around

elli_websocket/src/elli_ws_protocol.erl

Line 202 in 5153fff

handle_event(Req, Handler, websocket_open,

.

The client(s) I've tested with do not use the extension and elli_websocket does not return those headers. It seems to be that before the handshake is over, you can write to the socket, resulting in this error under certain circumstances. Namely, if a client is trying to connect while things are still "warming up" is the only way I can make this happen. Specifically, if I fire up an app and concurrently make a WS connection it happens. If I start the app, wait a few seconds and then try to connect, never fails.

It should be noted that the message that is trying to be pushed to the client happens because the client is subscribed to a topic in init or websocket_open event. I think a good solution would be to add something to handler state so that the handler can check if the socket is ready. Either that or queue messages in elli_ws_protocol until things are "ready".

[yurrriq]

Thanks for the feedback. We'd happily review a PR of either (or both) approach(es), if anyone has the time and interest. At first glance, I think I'd lean toward augmenting the handler state, but queuing could be good too, and wouldn't (necessarily) break the current API, in case that's a goal.

[starbelly]

Yes, I can try to put a PR together. I would be more inclined to augment state as it ultimately should not be a responsibility of elli_websocket IMO, but it may look a bit different once I look into the code a bit.