Shared File Link Issues

[mbvistaprint]

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

[Здравко]

---

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

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

[Здравко]

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]

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

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

[Greg-DB]

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

To see the headers received, you can dump "Headers" property of your "response", if you want. 😉

[mbvistaprint]

That is correct!

[Greg-DB]

@mbvistaprint Thanks. In that case, can you share a sample? You should still be receiving a 200, though depending on the type the client may have to follow one or more redirects first (though that aspect shouldn't have changed).