Usually when I look at the POST requests that are send to a webpage by my browser, they often include Form Data. I then make my own NSURLRequest appending httpbody with similar paramaters, and thus send POST requests to the page I need. However I recently encountered with a situation where a POST request doesn't havve a Form Data at all, but Request Payload instead. I have no idea what it means. Should I send the request appending httpbody with the paramaters from request payload? So far it hasn't been working for me though.
Here how this request payload looks:
------WebKitFormBoundarySomeLettersHere
Content-Disposition: form-data; name="recipient"
theRecipient
------WebKitFormBoundarySomeLettersHere
Content-Disposition: form-data; name="recipients"
theRecipients
------WebKitFormBoundarySomeLettersHere
Content-Disposition: form-data; name="inReplyToPimId"
thePimid
------WebKitFormBoundarySomeLettersHere
Content-Disposition: form-data; name="message"
theMessage
------WebKitFormBoundarySomeLettersHere--
Among the request headers I found interesting:
Accept-Encoding:gzip,deflate,sdch
Content-Type:multipart/form-data; boundary=----WebKitFormBoundarySomeLettersHere
Cookie:JSESSIONID=someId; PPLoggedIn=myId; pimConversation=true
I checked among the cookies I have, that "pimConversation" is missing. Maybe it is the problem? But again I made such cookie and add it to cookies storage.
What do you think I am doing wrong? Thank you in advance!
Related
I am building out an apache HttpClient for a REST service I have, and a app that will be using my service is sending a POST request using "content-disposition: attachment; name="file"; filename="file.txt".
Currently my Client is using "Content-Disposition: form-data; name="file"; filename="test.txt". Currently my request is multipart/mixed, where I am sending a file, and JSON.
Ideally I would need to have my client using the attachment one, but after much research, I have not found anything meaningful. What exactly is the difference between the two content-dispositions?
Attachment is for responses, form-data is for requests. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
GET /services/data/v47.0/sobjects/ContentVersion/0000v00000MFIVgAAP/VersionData from this request I will get binary file content, but how can I use this content to recreate the file properly (using request to POST /services/data/v47.0/sobjects/ContentVersion)?
I uploaded .docx through the UI and fetch its content.
Then I uploded that content using the request:
Endpoint
/services/data/v47.0/sobjects/ContentVersion
Headers
Content-Type:multipart/form-data; boundary=boundary_string
Accept: application/json
Body
--boundary_string
Content-Disposition: form-data; name="entity_content";
Content-type: application/json
{"PathOnClient":"MyFile.docx"}
--boundary_string
Content-Type: application/octet-stream
Content-Disposition: form-data; name="VersionData"; filename="MyFile.docx"
Binary data from the request to GET /services/data/v47.0/sobjects/ContentVersion/0000v00000MFIVgAAP/VersionData.
--boundary_string--
The request above is executed with a success status code, and the file was created successfully, but when I downloaded this file from UI, it became damaged :(
There may be something in the request body that I missed (but I don’t know what exactly is wrong), so the file creates damaged.
trying to understand more about RestFul calls. I understand the format, but what I want to know is how the call is actually sent. For example, if I were to setup Fiddler on my client, and I were to make a RestFul call to http:/thisplace.com/rws with Method = POST and Body = Login HTTP/1.1
Host: client.mydomain.com
Accept: application/xml
Content-type: application/xml
What exactly do I see being sent out from the client on fiddler? Is the information coded inside the URL?
Wondering if RestFul calls can be sent without a third-party tool such as PostMan.
RestFul services use standard HTTP methods (GET, POST, PUT, DELETE, etc). The parameters in a HTTP POST request are sent in the request body which appears after the headers. The information/parameters are not encoded in the URL in a POST request.
The format that the parameters are sent depends on the Content-Type of the request.
In your example you specify content-type: application/xml which means you'd need to provide xml in the request body. In fiddler an HTTP POST to http://thisplace.com/rws might look something like this (for application/xml):
POST http://thisplace.com/rws HTTP/1.1
Content-Type: application/xml
Accept: application/xml
Host: thisplace.com
content-length: 64
<myData>
<value>hello</value>
<value2>world</value2>
</myData>
The request body is below the headers and is the after the blank line where you see the xml.
If you specified application/json the parameters would be encoded as json, and the request body might look like:
{
"value1": "hello",
"value2": "world"
}
For content type application/x-www-form-urlencoded the parameters would be in the same format as a query string and the request body might look like:
value1=hello&value2=world
Yes, RestFul calls can be made without postman but you haven't specified which language/technology you're using or how you'd like to send the requests.
TL;DR
How can I set the Content-Type headers for each individual file/input/text in a multipart/form-data request (in Insomnia)?
I'm trying to POST to the OneNote API (HTTP description) using the Insomnia Rest Client. Per the documentation, I need to submit a multipart/form-data request with one file/text with headers:
Content-Type: text/html
Content-Disposition: form-data; name=presentation
and another with the headers:
Content-Type: application/inkml+xml
Content-Disposition: form-data; name=presentation-onenote-inkml
Here is a screenshot of what I am trying:
As you can see, the API returns an error with No Content-Type leading me to believe that the Content-Type header is not set. The debug information is below:
The POST data is hidden, which does not allow me to see the Content-Type.
Solution: When you use POST with the file arguments, this works. I don't know why.
I have been struggling with this for few days now, (new to fiddler)
My Url looks like this:
mywebservice/miclaim/casedetail/GetCaseDetail/638110079?apikey=MiClaimUK&token=ZD31MsFiLrFA2hCZShBJ7i4iinqeRxfYNrIsDHWriQM=
Now this is a multipart/form-data content type, and i tried a few things to submit my form data like this: (I have no problem submitting file though.. its just the form data along with file!)
adding the values after the token stuff in the query
LossItemId=1&Description=d&ClaimedAmount=1234.5&WherePurchased=reading&BasisOfValuation=basis&Status=sta
or just adding them on the request header but nothing seems to work, I still don't get my form data values in the controller...
I think it must be fairly obvious and usual thing in fiddler to do, but why am in having so much trouble? What am I missing?
Note: I can test my app by a test client using html form ..enctype="multipart/form-data" method="POST"> and it works... but not in Fiddler??
Had to revisit this problem in my project in the context of some other issue..and finally got it working this time around
(for those who might come across a similar issue):
---------------------------acebdf13572468
Content-Disposition: form-data; name="ToDo"
Content-Type: application/json
{"ToDoId":32,"InstructionId":6300460,"Description":"Description","Comment":"Comment","DueDatetime":"2014-02-28T16:44:52.8140079Z","SubmittedDatetime":"2014-02-28T16:44:52.8140079Z","StatusCode":10,"Media":[{"MediaId":0,"MediaDescription":"abc","CreatedDate":"2014-02-28T16:44:52.815008Z","MediaType":"Doc","UrlPath":null},{"MediaId":0,"MediaDescription":"foo","CreatedDate":"2014-02-28T16:44:52.815008Z","MediaType":"Image","UrlPath":null}]}
---------------------------acebdf13572468
Content-Disposition: form-data; name="fieldNameHere"; filename="abc.txt"
Content-Type: text/plain
<#INCLUDE *C:\uploads\abc.txt*#>
---------------------------acebdf13572468
Content-Disposition: form-data; name="fieldNameHere"; filename="Foo.txt"
Content-Type: text/plain
<#INCLUDE *C:\uploads\Foo.txt*#>
---------------------------acebdf13572468--