Recently the dropbox api has been giving me 404 errors when uploading a file. Same code has been working for months. Has anything changed? I'm accessing the rest api through sharpbox.
Error response is below. Part of the request I'm making is below that.
Response:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Mon, 28 Mar 2016 13:20:40 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Dropbox-Request-Id: ed356744df5e9541856f727505cceee0
X-Robots-Tag: noindex, nofollow, noimageindex
2e
{"error": {"file": "Expecting a file upload"}}
0
Request:
POST https://api-content.dropbox.com/1/files/dropbox/VMDVGZION?file=test.pdf&oauth_consumer_key=0o1pqhuy0ul766h&oauth_nonce=f74c8207d9a741929529f1a662804e66&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1459171240&oauth_token=0apqmt3p17e6s69z&oauth_version=1.0&oauth_signature=8i0QAVDTIDyQPUMNZTfDWdFDiyM%3d HTTP/1.1
Content-Type: multipart/form-data; boundary=-----------------------------28947758029299
Host: api-content.dropbox.com
Content-Length: 292539
-------------------------------28947758029299
Content-Disposition: form-data; name="file"; filename="test.pdf";
Content-Type: application/octet-stream
%PDF-1.4 %âãÏÓ
..
-------------------------------28947758029299--
Related
I am attempting to POST an HTTP request to the Mindee API using IntelliJ IDEA's HTTP client. Specifically, I want to upload an image of a receipt. According to the documentation, the form data must have the form
{ file: your_file }
So my question is...how do I specify the field name for a file in IntelliJ's HTTP client? What is the syntax?
I've tried a few different things with similar results. I get
POST https://api.mindee.net/products/expense_receipts/v3/predict
HTTP/1.1 400 BAD REQUEST
Date: Mon, 01 Feb 2021 22:18:15 GMT
Content-Type: application/json
Content-Length: 84
Connection: keep-alive
Server: nginx/1.15.12
Access-Control-Allow-Origin: *
{
"details": {
"file": [
"This field is required."
]
},
"message": "Invalid fields in form"
}
Here are two of my attempts:
POST https://api.mindee.net/products/expense_receipts/v3/predict
Content-Type: multipart/form-data; bundary=boundary
X-Inferuser-Token: <my token>
{
file: < /path/to/image.jpg
}
POST https://api.mindee.net/products/expense_receipts/v3/predict
Content-Type: multipart/form-data; bundary=boundary
X-Inferuser-Token: <my token>
--boundary
Content-Disposition: form-data; name="file"
< /path/to/image.jpg
--boundary--
The second seemed the most promising since it took longer to return a response, but I still got the same thing.
The second attempt request should work okay, but you have a typo in there - bundary instead of boundary.
Just got access to the Google My Business API and have been following the instructions found here: https://developers.google.com/my-business/content/get-started
Project Info
PROJECT_ID=twocents-reviews
PROJECT_NUMBER=705754565185
I'm trying to use the OAuth 2.0 Playground to send my first Google My Business API request to https://mybusiness.googleapis.com/v3/accounts, and this is the response I get (below).
Response
GET /v3/accounts HTTP/1.1
Host: mybusiness.googleapis.com
Content-length: 0
Authorization: Bearer [**** REDACTED ****]
HTTP/1.1 404 Not Found
Content-length: 100
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
X-goog-trace-id: 6748d818415fd6349e9763a87acb707e
Transfer-encoding: chunked
Vary: Origin, X-Origin, Referer
Server: ESF
-content-encoding: gzip
Cache-control: private
Date: Fri, 19 Jan 2018 23:28:51 GMT
X-frame-options: SAMEORIGIN
Alt-svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
Content-type: application/json; charset=UTF-8
{
"error": {
"status": "NOT_FOUND",
"message": "Method not found.",
"code": 404
}
}
Any suggestions?
Google just hadn't finished the setup process yet. All I needed to do was wait a bit longer for the API to work for me.
When using the Structured Data Testing Tool to test my Mom's recipe site page titled Perfect Chicken Fajitas I get the following...
ERROR
The URL was not found. Make sure the domain name is correct and the server is responding with a 200 status code.
However, if I curl for the same URL, I can see that a 200 results...
$ curl -I http://www.lindysez.com/recipe/perfect-chicken-fajitas/
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.5
Set-Cookie: bb2_screener_=1457484500+172.4.33.122; path=/
X-UA-Compatible: IE=edge
Link: <http://www.lindysez.com/wp-json/>; rel="https://api.w.org/"
X-Powered-By: ASP.NET
Date: Wed, 09 Mar 2016 00:48:21 GMT
What could be the problem?
My authorization token is:
oauth_token=""
,oauth_nonce="<unique id>"
,oauth_consumer_key="<consumerKey>"
,oauth_signature_method="HMAC-SHA1"
,oauth_timestamp="<epoch timestamp>"
,oauth_version="1.0"
,oauth_signature="<generated signature>"
(one line, but it has been formatted for legibility)
to generate the signature I run the algorithm using the following message:
POST&https://oauth.intuit.com/oauth/v1/get_request_token&oauth_token="",oauth_nonce="<unique id>",oauth_consumer_key="<consumerKey>",oauth_signature_method="HMAC-SHA1",oauth_timestamp="<epoch timestamp>",oauth_version="1.0"
against my OAuth Consumer Secret and an empty string, like:
"<consumerSecretKey>&<empty>"
, empty because I'm still requesting the access tokens.
then I do a POST
URL:
https://oauth.intuit.com/oauth/v1/get_request_token?oauth_callback=<myCallbackURL>
Header:
Authorization :OAuth <authorizationToken>
Body:
<authorizationToken>
After this rather get the request tokens I get an 401 Unauthorized error (oauth_problem=token_rejected)
Can you please assist?
The get request token call is a GET call.
This is a sample raw request/response-
GET https://oauth.intuit.com/oauth/v1/get_request_token?oauth_callback=oob&oauth_nonce=34562646-ab97-46e1-9aa7-f814d83ef9d1&oauth_consumer_key=qyprd7I5WvVgWDFnPoiBh1ejZn&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1392306961&oauth_version=1.0&oauth_signature=0EtvSnzsuumeyib2fiEcnSyu8%3D HTTP/1.1
Host: oauth.intuit.com
HTTP/1.1 200 OK
Date: Thu, 13 Feb 2014 15:56:03 GMT
Server: Apache
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Length: 150
Connection: close
Content-Type: text/plain
oauth_token_secret=dXhHHMS1EfdrQ32UabOMscIRWt5bLJNX3ZKljjBc&oauth_callback_confirmed=true&oauth_token=qyprdbwXdWrAt0xM2NgkLlJ79yCp4I2SmDg7tahDBPjA6Wti
I'm trying to implement file upload functionality in the iPhone app. Server code is tested and works when files are uploaded from the desktop browser, so I moved to implementing the Objective-C client code. I'm assembling HTTP requests body manually, and despite that it looks correct, it is rejected by the server (server handler unable to extract the parts from multipart content). In desperation I've simplified the form to having only one parameter, but it still does not work.
I've captured the network traffic and I could see that Wireshark could not parse my multipart content as well (have a look at screenshots: Firefox request, iPhone request). I'm pasting it below in hope that you could see the errors I can't see.
Thanks in advance.
Firefox:
POST /cubepaint/actions/gallery/post HTTP/1.1
Host: [...]
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Authorization: Basic [...]
Content-Type: multipart/form-data; boundary=---------------------------20072377098235644401115438165
Content-Length: 180
-----------------------------20072377098235644401115438165
Content-Disposition: form-data; name="deviceId"
12345
-----------------------------20072377098235644401115438165--
HTTP/1.1 200 OK
Date: Sat, 17 Oct 2009 22:09:21 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_python/3.2.10 Python/2.4.4 mod_ssl/2.2.3 OpenSSL/0.9.8c
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
iPhone:
POST /cubepaint/actions/gallery/post HTTP/1.1
Host: [...]
User-Agent: Copenhagen/1.0 CFNetwork/459 Darwin/9.8.0
Content-Type: multipart/form-data; boundary=----------0E7B16E6-CD3D-4213-9B42-07DA30822C74
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Authorization: Basic [...]
Content-Length: 187
Connection: keep-alive
----------0E7B16E6-CD3D-4213-9B42-07DA30822C74
Content-Disposition: form-data; name="deviceId"
00000000-0000-1000-8000-0016CBCC0B61
----------0E7B16E6-CD3D-4213-9B42-07DA30822C74--
HTTP/1.1 200 OK
Date: Sat, 17 Oct 2009 22:04:07 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_python/3.2.10 Python/2.4.4 mod_ssl/2.2.3 OpenSSL/0.9.8c
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Your iPhone version indicates keep-alive but doesn't specify a length. Not sure that's enough to cause trouble.
Also, is it possible your server is checking for user-agent strings it recognizes (say, for backward-compatibility mode)?
I'd also compare the two in a text editor that shows CR/LF characters to make sure you're getting proper line endings.
Another thing you could try is create a simple web-page that does a multipart POST and run it from the iPhone browser (instead of the Mac one) then check the headers that go across the wire. Or you could snag a toolkit like ASIHTTPRequest and see what kind of output it generates for multi-part posts (or just use the toolkit instead of trying to write your own).
Good luck
Solved by reading RFC 2046 (MIME specification): boundary between parts of multipart message should contain two leading '-'s, and last boundary should additionally contain two trailing '-'s. The boundary in the request header and request body in the Firefox request differ:
---------------------------20072377098235644401115438165
and
-----------------------------20072377098235644401115438165
The last boundary looks like this:
-----------------------------20072377098235644401115438165--
You really could not see this with the eye when there are so many leading '-'s in the original boundary.