flow: Websocket in combination with AJP broken behind reverse-proxy in 23.2.

Description of the bug

Previously websocket connections could be forwarded by using a separate location in the httpd configuration like so <Location /web/vaadinServlet/> allowing this connection to be used with http / websockets - after 23.2 the websockets connection is not routed tho /web/vaadinServlet/ anymore, instead it goes straigth to the /web/?v-r=push... where the connection can’t be established because /web/** forwards to AJP, which DOES not support websockets.

Example exception:


'HTTP upgrade is not supported by this protocol' Requested resource was: '/web/?v-r=push&v-uiId=1&v-pushId=0ce8ff89-eae1-4612-9a12-3383167a2d5b&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=3.1.2-javascript&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&Content-Type=application/json;%20charset=UTF-8&X-atmo-protocol=true'

Expected behavior

Websockets should be handled by a separat endpoint /web/vaadinServlet/ like done since V8.

Minimal reproducible example

.

Versions

  • Vaadin / Flow version: 23.2
  • Java version: 11
  • OS version: xx
  • Browser version (if applicable):
  • Application Server (if applicable):
  • IDE (if applicable):

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (14 by maintainers)

Commits related to this issue

Most upvoted comments

I’m fine with that - but I would also highly suggest to create proper reverse proxy documentation for e.g. Apache 2 and nginx until then for people to migrate (@tarekoraby)

@knoobie we have a solution here and currently making a test coverage for it, but the main obstacle for us is that with Jetty we got ws-disconnect-on-heartbeat errors, not clear why. Need to figure out the root cause before we apply this patch.

So should we add a “feature” flag to get the old mapping back and then remove the flag in V24, as the main/only reason for returning the old mapping would be compatibility?