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