Websocket connections no longer work

[Artur-]

Bug description

A Vaadin application in development uses a websocket connection to provide live reload capabilities. The live reload server listens to port 35729, which is indicated in the lower right corner in the Gitpod UI: Ports: 33411, 35729, 3799, 8080, 45049.

Port 35729 should be mapped to e.g.

$ gp url 35729
https://35729-jade-turkey-nd11myav.ws-eu03.gitpod.io

However, establishing a connection to wss://35729-jade-turkey-nd11myav.ws-eu03.gitpod.io/ fails without any other information in the browser console than WebSocket connection to 'wss://35729-jade-turkey-nd11myav.ws-eu03.gitpod.io/' failed.

An additional note is that a websocket connection is also established to wss://8080-jade-turkey-nd11myav.ws-eu03.gitpod.io/vaadinServlet/?v-r=push&refresh_connection and this one works properly

Steps to reproduce

1. Open http://gitpod.io/#https://github.com/vaadin/skeleton-starter-flow-spring
2. Wait for the app to be shown (a text field and a button)

Expected behavior

The dev mode indicator in the lower right corner has a full green circle, not a half red half green.

The browser console has no errors

Example repository

https://github.com/vaadin/skeleton-starter-flow-spring

Anything else?

This has worked before

[akosyakov]

It is reproducible only in VS Code right? not in Theia? Hm, nope probably in both.

[Artur-]

Same problem with Theia

[yyoncho]

I am having the same issue when trying to display gtk apps via Broadway

[yyoncho]

Just want to mention that in some cases websockets work fine. I have a demo using https://github.com/xtermjs/xterm.js/ with powered by websocket connection and it works fine. On the other side, gdk broadway does not work. You could reproduce it sing gitpod/workspace-full - type broadwayd :5 which will open port 8085 then in the browser console you will see an error for unable to connect.

[svenefftinge]

Can you share an example repo with gdk/broadway?
Sorry got it, it is installed with workspace-full. thanks

[svenefftinge]

Although I was able to reproduce both cases I couldn't figure out what causes the issue. Seems like ws-proxy has issues with the websocket server's response as it logs.

"could not connect to backend /: EOF"

And the returns 404.

[akosyakov]

I think it is a bug in spring-boot and broadwayd. Caddy rewrites headers like from Sec-WebSocket-Key (uppercase S) to Sec-Websocket-Key. But these servers are not parsing headers in case insensitive manner https://github.com/spring-projects/spring-boot/blob/4c71e8124d99c12dfaa2e342b12355bd0954cb8b/spring-boot-project/spring-boot-devtools/src/main/java/org/springframework/boot/devtools/livereload/Connection.java#L44

Relevant issue in Caddy was closed as no fix: caddyserver/caddy#3888 (comment) It used to work before because in Nginx config we will pass Sec-WebSocket-Key.

[akosyakov]

@Artur- Could you file an issue for spring-boot to treat http headers case-insensitive?
@yyoncho there is already a merge request for broadwayd: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2894

[Artur-]

Sorry, but that makes little sense to me. It would be in the form of "That guy over there said that headers are treated incorrectly in some case in Spring Boot. If you want more info, ask that guy over there. I am just trying to use their IDE". Of course I can do it but filing an issue with relevant details sounds like it has much higher odds of getting fixed.

[akosyakov]

ok, filed an issue: spring-projects/spring-boot#26811

[yyoncho]

@akosyakov thank you, I will test with a version having that fix and I will let you know.

[ghuntley]

Thanks @akosyakov 🧡

[yyoncho]

@akosyakov will #4419 be sufficient to avoid the issue? It seems like that gitpod does not support ubuntu:21.04 which contains the broadway fix, thus I was unable to test.

[akosyakov]

@yyoncho yes

[yyoncho]

@akosyakov thank you, I will test with a version having that fix and I will let you know.

Broadway works fine using the latest gitpod deployment. Thank you!

[francislavoie]

spring-projects/spring-boot#26813 is now merged, so the issue with spring-boot should be resolved.