Handshake failed due to invalid Upgrade header: null [SPR-12371]

[spring-projects-issues]

Tommy Ludwig opened SPR-12371 and commented

I am running into the issue of secured WebSocket upgrade requests (over STOMP using SockJS) failing when I run my Spring application on OpenShift or CloudFoundry, though it works perfectly fine when I run it locally. I have made a simplified sample and put it on GitHub that recreates this issue. That can be found here:
https://github.com/shakuzen/spring-stomp-websocket-test

I made a StackOverflow question regarding this but have not been able to get any help so far. That is here:
http://stackoverflow.com/questions/26452632/secured-websocket-upgrade-over-stomp-via-sockjs-fails-with-invalid-upgrade-heade

I have attached the relevant portion of the local and remote (OpenShift server) logs and corresponding request headers that were sent (captured using Chrome's developer tools) when trying to connect via WebSocket. In the case of running on OpenShift, you can see just before the ERROR message, it logs the headers, which differ from the headers Chrome states are being sent. Particularly, the logged headers do not contain an upgrade attribute and the connection attribute's value is 'Keep-Alive' instead of 'Upgrade'. Additionally, it has some extra x-forwarded-* attributes.

You can see that the request headers gathered from Chrome's developer tools for local and remote are identical except for expected differences in security key and URLs and session ID.

I have gone so far as to try debugging the framework code to figure out why the headers it is failing with are not the headers I see from the browser, but I was not able to figure out why. I apologize if this is some silly mistake on my part, but I feel the sample I made is simple enough of a case that it warranted creating this issue.

Please do not hesitate to let me know if I can provide any additional information to help figure out the cause of this issue. I really appreciate any help with this even though I am sure you are busy with the upcoming release.

---

Affects: 4.0.7, 4.1.1

Reference URL: https://github.com/shakuzen/spring-stomp-websocket-test

Attachments:

• local_request_headers.txt (1.06 kB)
• local.log (8.06 kB)
• local dev tools.PNG (18.55 kB)
• remote dev tools.PNG (17.35 kB)
• server_request_headers.txt (1.12 kB)
• server.log (8.33 kB)

[spring-projects-issues]

Rossen Stoyanchev commented

The x-forwarded-* headers indicate a routing issue where the request is getting forwarded but it's not set up to propagate Upgarde-related headers.

According to https://blog.openshift.com/paas-websockets/ you have to use port 8000 and also says by default Java apps are not WebSocket enabled (Tomcat 6). It looks like it should be possible though to use Tomcat 7 instead with a DIY application (https://github.com/ramr/openshift-tomcat7-websockets) based on the discussion here https://forums.openshift.com/websockets-in-java. Have you tried any of those instructions?

[spring-projects-issues]

Tommy Ludwig commented

Thank you for your quick response. I am taking a look into this and will get back to you soon. I apologize I didn't find this basic information on my own. As another note, it is not working on CloudFoundry either (same error), but that is perhaps a port issue as well, which I will try to do some research on.

[spring-projects-issues]

Tommy Ludwig commented

Rossen, your hunch and research was indeed correct. I am able to use websockets on port 8000 for OpenShift. Unfortunately it only seems to work if the address I am connecting from is of the same origin as the target URL, which means I have to have the ugly port 8000 in the URL for the page that connects to WebSocket. Do you know of any way to connect without the port in the origin URL?
Either way, it seems this ticket can be closed as invalid. Thank you for your help and sorry.

[spring-projects-issues]

Rossen Stoyanchev commented

No I don't know unfortunately. A good question for https://forums.openshift.com perhaps. If you find out please do comment here or add a link.

Thanks.