Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
Hi,
I'm writing to find out if anyone knows of any changes to the Drop Box service around 2/9, 2/10 that may have changed how file information is shared when using the Shared Link. For context, we have customers using our API that use Drop Box to share files with our print service but as of Wednesday this past week the links are no longer working for our service. We're unable to confirm the file size from the shared link. Nothing changed on our customer's side with their sharing and many of these files have been shared with us for years. Other shared files (from Shopify for example) still work with our service so this seems specific to the DropBox shared files. Any ideas what may have changed to cause this?
Thanks!
-Melissa
Alright, I found the response body and header:
{
"Errors": [
{
"ErrorMessage": "Unable to determine file size",
"PropertyName": null
}
],
"Method": "POST",
"StatusCode": 400,
"Uri": "http://prd.documents.vcs.cimpress.io:80/v1/documents/creators/url",
"Guid": "1b456a2c-5e14-46ee-a8eb-af44c535e006",
"Level": 3,
"Message": "Validation error.",
"Timestamp": "2022-02-14T18:51:12.9028064+00:00"
}
@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:
And here's what we're getting with the same request to dropbox:
Or with DL=1 (no response):
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:
PrettyRawHEAD /s/6djz4es56yb5k1b/SelfExamCardInside.jpgAccept: */*cache-control: no-cache
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!