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
>
>
> 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
>
> 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
>
> The above are from Tomcat to the client, correct?
>
Yes that's correct.
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
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 d
