About a week ago, POST content.dropboxapi.com/2/files/download started returning 401 when I pass the access token via the authorization URL query parameter (the CORS workaround from the docs). The same token works if I pass it in the Authorization header instead. The URL-parameter method still works on files/upload and files/get_metadata, so it looks specific to files/download.
Header auth — 200
curl -i -X POST https://content.dropboxapi.com/2/files/download \
-H "Authorization: Bearer <TOKEN>" \
-H 'Dropbox-API-Arg: {"path":"<FILE_ID>"}'
URL-parameter auth — 401
curl -i -X POST \
"https://content.dropboxapi.com/2/files/download?authorization=Bearer%20<TOKEN>&arg=%7B%22path%22%3A%22<FILE_ID>%22%7D"
{
"error": {
".tag": "other"
},
"error_summary": "other/...",
"user_message": {
"locale": "en",
"text": "Error in call to API function \"files/download\": Invalid authorization value in HTTP header/URL parameter"
}
}
Same as 2 plus Content-Type: text/plain; charset=dropbox-cors-hack — still 401
curl -i -X POST \
-H "Content-Type: text/plain; charset=dropbox-cors-hack" \
"https://content.dropboxapi.com/2/files/download?authorization=Bearer%20<TOKEN>&arg=%7B%22path%22%3A%22<FILE_ID>%22%7D"
files/upload with the same URL-parameter method — 200
curl -i -X POST \
-H "Content-Type: text/plain; charset=dropbox-cors-hack" \
--data-binary "test" \
"https://content.dropboxapi.com/2/files/upload?authorization=Bearer%20<TOKEN>&arg=%7B%22path%22%3A%22%2Ftest.txt%22%2C%22mode%22%3A%22overwrite%22%2C%22mute%22%3Atrue%7D"
The CORS section of the docs recommends the URL-parameter form to avoid a preflight, so switching to header auth isn't ideal for browser clients. Is the download change intentional, or a regression?
