Re: Empty Headers in response from Secure Websocket Upgrade request from Safari
Nevermind, i finally traced it all the way through the problem lies in the
Spring Framework code. For anyone who happens to trip up on the same
problem, our Spring is doing this in WebContentGenerator.applyCacheControl
if (response.containsHeader(HEADER_EXPIRES)) {
// Reset HTTP 1.0 Expires header if present
response.setHeader(HEADER_EXPIRES, "");
}
On Tue, Jul 9, 2019 at 12:03 PM Tom Kuo
wrote:
> I saw this both on 8.5.0.39 and 9.0.14
>>
>
> Oh actually this was also present on the latest 8.5.42
>
Re: Empty Headers in response from Secure Websocket Upgrade request from Safari
> > I saw this both on 8.5.0.39 and 9.0.14 > Oh actually this was also present on the latest 8.5.42
Re: Empty Headers in response from Secure Websocket Upgrade request from Safari
> > Tomcat never sets "Cache-Control: no-store" and I can't find anywhere > where Tomcat sets an empty expire header either. > Looking through the code, I saw AuthenticatorBase set the Expires header if using security constraints and not disabledProxyCaching if it's not a POST request. We use to force ours users into https and if i remove the security constraint then invalid Expires header is not present and things work on safari. I also tested adding the following to the context.xml and verified this also works (e.g. this does NOT produce an empty Expire header) It looks like the date string should be created fine by ConcurrentDateFormat, i wonder if there is some sort of bug in the setting of the header value itself? I saw this both on 8.5.0.39 and 9.0.14
Re: Empty Headers in response from Secure Websocket Upgrade request from Safari
> > The above are from Tomcat to the client, correct? > Yes that's correct.
Re: Empty Headers in response from Secure Websocket Upgrade request from Safari
Hi Chris, Are you able to put a packet analyzer into the mix? My guess is that > part of the TLS handshake is being interpreted by Safari as response dat > a. > I was able to get the traffic and I do see headers being sent back from Tomcat. Here is what the packet sniffer saw HTTP/1.1 101 Cache-Control: no-store Expires: Upgrade: websocket Connection: upgrade Sec-WebSocket-Accept: t9Mczky5DMt17Rmg4NH7k4HToGE= Date: Tue, 02 Jul 2019 15:56:36 GMT It sounds like problem is that the expires header is empty. https://bugs.webkit.org/show_bug.cgi?id=139298
Empty Headers in response from Secure Websocket Upgrade request from Safari
I'm running Tomcat 8.5.39 on an ubuntu 18.04 server that is experiencing some weird results when trying to upgrade a secure websocket request from Safari. Safari is returning an "invalid utf-8 sequence" in the browser console when processing the request, looking at the response headers in Safari devTools i see that there are no response headers being sent back. I also reproduce this Tomcat is being hosted on Windows as well. I turned on debugging on in Tomcat but didn't see anything error out on Tomcat's side. Searching both safari & tomcat forums didn't yield much about this particular scenario. What's interesting is that a non ssl request works fine. Also interestingly enough, when i hit another server using an Apache reverse proxy to handle the SSL handshake and forward off to Tomcat that also works. I tried using the native libs and upgrading to the lastest openssl but the request still fails. No other major browser seems to be doing this (Chrome, FF work fine) I'm kinda at a lost as to why this one particular scenario seems to be failing, any ideas? Thanks, Tom
