Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
No error message with line feed in json header
Hello! During using API I found weird behaviour of dropbox: when sending the new upload request (v2), if there is a 0xA (line feed) character in the end of Dropbox-API-Arg header, server will sen...
- Thanks! That's helpful.
It sounds like the issue is that the extra line feed is making its way into the HTTP request itself. When the resulting HTTP request is interpreted, that extra new line is interpreted as separating the headers from the body, causing the unexpected file data.
I'm not sure if we'll be able to detect and handle that on our side, so do make sure you don't put that in on your side.
Whatever HTTP client you're using doesn't seem to catch this for you, but some HTTP libraries apparently do. For example, the Python requests library stops you from doing this by throwing a "ValueError: Invalid header value" exception.
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorCan you share the code to reproduce this? Thanks in advance!
Some sample code:
string test = "{\"mode\":\"overwrite\",\"path\":\"/testFile.txt\"}";
// Adding the line feed to end of the api-args
// Of cource, I am not adding this intentionally, that character will be in the end of the string from some Json parsing class
test += 0xA;// set this to api-args
string dropboxApiHeader = "Dropbox-API-Arg: ";
request.SetHeader(dropboxApiHeader + test);
// correctly fill all other headers
...
// fill data-binary content
request.SetData("Test text!");
// sending request
request.Send();
And here is what I will get in response:
{"name": "testFile.txt", "path_lower": "/testFile.txt", "path_display": "/testFile.txt","id": Some Id, "client_modified": Some time, "server_modified": Some time, "rev": Some Rev,"size": 0, "content_hash": Some hash}
If I cut out the 0xA from the end of the dropbox-args, then data will be written correctly and size will be not 0.
- Greg-DBThanks! That's helpful.
It sounds like the issue is that the extra line feed is making its way into the HTTP request itself. When the resulting HTTP request is interpreted, that extra new line is interpreted as separating the headers from the body, causing the unexpected file data.
I'm not sure if we'll be able to detect and handle that on our side, so do make sure you don't put that in on your side.
Whatever HTTP client you're using doesn't seem to catch this for you, but some HTTP libraries apparently do. For example, the Python requests library stops you from doing this by throwing a "ValueError: Invalid header value" exception.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
