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

Hi mbvistaprint,Let's hope the bug will be fixed soon. I believe staff working on it will follow up on the forum thread referred above on update.Good luck!.. to all of us. 😉

mbvistaprint Can you share a sample value of the "url" variable there for reference? (There are a few different types of links and options so I want to make sure I know exactly what you're using.) Also, based on this, if you're throwing that particular VcsValidationException exception at the bottom that would indicate that the "(response.StatusCode == HttpStatusCode.OK)" check is failing; that is, you're not getting a 200 status code back. Is that correct?

Hi mbvistaprint,From the description you gave to here, seems your environment is using HTTP protocol version less than 2. Dropbox server "keeps strictly" the "chunked" encoding in such a case and it's difficult to turn it off. The mentioned by me above works for HTTP v2, but not in other (in particular not in v1.1) and there "content-length" is still missing! 🤷 Most probably this is your case. Add: As a workaround, you can change a little bit you function and if it misses "content-length", not to fail immediately but check for "X-Dropbox-Content-Length" before - content is the same. Just a small trick. 😉

mbvistaprint wrote:... We're unable to confirm the file size from the shared link. ...Hi mbvistaprint,To be clear what exactly is the problem, you have to provide some example, at least, or describe the way you are using to "confirm the size". Size is reported correctly as always. Nothing has changed recently related to the size (as far as I know).If I have to bet, not the size confirmation itself is your issue. If you are using HEAD request to perform size confirmation and in advance you check file type then yes, there is a change (bug actually). Check exactly what you are doing, where is the error, and post additional info describing this error.Hope this gives direction. Add: Another possible reason, if you are using HTTP protocol version less than 2 together with HEAD request, "chunked" transfer encoding used by Dropbox "encodes" file size within data transfer itself and so not available within a HEAD response (not in the regular way at least). Check for this too. In such a case file size is still available but in "X-Dropbox-Content-Length" response header. 😉

Thank you! You hit the nail on the head. We are in fact making a HEAD request to get the file size so sounds like that could be where we are running into an issue then. Is there anywhere I can check for updates on bug fixes? This is essentially preventing a number of our customers now from placing orders with us and would require a significant effort on their part to move these to another sharing system. Thanks, Melissa

Shared File Link Issues | The Dropbox Community

Здравко
Legendary | Level 20
4 years ago
mbvistaprint wrote:
... We're unable to confirm the file size from the shared link. ...
Hi mbvistaprint,
To be clear what exactly is the problem, you have to provide some example, at least, or describe the way you are using to "confirm the size". Size is reported correctly as always. Nothing has changed recently related to the size (as far as I know).
If I have to bet, not the size confirmation itself is your issue. If you are using HEAD request to perform size confirmation and in advance you check file type then yes, there is a change (bug actually). Check exactly what you are doing, where is the error, and post additional info describing this error.
Hope this gives direction.

Add: Another possible reason, if you are using HTTP protocol version less than 2 together with HEAD request, "chunked" transfer encoding used by Dropbox "encodes" file size within data transfer itself and so not available within a HEAD response (not in the regular way at least). Check for this too. In such a case file size is still available but in "X-Dropbox-Content-Length" response header. 😉
mbvistaprint
Helpful | Level 5
3 years ago
Thank you! You hit the nail on the head. We are in fact making a HEAD request to get the file size so sounds like that could be where we are running into an issue then. Is there anywhere I can check for updates on bug fixes? This is essentially preventing a number of our customers now from placing orders with us and would require a significant effort on their part to move these to another sharing system.

Thanks,

Melissa
- Здравко
  Legendary | Level 20
  3 years ago
  Hi mbvistaprint,
  Let's hope the bug will be fixed soon. I believe staff working on it will follow up on the forum thread referred above on update.
  Good luck!.. to all of us. 😉
- Greg-DB
  Dropbox Staff
  3 years ago
  mbvistaprint Thanks for the report. Can you clarify a bit around exactly how you're attempting to check the size? The thread Здравко linked to was more about the "Content-Type" than the length. Please share what kind of link you're using and exactly what value (e.g., what header(s)) you're reading so I can check on this for you. If you can show the actual response(s) you're getting as well as what you're expecting to get, that would be helpful.
  - mbvistaprint
    Helpful | Level 5
    3 years ago
    Hi Greg,
    
    I don't know exactly what the response is since I'm just seeing the error returned by our code. I can share with you the call we're making though if that might help:
    
    private bool IsImageLargerThanThreshold(string url) { RestClient tempClient = new RestClient(url); RestRequest tempRequest = new RestRequest(Method.HEAD); tempRequest.AddHeader("Accept", "*/*"); IRestResponse response = tempClient.Execute(tempRequest); if (response.StatusCode == HttpStatusCode.OK) { return response.ContentLength > _asynchThresholdInBytes; } throw new VcsValidationException("Unable to determine file size"); }
    And then we are throwing the exception at the bottom. That's all I'm able to actually see in our logs unfortunately but hoping seeing what we are doing might help. I can confirm that shared links from other sharing services (ex. Files shared out of Shopify) work just fine and until last week Dropbox was also working fine. Unfortunately we have at least 2 (possibly more) of our main API customers using dropbox for their image share so they can't place print orders with us at the moment.
    
    -Melissa

Forum Discussion

Shared File Link Issues

About Dropbox API Support & Feedback

Related Content

Re: Alias shortcut files don't work as expected on Dropbox or on another user's computer

Synchro of one file

Share link .paper

Re: I uploaded a personal file in a shared folder and deleted it. Did my collaborators get notified?

Referral Issue

Recent Discussions

Regarding the condition that "folder_id" is returned in "/sharing/list_folders".

The results of "/files/search_v2" may be different.

"error_description": "missing required field \"grant_type\""

Can't access shared folder metadata

Need help with file uploads to Dropbox for a charity website