When i was doing upload file to onedrive with following:
HTTP POST https://apiis.live.net/v5.0/{foldid}/files?access_token={ACCESS_TOKEN}
Content-Type: multipart/form-data; boundary={boundary}
--{boundary}
Content-Disposition: form-data; name="file"; filename="{filename}"
Content-Type: application/octet-stream
{File content goes here}
--{boundary}
by which I follow the guide from https://msdn.microsoft.com/en-us/library/office/dn659726.aspx
It always give me error "java.lang.Exception: HTTP 400. Bad Request".
Would one drive team or anyone help to give me advice what it was going wrong?
Thanks and Best Regards,
Ronald
It seems your request is malformed. I don't know how one drive works but after a quick overview on your link, did you try to remove the 'HTTP' before 'POST' header ?
Or is your file content properly sended ?
From the url, https://apis.live.net/v5.0/{folderid}/files?access_token={ACCESS_TOKEN}, this would indicate you are using the deprecated LiveConnect API. I would recommend using the supported APIs located at https://api.onedrive.com with the upload method described here https://dev.onedrive.com/items/upload_put.htm where the request does not need the multipart mime schema
PUT .../drive/root:/{parent-path}/{filename}:/content
Content-Type: text/plain
The contents of the file goes here.
Get more information about these APIs at https://dev.onedrive.com If the updated uploading method is still causing you trouble, please make sure to include the full HTTP response headers and body.
Related
I built a wix website and wanted to have a database to accept data from a Form. I wrote the codes in wix corvid to accept data after some research. Please refer to attached image links for the code.
In order to test the same, I used http://www.apirequest.io. And it gives me the following error:
Error Submitting Request
Error: Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.
If you site enforces CORS (i.e. Access-Control-Allowed-Origin is set to something other than *), then you may need to allow http://www.apirequest.io.
Regarding the permissions, I have made sure from the settings that 'Anyone can submit data to this collection'.
I am an absolute beginner for web development and http requests. Please support where I went wrong. I would be happy to do further reading on these subjects, please help.
enter image description here
enter image description here
The above question is solved and now it seems that it shouldn't have been here! I was making an error in generating the Http Request.
In case any anyone else is working with wix, the above code is correct in the attached images is correct.
The following http request triggers it:
POST /_functions/firstfunc HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 45
{"Title": "Mr.",
"Name": "John",
"Age": "58"}
I am doing a HTTP POST request from a web client using angular with the following header:
Accept-Encoding: gzip, deflate, br
The server response content-type is application/json. When the response status is 200, everything works fine, my response has a body that I can see from the client. However, when the response status is 400, the response body is empty according to the client, but I am certain I am populating it on the server. Also, if I remove "gzip" from the request header above (no change server-side whatsoever), then everything works fine even with a 400 response status, in other words I can see the response body from the client. I'm running Tomcat with Spring on the server side.
It really seems like gzip is the cause of my problem here, but I don't understand why or how to fix it, any help would be appreciated.
Thanks in advance.
We figured it out, we were using an old version of the ehcache-web library and thus its GZipFilter, which didn't return the response body for any status other than 200. Upgrading to version 2.0.4 of that library fixed the issue.
While integrating FreshDesk in my product,I am stuck with Create Ticket with attachment API. I am using Advanced Rest Client for testing APIs.I have seen many forums and questions on the Stack Overflow itself but I am still not satisfied with any answer pertaining to multipart-form-data POST request for uploading files.
I would like to know the Request Format required in Advanced Rest Client along with headers.
As of now, this is the request I am using but I am not getting a proper response:
-----------------------------7d01ecf406a6
Content-Disposition: form-data;name="files";filename="text1.txt"
Content-Type:text/plain
Its a nice day.
-----------------------------7d01ecf406a6--
I just spent the last hour on this same issue, thinking I was doing something wrong. I eventually gave up on ARC and tried PostMan and set all the values the same and it worked on the server-side (I'm using node.js+hapi) where previously the server was returning 415 with little more info (there's an open issue in Hapi regarding this).
After seeing the requests at the server when using PostMan and considering the UI feedback ARC regarding multi-part (implying it would overwrite any included content-type headers), I've concluded that it's supposed to overwrite/include the content-type header AND provided the boundary, but is not and so my requests were failing.
I've also looked at closed and open issues for ARC ( https://github.com/jarrodek/ChromeRestClient/issues?utf8=%E2%9C%93&q=is%3Aissue%20multipart ) and it looks a lot like there are known issues with multi-part uploads from the client so I'd suggest you not spend too much more time with ARC until you've tried another client to eliminate ARC as the source of your issues.
You need to set proper Content-Type header
Content-Type: multipart/form-data; boundary=---------------------------7d01ecf406a6
Server needs to know what to look for in the request body. In case of multipart/form-data you need to pass the boundary you have used in the Content-Type header.
I can upload small drafts OK using the metadata endpoint (https://www.googleapis.com/gmail/v1/users/me/drafts), e.g.:
{"message":{"raw":"TUlNRS1WZXJzaW9uOiAxLjANClgtTWFpbGVyOiBNYWlsQmVlLk5FVCA3LjAuNC4zMjgNClRvOiBjaHJpcy53b29kQG5vdGFibHlnb29kLmNvbQ0KU3ViamVjdDogdGVzdCENCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KCWJvdW5kYXJ5PSItLS0tPV9OZXh0UGFydF8wMDBfQUFEQV9FOUMzOEZCNy5BMjRFQjI2OSINCg0KDQotLS0tLS09X05leHRQYXJ0XzAwMF9BQURBX0U5QzM4RkI3LkEyNEVCMjY5DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCg0KVGVzdCBjb250ZW50DQotLS0tLS09X05leHRQYXJ0XzAwMF9BQURBX0U5QzM4RkI3LkEyNEVCMjY5DQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsNCgluYW1lPSJUcmFjZS5sb2ciDQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50Ow0KCWZpbGVuYW1lPSJUcmFjZS5sb2ciDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQNCg0KVTNWdUlESTVJRXBoYmlBeU1ERXlJREV5T2pJek9qTTBMalkzTmlBNklDTXhNREExTXpvZ1YxTkJSVU5QVGs1QlFrOVNWRVZFT2lCVA0KYjJaMGQyRnlaU0JqWVhWelpXUWdZMjl1Ym1WamRHbHZiaUJoWW05eWRDNGdJRWc2TURVMU9USWdSam9uU0VOVFRsUlRiMk5yWlhSZg0KVTJWdVpDY2dRVG9uYzJWdVpDY2dWRG9uVTI5amEyVjBQVFUwTUM0Z1JtbHVhWE5vWldRZ2NtVjBjbmxwYm1jdUp5QU5DbE4xYmlBeQ0KT1NCS1lXNGdNakF4TWlBeE1qb3lNem96TkM0Mk9UQWdPaUFqTVRBd09Eb2dSWEp5YjNJNklDQklPakExTlRreUlFWTZKMU5sYm1SVg0KYzJWeVJHVm1hVzVsWkVoVVZGQk5aWE56WVdkbFFtOWtlU2NnVkRvblJYSnliM0lnYzJWdVpHbHVaeUIxYzJWeUlHUmxabWx1WldRZw0KWm1sc1pTQmpiMjUwWlc1MGN5QjBieUJqYkdsbGJuUWdLRUp2WkhrcExpQlNaWFIxY200OUxURXVKeUFOQ2xOMWJpQXlPU0JLWVc0Zw0KTWpBeE1pQXhNam95TXpvek5DNDJPVElnT2lBak1UQXdOVE02SUZkVFFVVkRUMDVPUVVKUFVsUkZSRG9nVTI5bWRIZGhjbVVnWTJGMQ0KYzJWa0lHTnZibTVsWTNScGIyNGdZV0p2Y25RdUlDQklPakExTlRreUlFWTZKMGhEVTA1VVUyOWphMlYwWDFObGJtUW5JRUU2SjNObA0KYm1RbklGUTZKMU52WTJ0bGREMDFOREF1SUVacGJtbHphR1ZrSUhKbGRISjVhVzVuTGljZ0RRcFRkVzRnTWprZ1NtRnVJREl3TVRJZw0KTVRJNk1qTTZNelF1TmprMElEb2dJekV3TURnNklFVnljbTl5T2lBZ1JYSnliM0lnY21WeGRXVnpkR2x1WnlCQ1lYTnBZeUJCZFhSbw0KWlc1MGFXTmhkR2x2Ymk0TkNsTjFiaUF5T1NCS1lXNGdNakF4TWlBeE1qb3lOVG96TVM0NE1EWWdPaUFqTVRBeE5Ub2dVMmgxZEdSdg0KZDI0NklDQkdjbVZsSUZCeWIzaDVJRk5sY25acFkyVWdjM1J2Y0hCbFpDNE5DZz09DQotLS0tLS09X05leHRQYXJ0XzAwMF9BQURBX0U5QzM4RkI3LkEyNEVCMjY5LS0NCg"}}
However, when I try a larger file that's still within the 35MB limit (e.g. an 11MB file), I get the following HTTP WebException:
The remote server returned an error: (413) Request Entity Too Large.
Is this a bug in the new API, or is this down to the fact I should be using the media endpoint instead for this kind of thing? If so, can anybody provide an example of how to do this using the .NET Client?
You need to use the /upload "media upload" path to upload anything over a few MB. The URL and POST format are slightly different:
You'd do:
POST https://www.googleapis.com/upload/gmail/v1/users/userId/drafts
add a HTTP header like "Content-type: multipart/related; boundary=\"part_boundary\""
POST body looks more like:
--part_boundary
Content-Type: application/json; charset=UTF-8
{
}
--part_boundary
Content-Type: message/rfc822
From: script#example.org
To: user#example.com
Subject: test
body here
--part_boundary--
See this for more info (which then links to this).
Content-Length header is missing when I try to download rar, exe, msi static files, though response for images contains Content-Length, but if I change rar extension to jpg it doesn't.
How do I solve this?
What headers do you see? It's possible it's being served using Transfer-Encoding: Chunked, which is a perfectly legitimate way of transferring responses over HTTP.
Also, how are you serving the file - using static files, your code, or the blobstore?
I tried serving a copy of http://googleappengine.googlecode.com/files/GoogleAppEngine_1.3.4.msi as a static fileand experienced the same issue - GAE's response did not include a Content-Length header.
Workaround: If the Content-Length header is critical, then consider hosting your static msi (etc.) file types on a file hosting site (e.g., Dropbox for now.
Edit: This is the intended behavior after all - Nick points out that the files are being transferred with the Transfer-Encoding: Chunked header.