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
On 02/07/2019 17:29, Tom Kuo wrote: >> >> The above are from Tomcat to the client, correct? >> > > Yes that's correct. It looks like you have some additional component configured that is adding those headers. Tomcat never sets "Cache-Control: no-store" and I can't find anywhere where Tomcat sets an empty expire header either. If you can provide steps to reproduce this from a clean Tomcat install of the latest 9.0.x, 8.5.x or 7.0.x release then I'll take another look. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
On 02/07/2019 17:13, Tom Kuo wrote: > 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. The above are from Tomcat to the client, correct? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
Re: Empty Headers in response from Secure Websocket Upgrade request from Safari
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tom, On 7/1/19 12:17, Tom Kuo wrote: > 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 Well, if Safari is encountering an invalid utf-8 sequence, it's probably aborting immediately. > 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. 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 tried using the native libs and upgrading to the lastest openssl > but the request still fails. What is your configuration? Does this happen when using NIO+JSSE as well, or only JSSE+OpenSSL (or APR+OpenSSL)? > 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? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0adncACgkQHPApP6U8 pFjGTxAAgD6dO6InE5ZTw9PZw5lyif3vmie1UGPwcZhOSJCqZpFO5P4BpECkKtmX xWnlB0wE6EckGx5z7JwqtAukYmVFJHc0AcZTfK8exL2Y3deS6l94ZwGkiLp4Nzla nfa/HXFAeY0ZYInXA7TCMxlCCY+u7l8/4c44hRF1rjKFMB2LgDxxgJk6/tTZCnVX R5V9cD/vFM2LAP088DTy62/JA/7WiJRnoMpDGzCSS18CtCgrjmgvc08YY/+eCZnh eccE0/EOFsWz7cWPRPisfjScuHkYWlAFkOHKqUJPGLQ2U+yu9r80si+xmvlZBGLt 7fBZb7qllBZ6hO7vQlrg617TPHkGTezNyBw8cOKLtqWZiYDSi9G5PP4+UGYFZ6et ljeyDdS/YI2EFr1cN1sac1XWjX9iOXTGxXp+L3jxJP3YCrUS5a8xsn7fqjy5KjXy RxDjzvfyZxY41tWWxx2glCDGmYqAr4ZoaCSblQlpy0aw6NHtHKHUqtr74EuTf3Vo NtEtQVABGaTO7VCnTq/l7C+8BqlCRxBbQJyZJDL56gkB5pVW/ZTqQ8cKLwxN/Rq0 QW4ugljvoyaKG3KYyj89y2tvtdupA1OdCf8//yJTSKyVLQBiESvAwAblxdX1GqJ/ jvfyuitr2/BSEFcgOb+V0RX/dLcUx/scQrE4RT4qf1pzOpDmGkc= =sANa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
