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
- feat: Added vaadinServlet mapping behind FeatureFlag (#14641) — committed to vaadin/flow by MarcinVaadin 2 years ago
- feat: Added vaadinServlet mapping behind FeatureFlag (#14641) — committed to vaadin/flow by MarcinVaadin 2 years ago
- #14641 Remove pushUrl configuration option; Use dedicated mapping for push — committed to vaadin/flow by tepi 2 years ago
- #14641 Remove pushUrl configuration option; Use dedicated mapping for push — committed to vaadin/flow by tepi 2 years ago
- #14641 Fix pushUrl mapping for servlet mapped with urlPattern — committed to vaadin/flow by tepi 2 years ago
- fix!: Use dedicated mapping for Vaadin push endpoint (#15188) Removes pushUrl configuration option, and instead maps push always to a dedicated path (/VAADIN/push). Related-to #14641 — committed to vaadin/flow by tepi 2 years ago
- fix!: Use dedicated mapping for Vaadin push endpoint (#15188) Removes pushUrl configuration option, and instead maps push always to a dedicated path (/VAADIN/push). Related-to #14641 — committed to knoobie/flow by tepi 2 years ago
- fix!: Use dedicated mapping for Vaadin push endpoint (#15188) (#15330) Removes pushUrl configuration option, and instead maps push always to a dedicated path (/VAADIN/push). Related-to #14641 C... — committed to vaadin/flow by knoobie 2 years ago
- fix: Use root servlet mapping for push url in OSGi case (#15350) Fallback to a root mapping for push in case if not servlet registration is available (OSGi runtime). Related-to https://github.com/... — committed to vaadin/flow by mshabarov 2 years ago
- fix: Use root servlet mapping for push url in OSGi case (#15351) Fallback to a root mapping for push in case if not servlet registration is available (OSGi runtime). Related-to https://github.com/... — committed to vaadin/flow by mshabarov 2 years ago
- fix!: Use dedicated mapping for Vaadin push endpoint (#15188) Removes pushUrl configuration option, and instead maps push always to a dedicated path (/VAADIN/push). Related-to #14641 — committed to vaadin/flow by tepi 2 years ago
- fix: Use root servlet mapping for push url in OSGi case (#15351) Fallback to a root mapping for push in case if not servlet registration is available (OSGi runtime). Related-to https://github.com/... — committed to vaadin/flow by mshabarov 2 years ago
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-heartbeaterrors, 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?