Re: [jetty-users] Issue with Jetty Web Sockets behind IIS Reverse Proxy

[Manpreet Singh <manpreet.singh@xxxxxxx>]

Joakim,

 

Thanks for the response, here is what we ended up doing to fix the issue:

Issue is being caused by Jetty supporting deflate per message and the browser requesting this, however IIS does not support this. Due to this browser-Jetty communication via IIS does not support websocket upgrade and the connection fails.

In order to get this working make sure the feature requested by the browser does not reach IIS. In IIS add the following rule in ARR:

Add to server variables:
HTTP_SEC_WEBSOCKET_EXTENSIONS

Add a blank rewrite rule:
name: Websocket Rule
matches the pattern ^ using regular _expression_

Conditions: (MATCH ALL)

{HTTP_UPGRADE}

matches the pattern ^websocket$

{HTTP_SEC_WEBSOCKET_EXTENSIONS}

matches the pattern .

Server variables:
HTTP_SEC_WEBSOCKET_EXTENSIONS value ;
replace existing

Action type: NONE
do not stop processing.

Make sure the rule is at the top so it gets executed first.

 

Manpreet 

From: jetty-users-bounces@xxxxxxxxxxx <jetty-users-bounces@xxxxxxxxxxx> On Behalf Of Joakim Erdfelt
Sent: Thursday, October 1, 2020 5:10 AM
To: JETTY user mailing list <jetty-users@xxxxxxxxxxx>
Subject: Re: [jetty-users] Issue with Jetty Web Sockets behind IIS Reverse Proxy

 

This wouldn't be the first time we've received reports about IIS messing with the websocket upgrade request headers before it reaches Jetty.

 

Check the headers at the Jetty side, make sure they have the following present (to be a valid WebSocket upgrade request).

This is documented in https://tools.ietf.org/html/rfc6455#section-4.1 (Client Requirements, Page 17, starting with bullet point 1 "The handshake MUST be a valid HTTP request" ...)

• HTTP version MUST be HTTP/1.1
• Request Method MUST be "GET"
• Request header "Upgrade" MUST exist and have only the value "websocket"
• Request header "Connection" MUST exist and contain the value "upgrade" (it can have other values, but it's not desired)
• Request header "Sec-WebSocket-Version" MUST exist and have the value of "13"
• Request header "Sec-WebSocket-Key" MUST exist and have a valid (unique) client specified websocket hash.
• Request header "Sec-WebSocket-Protocol" MAY exist. (optional header, but the client sent it and IIS strips it, you now have an invalid upgrade)
• Request header "Sec-WebSocket-Extensions" MAY exist. (optional header, but the client sent it and IIS strips it, you now have different behavior)

We've had reports that various IIS configurations will mess around with the websocket upgrade request to a point where it is no longer a valid (or intended) upgrade request.

Double / Triple check this.

 

Note that Jetty 9.2.x, the version you came from, supported Alpha/Beta/Draft versions of the WebSocket spec, which are no longer supported on Jetty 9.4.x.

It could be that your version of IIS doesn't support the finalized spec https://tools.ietf.org/html/rfc6455 (published Dec 2011)

Joakim Erdfelt / joakim@xxxxxxxxxxx

 

 

On Thu, Oct 1, 2020 at 12:29 AM Manpreet Singh <manpreet.singh@xxxxxxx> wrote:

Hi,

 

We have a setup where Jetty sits behind an Microsoft IIS Reverse Proxy (via ARR). IIS is 10.5 on Windows 2019. Our Web application deployed in Jetty uses web sockets to render video on the browser.

 

Since we have upgraded from Jetty 9.2.17.v20160517 to  9.4.24.v20191120, the web socket seems to have stopped working. The video doesn’t go through anymore.  Everything else is exactly the same.

If we downgrade Jetty to 9.2.17 it starts working again in the same setup.

If we remove IIS in front of Jetty 9.4.24 it works as well.

If we upgrade Jetty to latest version 9.4.31 it doesn’t work.

 

So there seems to be some incompatibility between MS IIS and Jetty related to web sockets.

 

Does anyone else has run into a similar issue or are there any obvious things that changed between these versions that can impact our scenario?

Can you point us to some troubleshooting techniques/logging recommendations that can be used to diagnose this?

 

Thanks,

Manpreet

 

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users