cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Share your feedback on the Document Scanning Experience in the Dropbox App right here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Shared File Link Issues

Shared File Link Issues

mbvistaprint
Helpful | Level 5

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

29 Replies 29

mbvistaprint
Helpful | Level 5

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"
}

 

Content-Type application/json
Content-Length 322
Connection keep-alive
Date Mon, 14 Feb 2022 18:51:12 GMT
Cache-Control no-cache
Expires -1
Pragma no-cache
Server Microsoft-IIS/10.0
X-AspNet-Version 4.0.30319
X-Powered-By ASP.NET
Access-Control-Allow-Origin *
Vary Origin
X-Kong-Upstream-Latency 553
X-Kong-Proxy-Latency 0
Via kong/0.8.3, 1.1 560ae23eb11e8a754d4876989783ad5e.cloudfront.net (CloudFront)
X-Cache Error from cloudfront
X-Amz-Cf-Pop EWR53-P1
X-Amz-Cf-Id gvwJ9brKD4mKUm2UkbXVlLGeIdv84pbFj6G542jVCTzqv-ifMa8ZJA==

Greg-DB
Dropbox Staff

@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?

mbvistaprint
Helpful | Level 5

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

 

    • Request Headers:
      • Accept:"*/*"
      • cache-control:"no-cache"
      • User-Agent:"PostmanRuntime/7.6.0"
      • Host:"upload.wikimedia.org"
      • accept-encoding:"gzip, deflate"
      • content-length:""
 
    •  
      Response Headers:
      • Date:"Mon, 14 Feb 2022 19:56:24 GMT"
      • Content-Type:"image/gif"
      • Content-Length:"1789"
      • X-Object-Meta-Sha1Base36:"j46h21owxa5nvjxzmreodh4vr4rw2a7"
      • Last-Modified:"Sun, 06 Oct 2013 15:18:28 GMT"
      • Etag:"792456dc6ed5053432e53ea1aaa2a444"
      • X-Timestamp:"1381072707.29367"
      • Server:"ATS/8.0.8"
      • Age:"105"
      • X-Cache:"cp1082 miss, cp1086 hit/1"
      • X-Cache-Status:"hit-front"
      • Server-Timing:"cache;desc="hit-front", host;desc="cp1086""
      • Strict-Transport-Security:"max-age=106384710; includeSubDomains; preload"
      • Report-To:"{ "group": "wm_nel", "max_age": 86400, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c..." }] }"
      • NEL:"{ "report_to": "wm_nel", "max_age": 86400, "failure_fraction": 0.05, "success_fraction": 0.0}"
      • Permissions-Policy:"interest-cohort=()"
      • X-Client-IP:"72.38.236.99"
      • Access-Control-Allow-Origin:"*"
      • Access-Control-Expose-Headers:"Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache"
      • Timing-Allow-Origin:"*"
      • Accept-Ranges:"bytes"
      • Connection:"keep-alive"

 

And here's what we're getting with the same request to dropbox:

 

Pretty
Raw
    •  
      Request Headers:
      • Accept:"*/*"
      • cache-control:"no-cache"
      • User-Agent:"PostmanRuntime/7.6.0"
      • Host:"www.dropbox.com"
      • cookie:"t=VJO2c4CRFqZizRnH5eTAtdBa; locale=en; gvc=MjQyOTU1MzM4NDQ2MzQzNzgzNjAzMTEwODgzMDY2OTExMDM0NTE5; __Host-js_csrf=VJO2c4CRFqZizRnH5eTAtdBa"
      • accept-encoding:"gzip, deflate"
      • content-length:""
 

 

Or with DL=1 (no response):

 

Pretty
Raw
HEAD /s/6djz4es56yb5k1b/SelfExamCardInside.jpg
Accept: */*
cache-control: no-cache

 

 

Здравко
Legendary | Level 20

Hi @mbvistaprint,

Hah... :beaming_face_with_smiling_eyes: 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. :winking_face:

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! :winking_face:

mbvistaprint
Helpful | Level 5

Thank you Здравко

 

That definitely got us something. :slightly_smiling_face:      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.

 

HEAD /s/6djz4es56yb5k1b/SelfExamCardInside.jpg
Accept: */*
Accept-Encoding: identity
cache-control: no-cache
User-Agent: PostmanRuntime/7.6.0
cookie: t=VJO2c4CRFqZizRnH5eTAtdBa; locale=en; gvc=MjQyOTU1MzM4NDQ2MzQzNzgzNjAzMTEwODgzMDY2OTExMDM0NTE5; __Host-js_csrf=VJO2c4CRFqZizRnH5eTAtdBa; __Host-logged-out-session=ChDNFjzU5Y3hv+wpzLJmOiR8ELTpqpAGGi5BQ2NhMWdvc01HbXBJZ3JrcmZUempOT1c4RU54dUR3RE80TzF0U0VSMXdrYUNR
content-length:
 
HTTP/1.1 200
status: 200
Accept-Ranges: bytes
Cache-Control: max-age=60
Content-Disposition: attachment; filename="SelfExamCardInside.jpg"; filename*=UTF-8''SelfExamCardInside.jpg
Content-Security-Policy: sandbox
Etag: 1627768410839975d
Pragma: public
Referrer-Policy: no-referrer
Vary: Origin, Accept-Encoding
X-Content-Security-Policy: sandbox
X-Content-Type-Options: nosniff
X-Dropbox-Content-Length: 4006971
X-Robots-Tag: noindex, nofollow, noimageindex
X-Robots-Tag: noindex, nofollow, noimageindex
X-Server-Response-Time: 21
X-Webkit-Csp: sandbox
Content-Type: application/json
Accept-Encoding: identity,gzip
Date: Mon, 14 Feb 2022 21:32:54 GMT
Server: envoy
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Dropbox-Response-Origin: far_remote
X-Dropbox-Request-Id: 0ae641141a2b4668a508979c25c6bd29
Transfer-Encoding: chunked
 
-Melissa

Greg-DB
Dropbox Staff

@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).

Здравко
Legendary | Level 20

@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... :thinking_face: And what about the "content-length" with "the same request headers"? Take a look! Repeat again without gzip. :slightly_smiling_face:

mbvistaprint
Helpful | Level 5

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

Здравко
Legendary | Level 20

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.

Greg-DB
Dropbox Staff

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


@mbvistaprint wrote:
Pretty
Raw
HEAD /s/6djz4es56yb5k1b/SelfExamCardInside.jpg
Accept: */*
cache-control: no-cache

 

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Greg-DB Dropbox Staff
  • User avatar
    mbvistaprint Helpful | Level 5
  • User avatar
    Здравко Legendary | Level 20
What do Dropbox user levels mean?