Functionality changes

Are you able to retrieve any specific error message or output?

We did recently update these links to use "Transfer-Encoding: chunked" (and accordingly not return the "Content-Length" header) on HTTP/1.1, but HTTP clients should automatically handle this. It's possible yours doesn't, however.

Also, that change was rolled out earlier than you're describing. When was the last time specifically that you saw this working?

Thank you for reply!

Users started to report issue the 3rd February in the evening.

I checked Content-Length in Postman and it was there. These headers I got from Postman:

accept-encoding: identity,gzip
accept-ranges: bytes
cache-control: max-age=60
content-disposition: attachment; filename="2.ogg"; filename*=UTF-8''2.ogg
content-length: 3018658
content-security-policy: sandbox
content-type: audio/ogg
date: Fri, 04 Feb 2022 20:04:06 GMT
etag: 1642877210753874d
pragma: public
referrer-policy: no-referrer
server: envoy
strict-transport-security: max-age=31536000; includeSubDomains; preload
vary: Origin
x-content-security-policy: sandbox
x-content-type-options: nosniff
x-dropbox-request-id: b6165d08b11c4e86ab427e2ef3f9151a
x-dropbox-response-origin: far_remote
x-robots-tag: noindex, nofollow, noimageindex, noindex, nofollow, noimageindex
x-server-response-time: 16
x-webkit-csp: sandbox

I noticed that .ogg audio did not preload.

Except .ogg files I also have .m4a as duplicates. It is strange, but I switched to .m4a and it works. I compared headers of .ogg and .m4a and they were identical.

Now my app seems to work fine, but I am not sure the same won't happen with .m4a.

Do you know why .m4a works, but .ogg does not?

I'm not aware of any reason off hand that .m4a should works but .ogg wouldn't. Note that using Postman may not be representative of your actual video player client on Android though, as they may use different HTTP versions or features. Are you able to get any logging output for the actual client on Android?

I tried to get headers from android, but I didn't find working solution to do it. Thank you for you answers!

Update: in order to temporarily accommodate clients that don’t properly support automatically handling “Transfer-Encoding: chunked”, we’re temporarily rolling back this change, so that these links will no longer use “Transfer-Encoding: chunked” and will instead return “Content-Length” on HTTP/1.1. We will begin rolling that out starting around 2/17. That will be in place until around 3/1. At that point, we will begin using “Transfer-Encoding: chunked” and no longer returning “Content-Length” on HTTP/1.1 again.

Going forward, please ensure that your clients are able to automatically handle both chunked encoding and non-chunked encoding automatically.

grp3 

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this as previously planned. (Regardless, for HTTP compatibility in general, we still recommend you make sure your HTTP clients support both types.) Hope this helps!