[just_audio] Ignore acceptEncodingHeader from proxy server

[dfdgsdfg]

Ignore accept-encoding Header

If the origin response has the accept-encoding HTTP header with useProxyForRequestHeaders: true, just ignore it.

Because the default HttpServer does not compress responses with GZIP, but the header has accept-encoding, the native encoder throws an error.

Another approach is to add the autoCompress: true option, but I'm not sure it covers all cases.

References

• maybe relatated M4A not buffering on iOS, macOS #881 ?
• https://api.dart.dev/stable/3.4.4/dart-io/HttpServer/autoCompress.html

[ryanheise]

Apologies for the delay, I had computer issues. This looks interesting, I shall review on the weekend. Although if the proxy is just copying the exact headers, wouldn't it be that #881 would be an issue even without the proxy?

[dfdgsdfg]

It seems the accept-encoding header is a fairly robust feature, according to the standard.
http 1.1 accept-encoding header rfc

Issue 881 also includes an accept-encoding and gzip-related option. So, in my opinion, it’s fine to proceed without the proxy, perhaps?

Unfortunately, the URL provided in issue 881 is no longer working, so I couldn’t run the test. However, similar to the example, our m3u8 static media server also goes through AWS CloudFront, with Gzip enabled in the responses.

Cloudfront gzip

For Android, I disable the proxy with useProxyForRequestHeaders: false, and it works well. However, I haven’t tested it on iOS.

[ryanheise]

Note that your change only affects the proxy scenario, and we have no control over what the native os decides to do when we are not using the proxy (hence the question about whether you have observed the issue even without the proxy)

[ryanheise]

Do you have a URL I can test this with?

Also, my preference would be to aim to do a direct passthrough, so with regards to compression, I would prefer that if the native player says it accepts a certain encoding, and the server actually sends a certain encoding, I would like to preserve the encoding that the server sends and just forward that back to the player again so that the middleman is unnoticeable. Maybe that means setting autoUncompress = false on the client and leaving the headers alone. Thoughts?

[ryanheise]

I'd like to test this hypothesis if you have a URL to test on. Am I understanding it correctly that this issue occurs when the server serves a gzipped response because the client declared that it would accept it?

I have never encountered a server that actually gzips audio responses, so it's a bit difficult to reproduce, if that's the case. But if it is the case, I would like to test the approach described in my previous comment.