Shared File Link Issues

mbvistaprint That does not appear to be a response from Dropbox itself. Can you share a sample value of the "url" variable that would be used in your code?

Sorry about that...   So here's a working HEAD request that returns 200 for us with another Shared Image File:

Hi mbvistaprint,

Hah... 😁 One more bug... 🤷 It's definitely not the same like the one I linked to before.

Here as far as I can see Dropbox server gets confused from Accept-Encoding header. You haven't posted you query, but most probably there your web client pushed all supported encodings. What seems confusing to Dropbox (I have no idea why - just bug). Let's hope that will get solved soon.

You can workaround (temporary, at least) by putting within your request a header like:

Accept-Encoding: identity

That's it. 😉

Good luck.

Greg-DB, I have no idea what's going on, but such bugs are "raining" one after other!? Maybe it's asking better QA... 🧐

Edit: mbvistaprint  my error. You have posted it. And as expected:

---

mbvistaprint wrote:
...

• • • accept-encoding:"gzip, deflate"

...

---

Force replace it! 😉

Thank you Здравко

That definitely got us something. 🙂      So using the identity encoding with the dl=1 url we get back a response at least.    However, I'm still not seeing any "content-length"... It's just empty.... though I do see a "X-Dropbox-Content-Length: 4006971" which looks like it's probably the right value... it's just being provided in the way we're expecting.

mbvistaprint You mentioned both "dl=0" and "dl=1". For clarity, which one are you actually using in your app? For reference, using "dl=0" would only give you the HTML preview page, not the actual file, so that's presumably not what you want. Using "dl=1" would give you the actual file, but would require the client follow one or more redirects first.

It's not clear why you're not getting a response though, and I can't reproduce that. I just tried a HEAD request on your sample link with "dl=1" sending the same request headers you specified for that one and I do get the expected redirects and successful response (that is, a 301, then a 302, then a 200).

---

Greg-DB wrote:

... I just tried a HEAD request on your sample link with "dl=1" sending the same request headers you specified for that one and I do get the expected redirects and successful response (that is, a 301, then a 302, then a 200).

---

Hmm... 🤔 And what about the "content-length" with "the same request headers"? Take a look! Repeat again without gzip. 🙂

Hi,

When I test this in Postman I can only get a response when adding the "Accept-Encoding: Identity" parameter.    But even still I don't get a content-length returned.

-Melissa

Hmm... In such a case I'm up to here. In my test when transfer encoding is off (i.e. set to Identity) "content-length" comes up:

x-content-security-policy: sandbox
x-content-type-options: nosniff
x-robots-tag: noindex, nofollow, noimageindex
x-server-response-time: 46
x-webkit-csp: sandbox
content-type: application/json
accept-encoding: identity,gzip
date: Mon, 14 Feb 2022 22:19:20 GMT
server: envoy
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-robots-tag: noindex, nofollow, noimageindex
content-length: 4006971 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
x-dropbox-response-origin: far_remote
x-dropbox-request-id: 6be667e7c1b0467f85be55d383b06557

 Just a subset of the response.

Здравко Thanks. Just to clarify, I was referring to this portion in particular, which didn't indicate any of that:

---

mbvistaprint wrote:

HEAD

https://www.dropbox.com/s/6djz4es56yb5k1b/SelfExamCardInside.jpg?dl=1

15:02:27.057

Pretty

Raw

HEAD /s/6djz4es56yb5k1b/SelfExamCardInside.jpg

Accept: */*

cache-control: no-cache

---

mbvistaprint Please note that using Postman may not accurately represent what your actual app itself is doing. For instance, it may be using a different version of HTTP itself (the Dropbox servers support both HTTP 1.1 and 2), etc. In any case, we can't provide support for Postman itself, so in case Postman is introducing any complications, please post the full raw HTTP request and response, where applicable for whatever exactly is causing issues for your app. For example, using curl may be more direct.