Hi everyone!
I’ve found an interesting problem working with LiveView this week and I’ve been meaning to share it with you. I want to make this available for posterity because I think it’s something very likely to happen to others.
Ok, storytime… We had a problem at work that would affect some of our internal users but not our clients. It was tough to reproduce because it would happen “randomly” for some users but not others.
What happened is that the interactive elements in the app would simply stop working out of the blue during common usage. If you are thinking “this looks like a WebSocket issue”, you are 100% right; after further investigation, we noticed that sometimes the server would just, without any apparent reason, refuse the WebSocket connection. We noticed that cleaning up the local data would make things work again for a while but the root cause of the problem was still not clear to us.
In the meantime, we noticed that we were sending a strangely amount of cookies in the WS connection handshake. This happened because we had multiple third-party apps accessible through subdomains, so the browser was sending everything under *.domain.com to all further requests.
We started getting suspicious about the cookies and started checking for the 4096 bytes threshold. We know we were adding some unnecessary cookies to the request, but overall it was nothing too crazy. The funny thing is that, under the same circumstances, the problem would happen in production but not locally, it would happen in Chrome but not in other browsers, and although the WebSocket connection was being dropped, the dead render request would still complete fine… What made things worse for us is that the Chrome Dev Tools did not show the response headers for the failed handshake so we had no clue what was happening until we tried to use Safari which actually gave us some useful information - the WS connection was being refused with the status “431 Request Header Fields Too Large” 
(thanks Safari). Ok, if you have seen this error before you know exactly what this is related to. We went and doubled our endpoint’s default header limit: http: [protocol_options: [max_header_value_length: 8192]] and the problem went away.
This prevents the issue from happening, but it doesn’t solve the root cause of the problem which is sending unnecessary cookies. So I was wondering what other options are there that allow us to have more fine-grained control over which cookies are sent in the WS handshake. I was thinking mainly in terms of whitelisting/blacklisting some of them. Any thoughts!?
