We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Functionality changes
Hi!
I play some audio files from dropbox all was great but yesterday something went wrong. I use
get_temporary_link
to get link of the file.
When I play .ogg file via temporary link in my pl...
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?
Greg-DB
Dropbox Staff
Dropbox StaffI'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!
- Greg-DB
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.- Greg-DB
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!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
