Corrupted compressed .js-files for Mac OS / Safari -clients

[ICarryTheDustOfAJourney]

Corrupted compressed .js-files for Mac OS / Safari -clients

[dougwilson]

I don't have a Mac so I'm not sue I will be able to troubleshoot this for you, unfortunately. Would you be willing to dig into the underlying cause?

[ICarryTheDustOfAJourney]

Thx! How can I support you?
Here is a related post on SO

[dougwilson]

Gettng a packet capture of the traffic at the server and the same traffic at the client would help me see if (1) there are any obvious issues with the response from a standards pov and (2) if the response was altered between those two points.

[ICarryTheDustOfAJourney]

I'll try to get a capture, but that may take a while. What format/tool?
Not sure how I can get a tool on Mac OS side, I'm not a Mac user either.

[dougwilson]

I am about to go to work, so won't likely be able to respond for the rest of the day anyhow. The tool you use doesn't matter; whatever works on that OS. Ideally a pcap file is good, but if there is a different format you are restricted to, just upload that and we can work though with that.

[ICarryTheDustOfAJourney]

It occurs only in combination with http2 (https:) using spdy. Http works fine with compression. Is an TLS-encripted capture of any use for you? If not, what else?

I'm new to this level of debuging. Sorry when asking silly questions here.

Update: It works when using module https instead of spdy. Could also be a spdy issue. Can't use HTTP2 for the moment since it is seems to be no drop-in replacement for spdy/https.

[dougwilson]

So I think you are on track to narrow down on what the issue could be happening from. A packet capture can be used even if it is encrypted, but just needs to be decrypted. Decrypting requires having the symmetric key that was exchanged or just having a capture of the ssl handshake and the private key from the server.

Of course if that is a real server with a real cert, don't share the private key, but you could even decrypt locally and then share the decrypted capture, for instance. The Wireshark tools makes it pretty straight forward, for example.

[ICarryTheDustOfAJourney]

OK, I installed wireshark and have to find out, how to decrypt using the key I have.
This may take a while, since I'm rather busy atm.

[ICarryTheDustOfAJourney]

After throwing some hours against it, I'm giving up for the moment:
I followed https://wiki.wireshark.org/TLS?action=show&redirect=SSL#TLS_Decryption

• I'm not able to decrypt using a SSLKEYLOGFILE, Safari's doesn't seem to support that.
• I'm not able to decrypt using the the server's private key .

So I'll live for the moment with Safari on Mac OS users not compressing and keep recommending Chrome & FF, if compression matters. Thx for your time.

No problem here if you close this

[ryhinchey]

Update: It works when using module https instead of spdy. Could also be a spdy issue. Can't use HTTP2 for the moment since it is seems to be no drop-in replacement for spdy/https.

@ICarryTheDustOfAJourney I did a little digging and came across this post from Apple:
https://webkit.org/blog/8569/removing-legacy-spdy-protocol-support/

What version of macOS and iOS were/are you testing on? I wonder if this issue could be replicated in recent versions of these browsers? With SPDY being deprecated for some time, it's certainly possible you hit a bug that doesn't exist in a newer version of Safari.

If you have a minimal reproducible example, I'd be happy to test it as well.

[ryhinchey]

Closing this issue as I don't think there's anything we can do in compression for this at the moment and is probably an issue related to spdy and safari. as always, feel free to re-open if there's a reproducible issue here.