Recently we had a bug report from the client that states they are unable to connect to WebSocket with Error during WebSocket Handshake: 'Connection' header value must contain 'Upgrade'.
Obviously we have this header so the only thing I can think of is that ours is downcased (people seem to have problems with that).
For this reason I wanted to capitalize “Upgrade” in the “Connection” header, but it’s trickier then it seems: When I run locally and analyze headers I can see that it is already capitalized, but behind the proxy it becomes downcase.
In nginx I capitalized the proxy_set_header Connection value which does nothing. I then tried both add_header Connection "Upgrade" always; and more_set_headers 'Connection: Upgrade'; from headers-more-nginx module, they work but add an extra “Connection” header instead of modifying the existing one which doesn’t seem solve the problem.
I also tried to clear the existing header before setting the new one, things like more_clear_headers 'Connection'; and such but they seem to “miss” the downcased header as if it didn’t exist.
Did anyone have a similar problem? Any info on how exactly the whole thing works? ideas how to solve it?
As I understand it headers go in, get proxied to the app and get downcased on their way back without much control over the whole thing.
At the moment I’m thinking about dropping nginx and using cap_net_bind_service or iptables to get to port 80 but I hope there is an easier solution.
well it’s not as lean as it used to be There is an extra copy pasted location to experiment with the socket route. I can also almost confirm that it’s an nginx problem - we got remote access to the client and could test it without nginx, at least with websocket.org echo test it works without proxy but it didn’t work with it, didn’t try it with the proper client app yet though.
It’s not an nginx issue after all, there seem to be a well hidden firewall that messes up port 80 traffic on the application level. Using another port (incl. wss with 443) solves the issue and 80 wouldn’t work with nginx or directly.
Sorry for the confusion and thanks for all your feedback!
I’m afraid I can’t tell you much on this topic, it should have been a part of network setup since no one was aware of it and we had to exclude every other option and basically “prove” that something happens on the network level for it to come up.
Anyway I don’t think it’s something to worry about in the long run since it messes up all WS traffic on port 80, so at some point it will be removed or updated.