Hi Manpreet,
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.
Does it also work on 9.4.31 when not using IIS in front of jetty?
Firstly it would be useful to see what the HTTP websocket upgrade request
looks like when it
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 see
A response with a `Connection: close` header (and no `Transfer-Encoding` or
`Content-Length`) indicates it's done sending the payload when the
connection is closed.
This is covered in ...
- https://tools.ietf.org/html/rfc2068#section-4.4 (entry 5)
- https://tools.ietf.org/html/rfc2616#sect
Hi Joakim Erdfelt,
Thanks for the response.
Wanted to understand more on this issue. How is it a valid response header
when both Content-Length and Transfer-Encoding is not set in the response
from jetty? Dont we need any one of these?
If I understand correctly, in Jetty 9.4.x either Content-Len
