Acces thumbnail images for PDFs

---

FoxyLoxy wrote:
...

Is there a way to directly access the thumbnail that Dropbox generates for each file via http?

 

If not, is there a suggested/recommended approach to convert PDF to an image format and use that for a thumbnail?

...

---

Hi FoxyLoxy,

Supported way to get a thumbnail image from wide range of file types is using the API end point 2/files/get_thumbnail_v2 (or use equivalent call in some of Dropbox SDKs). You can embed the image wherever you want directly or store it to Dropbox and create a link to the thumbnail for later use (and so directly available through HTTP). Whatever is more convenient to you.

In Dropbox documentation another way to construct a link for dynamic generation of such images is described (not to store a image which could get outdated), but seems this feature is broken now (on my attempts "Internal Server Error" is the response, persistently).

Hope this gives idea.

FoxyLoxy That's correct, /2/files/get_thumbnail_v2 technically can return thumbnails for PDF files. It doesn't officially document support for PDF files in particular though, so I can't officially recommend relying on that. I will send this along as a request to consider that officially supported, but I can't promise if or when that might be done.

Здравко You mentioned you're getting an "Internal Server Error" on some piece of functionality. Can you share the details so we can look into it? Thanks in advance!

---

Greg-DB wrote:

...

ЗдравкоYou mentioned you're getting an "Internal Server Error" on some piece of functionality. Can you share the details so we can look into it? Thanks in advance!

---

Hi Greg-DB,

Sure, I can. In 2/files/get_thumbnail_v2 description can be seen that connection to this end point can be authenticated using App Authentication. Such type of authentication assumes possibility of using both POST and GET request. Also, authentication and argument should be able pass either as header or as parameters and both are assumed equivalent. Yes but no!!! When I pass headers using GET request:

curl -s -S -o ~/dump.jpg -D - -u "<app key>:<app secret>" -H "Dropbox-API-Arg: {\"resource\": {\".tag\": \"link\",\"url\": \"<shared link>\"},\"size\": \"w64h64\"}" https://content.dropboxapi.com/2/files/get_thumbnail_v2

The result is as expected. Here <app key> and <app secret> are valid ones. <shared link> is valid link to a file able to produce thumbnail. In my case I use a link to arbitrary PDF in my account.

When I try pass the same (or equivalent thing, according to documentation) as parameters:

curl -s -S -o ~/dump.txt -D - -g "https://content.dropboxapi.com/2/files/get_thumbnail_v2?arg={\"resource\":{\".tag\":\"link\",\"url\":\"<shared link>\"},\"size\":\"w128h128\"}&authorization=Basic%20<base64 key&secret>"

 Where <shared link> is the same as above and <base64 key&secret> is produced according documentation from <app key> and <app secret>. Follows the result (response body is empty):

HTTP/1.1 500 Internal Server Error
Server: envoy
Date: Wed, 23 Feb 2022 19:17:38 GMT
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Cache-Control: no-cache
Vary: Dropbox-API-Arg, Authorization, Accept-Encoding
Content-Disposition: attachment; filename=unspecified
Content-Security-Policy: sandbox
X-Webkit-Csp: sandbox
X-Content-Security-Policy: sandbox
Content-Security-Policy: sandbox allow-forms allow-scripts
X-Robots-Tag: noindex, nofollow, noimageindex
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Robots-Tag: noindex, nofollow, noimageindex
X-Dropbox-Response-Origin: remote
X-Dropbox-Request-Id: 81e8c25c686642a3b479972366796ab9
Transfer-Encoding: chunked

I have no idea what's wrong here! As a consequence, such request can not be encoded in a simple link. The same is the result when I try to in web browser (I checked in Firefox). That's it.

Здравко Thanks! That's helpful. I just checked on this, and it looks like that failure is due to an invalid app key and/or secret value, so please double check your values. Additionally, there seems to be a bug on our side with how we handle that error case, resulting in the 500 Internal Server Error being returned, instead of a useful error message/response. I'll ask the team to fix that up.

---

Greg-DB wrote:

... it looks like that failure is due to an invalid app key and/or secret value, so please double check your values. ...

---

Ok, Might be, but there is no reliable way I check it. The following is the way I use to get authentication values. I repeated the test with the same result.

curl -s -S -o ~/dump.txt -D - -g "https://content.dropboxapi.com/2/files/get_thumbnail_v2?arg={\"resource\":{\".tag\":\"link\",\"url\":\"<shared link>\"},\"size\":\"w128h128\"}&authorization=Basic%20$(echo "<app key>:<app secret>" | base64)"

Here used values are correct for sure; they are same as above (first command), but fails still (second command). Is the used algorithm wrong? 🤔 I thought it's the same as described, but...

Здравко You need to use "echo -n " instead of just "echo" in this case. When you don't set "-n", echo includes a trailing newline character which will corrupt your encoded app key/secret value.

Waww🤦🤫... that's something really stupid from my side.

But the issue is still there. 🤯 Just the response changes to "Conflict" with body:

{"error_summary": "not_found/", "error": {".tag": "not_found"}}

Despite the values are correct.  I just checked all them once again. 🤔 Using the same values I can download a thumbnail of the pointed file (values passed as headers).

If you have performed a successful query, can you post the corrected template? 🙏 (just correct the one I posted above; not only the ending new line but whatever is else too)

Add: Full response, if can help:

HTTP/1.1 409 Conflict
Server: envoy
Date: Wed, 23 Feb 2022 21:27:34 GMT
Content-Type: application/json
X-Content-Type-Options: nosniff
Cache-Control: no-cache
Vary: Dropbox-API-Arg, Authorization, Accept-Encoding
Content-Disposition: attachment; filename=unspecified
Content-Security-Policy: sandbox
X-Webkit-Csp: sandbox
X-Content-Security-Policy: sandbox
Content-Security-Policy: sandbox allow-forms allow-scripts
X-Robots-Tag: noindex, nofollow, noimageindex
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Robots-Tag: noindex, nofollow, noimageindex
X-Dropbox-Response-Origin: remote
X-Dropbox-Request-Id: 8302bd4020194fcfb1c64a0201ecae46
Transfer-Encoding: chunked

Thanks @Greg-DB,

I'll try using /2/files/get_thumbnail_v2. I had assumed this would simply not work at all for PDF files, since they're not mentioned in the list of supported file types.

Здравко Your code does work for me, as long as I add "-n", and plug in my own app key/secret and shared link. That "not_found" error should indicate an issue with the shared link in this case. Make sure you're supplying a valid and accessible shared link value and are encoding it correctly. For instance, it appears your "arg" URL parameter value is not encoded, though it's not clear if that is how you're sending it or if that's just for illustration purposes.

For example, here's a working version of your code, with the "-n" and an encoded arg containing a sample link:

curl -s -S -o ~/dump.txt -D - -g "https://content.dropboxapi.com/2/files/get_thumbnail_v2?arg=%7B%22resource%22%3A%7B%22.tag%22%3A%22link%22%2C%22url%22%3A%22https%3A%2F%2Fwww.dropbox.com%2Fs%2F1xzftgs96f8ksbx%2Ftest.pdf%3Fdl%3D0%22%7D%2C%22size%22%3A%22w128h128%22%7D&authorization=Basic%20$(echo -n "<app key>:<app secret>" | base64)"

Thanks Greg-DB,

It's not exactly missing URL encoding, but you drive my to right direction and I found out what's wrong. Since I have used non ASCII symbols in the file name this seems confuses the function. I have no idea why? There is an easy workaround: I just stripped filename in the link; the name isn't mandatory there. Everything works now. 😉

You can take a look if this can be fixed. To reproduce, just rename your "test.pdf" to something like "тест.pdf", for example. It still works while passed as header, but not as parameter! Anyway... I successfully bypassed the issue. 👍

Thanks again!