Error 4xx while downloading a file through API which has second word's intials H for eg. (DX Haley)

Moved to the API forum.

I can't reproduce this error. Here's what happens when I try it:

$ http get "https://api.dropbox.com/1/metadata/auto/Test test.txt" 'Authorization:Bearer <REDACTED>'
HTTP/1.1 200 OK
...
{"read_only": false, "revision": 47485, "bytes": 4, "thumb_exists": false, "rev": "b97d10f8d89e", "modified": "Thu, 02 Apr 2015 15:43:00 +0000", "mime_type": "text/plain", "size": "4 bytes", "path": "/Test test.txt", "is_dir": false, "modifier": null, "root": "dropbox", "client_mtime": "Thu, 02 Apr 2015 15:43:00 +0000", "icon": "page_white_text"}

$ http get "https://api.dropbox.com/1/metadata/auto/Test hest.txt" 'Authorization:Bearer <REDACTED>'
HTTP/1.1 200 OK
...
{"read_only": false, "revision": 47486, "bytes": 4, "thumb_exists": false, "rev": "b97e10f8d89e", "modified": "Thu, 02 Apr 2015 15:43:03 +0000", "mime_type": "text/plain", "size": "4 bytes", "path": "/Test hest.txt", "is_dir": false, "modifier": null, "root": "dropbox", "client_mtime": "Thu, 02 Apr 2015 15:43:03 +0000", "icon": "page_white_text"}

Could you share some more information?

1. What programming language are you using?
2. Are you using an OAuth or Dropbox library? If so, which one?
3. What does GetProperties.getDropBoxMedURI() return?
4. What's the exact value of fileName (both in the successful and unsuccessful calls)?
5. What is the code for OAuthBearerClientRequest, including its buildQueryMessage method? (Perhaps that's from a library?)

I've got same issue.

Just one thing: 'H' letter must be upper case in second word:

If fileName = Test Test > works

fileName = Test Hest > doesn't work

The Android library works fine and the direct request using CURL does not. The answer from server is the page with 4xx error.

My info:

1. C++

2. Custom implementation based on CURL

3. not implemented in our library

4. In my case: Van Halen.mp3 - not successful, Alice Cooper.mp3 - successful

5. Not sure that understand what this mean

Hi Steve

Apologies for late reply, somehow I missed the mail from this thread.

Please find the inline comments

1. What programming language are you using? -- Java
2. Are you using an OAuth or Dropbox library? If so, which one? -- Oauth library(Apache Oltu)
3. What does GetProperties.getDropBoxMedURI() return? (It returns url - https://api.dropbox.com/1/media/auto/)
4. What's the exact value of fileName (both in the successful and unsuccessful calls)? (Filename is already given Second word must start with 'H' try capital letter as mentioned in the above comment)
5. What is the code for OAuthBearerClientRequest , including its buildQueryMessage method? (Perhaps that's from a library?) (same apache oltu)

Please let me know in case you need more information.

Thanks

Ranjodh, can you share the code that actually makes the request? It looks like that library just returns a URL to you, and I suspect there's an error in the code that escapes the URL and makes the HTTP request. Maybe you can share the relevant part of your code?

Denys, similarly, you'll need to share the code you're using to make the request. (Are you using OAuth 1? HMAC signing or PLAINTEXT? Or OAuth 2?)

In both cases, I suspect a URL escaping error, but it's likely that the exact source is different, since you're writing code in different languages and with different libraries.

Steve,

We are using** OAuth2   **

Sorry, I cannot share code. The main strange thing is that we can get metadata from any file except when " H" is in the code. At the moment we fixed this behavior by changing all spaces to %20

Hi Steve

Sorry, we also cannot share the code. We have also handled it by using '%20' as space. Did you try with capital 'H' as mentioned by Denys. Rename file to "Text Hest" and then try. It will reproduce the issue hopefully. I will try to put a sample code on github if got enough time as currently I am bit busy.

Thanks

We've done some additional investigation on this, and to summarize:

• Your respective apps/libraries are apparently not properly escaping the URI path, which results in technically invalid HTTP requests. (That is, they contain unescaped spaces in the URI.)

•  Our web server is somewhat forgiving of these malformed requests normally and is able to service the request, except when the unescaped space is followed by an "H", as that causes a different behavior in the web server's HTTP request parser.

• The solution is to make sure your app always properly encodes the path in the URI. (This applies to more than just spaces.) 

Hi Steve

Thanks for the update, we are using the same library for Google Drive and its working fine, So we are ok with replacing space with '%20' for the time being. Hope you can do something with point 2 mentioned in your comment above.

Thanks

To clarify what Greg said, a space is not an allowed character in a URL. If your code is sending URLs with unescaped spaces in them, then you have a bug, which I'd strongly encourage you to fully fix. If all you did was special-case this one character (a space), you're quite likely to run into more issues when you have URLs with other disallowed characters like question marks, hash signs, parentheses, etc. It's true that some services (including ours) will try to guess at the meaning of the invalid URL you're sending, but relying on this seems like a bad idea.

See http://www.ietf.org/rfc/rfc2396.txt for the details on how URLs needs to be escaped, but also consider just using the http://docs.oracle.com/javase/6/docs/api/java/net/URI.html class, which I believe will handle all the escaping for you.