I am trying to send a post request though an api. The call requires:
content-type: multipart/form-data; boundary=[boundary_number]
I have used Charles HTTP proxy to watch see what headers/content I need to send.
My Request: (basically copied from Charles' multipart section)
--324a08fa-6b58-424a-a1ad-691123d9d04b
Content-Disposition: form-data; name="message[body]"
Content-Transfer-Encoding: binary
Content-Type: text/plain; charset=utf-8
Content-Length: 5
Text!
--324a08fa-6b58-424a-a1ad-691123d9d04b--
** My Headers:**
My Result:
When I post this in postman, the response just displays 'Loading'
I can't seem to satisfy the content I was wondering if anyone can point me in the right direction.
Any help would be greatly appreciated!
Cheers!
The response is not as expected because the Content-Length of HTTP request body is incorrect. It should be 240, not 238.
For HTTP request in Charles screenshot, the message[body] data is qqq, which is also indicated by Content-Length: 3. However, in your HTTP request in postman, the message[body] data is Text!. While its own Content-length is correct (5), the Content-length of the whole request body is not changed accordingly -- it's still 238, which should be increased to 240.
Related
I'm uploading a screenshot failure png to Test Rail via their API - Here's the code that works in 106:
Request = new RestRequest("/index.php?/api/v2/add_attachment_to_result/85)
.AddHeader("Content-Type", "multipart/form-data")
.AddFile("attachment", "C:\Source\screenshot.png");
IRestResponse AddAttachmentResponse = Client.Post(Request);
The only thing I changed after the upgrade to v107 is the last line:
RestResponse AddAttachmentResponse = Client.PostAsync(Request).GetAwaiter().GetResult();
I now get an error back from the Test Rail API "Bad Request" - here's the documentation on their API: Test Rail Add Attachment API doc - I know the http engine has changed in 107 - what do I need to do differently now?
UPDATE:
It appears that v107 is not sending the Content-Type in the header - here's the output from HttpTracer:
==================== HTTP ERROR REQUEST: [POST] ====================
Authorization: Basic TokenRemoved
Accept: application/json, text/json, text/x-json, text/javascript, *+json, application/xml, text/xml, +xml, *
User-Agent: RestSharp/107.1.1.0
Accept-Encoding: gzip, deflate, br
Cookie: tr_session=7cef485e-1aca-46bb-a773-9d9f5d410ee6
--8eef1c58-a3df-4ddb-a1c5-e081ccf90709
Content-Type: application/octet-stream
Content-Disposition: form-data; name=attachment; filename=Untitled.png; filename=utf-8''Untitled.png
snipped for brevity
Note there is a Content-Type in the body, but none in the header.
Issue link: https://github.com/restsharp/RestSharp/issues/1713
As we discussed, HttpTracer only shows the request headers, and Content-Type is the request header.
When debugging this issue (and a couple of other related issues), we found out that the issue was caused by the server not being able to handle name and filename parameters in the form part (Content-Disposition header) if they are not wrapped in quotes. Strangely enough, adding content disposition directly using ContentDispositionHeaderValue doesn't add quotes by default. After adding them manually it started to work:
fileContent.Headers.ContentDisposition = new ContentDispositionHeaderValue("form-data") {
Name = $"\"{file.Name}\"",
FileName = $"\"{file.FileName}\""
};
My answer is for anyone who experienced a similar issue with 107.1, the latest alpha and the next stable version should handle this properly.
I'm trying to send a file in Postman native to test our API, but I can't get it sent. I've set Request method POST, chosen BODY and added a file (using the file selector) and given the file the key I want it to have. I've also added another key-value (string), which gets sent. This is the request:
POST /api/user/1901594/17406/foto HTTP/1.1
Host: hidden.domain.com
tp-api-token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6ImF4a3Jpc3RpYW5zZW4iLCJ0dGwiOjE1NTYwNDQ0NDh9.7MAp43_4jnPM_QQluc2Ozx-QBowjCIqQzJ8sn9Y7HG0
cache-control: no-cache
Postman-Token: 8c14c293-f769-4391-90a3-c070cba1393a
Content-Type: multipart/form-data; boundary=----
WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="foto"; filename="C:\Users\ander\Downloads\bilder tilhenger\DSC_0178.JPG
Content-Disposition: form-data; name="unikID"
asdf2398
------WebKitFormBoundary7MA4YWxkTrZu0gW--
As you can see the filename is added to the request, but not the actual file itself (it should be, shouldn't it?)
Is this a bug, or am I doing something wrong?
Nothing wrong with the Postman request. It was the PHP extension php-fileinfo who wasn't installed on our new server.
I have a WCF service which I make API requests to.
This API call returns a JSON response object and also is able to return it in GZIP compression as well when "gzip" value is used in "Accept-Encoding" header.
The problem is when I try to get the response in GZIP, Postman shows "Could not get any response" although I see response and response's content are OK (200 status code) in Fiddler and can easily decompress the response content in my C# client.
I took a look in Postman Console but all I see is "Error: incorrect header check".
I hardly tried to find any documentation regarding this header check but couldn't find any.
These are the request headers:
POST /correction/v1/document?lang=US HTTP/1.1
Content-Type: text/plain
Accept-Encoding: gzip
User-Agent: PostmanRuntime/7.6.0
Accept: */*
content-length: 630
Connection: close
These are the response headers:
HTTP/1.1 200 OK
Content-Length: 512
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-HTTPAPI/2.0
Date: Sun, 24 Feb 2019 14:05:50 GMT
Connection: close
The only thing I suspect is wrong is this message from Fiddler:
I integrated this code into mine in order to use GZIP in WCF.
https://github.com/carlosfigueira/WCFSamples/tree/master/MessageEncoder/GZipEncoderAndAutoFormatSelection
Basically, it captures the response before returning to client and use GZipStream for compression.
I got the same issue, I added the following header to fix this issue.
Accept-Encoding : *
I was able to solve a similar issue by using the header Accept-Encoding: */* or if you want to be specific do Accept-Encoding: */* that way the HTTP client will be able to process the response based on the type of encoding received, in the case of a gzip, it will decode the response and show it as normal text.
For me, I removed 'Accept-Encoding' in the request header.
I got this issue when the REST service was returning a zip content (aka. WinZip format). I solved the error by compressing the data using 7zip to produce true gzip format.
So I'm trying to generate HTTP POST form in my embedded application. However I get server 400 error that indicates that something is wrong with my post. I do not have any curl-like libraries, or such, so I need to form the post header from scratch.
const static char *post_header = "POST /v1/avs/speechrecognizer/recognize HTTP/1.1\r\n\
Host: access-alexa-na.amazon.com\r\n\
Authorization: Bearer %s\r\n\
Content-Type: multipart/form-data; boundary=BOUNDARY1234\r\n\
Transfer-Encoding: chunked\r\n\
Content-Length: %d\r\n\
\r\n\r\n\
--BOUNDARY1234\r\n\
Content-Disposition: form-data; name=\"metadata\"\r\n\
Content-Type: application/json; charset=UTF-8\r\n\
\r\n\
{\"messageHeader\": {},\"messageBody\": {\"profile\": \"alexa-close-talk\",\"locale\": \"en-us\",\"format\": \"audio/L16; rate=16000; channels=1\"}}\r\n\
\r\n\r\n\
--BOUNDARY1234\r\n\
Content-Disposition: form-data; name=\"audio\"\r\n\
Content-Type: audio/L16; rate=16000; channels=1\r\n\n";
After the last "\n" I have the wav header and payload itself. I don't have null termination between the wav header and the last request header content. Altough I've tried it and it doesn't seem to make any difference.
My authentication token should be OK (I've verified it with curl). I've used these scripts (https://miguelmota.com/blog/alexa-voice-service-with-curl/) and Amazon documentation as a base. The blogpost has a script that generates multipart payload and it's identical (compared binary dumps) to mine. My only obvious questionmarks are the first part of the query:
"POST /v1/avs/speechrecognizer/recognize HTTP/1.1\r\n\
Host: access-alexa-na.amazon.com\r\n\
Authorization: Bearer %s\r\n\
Content-Type: multipart/form-data; boundary=BOUNDARY1234\r\n\
Transfer-Encoding: chunked\r\n\
Content-Length: %d\r\n\
\r\n\r\n\"
and the curl call with especially the --data-binary part. Should it effect the request body shomehow?
curl -X POST \
-H "Authorization: Bearer ${TOKEN}" \
-H "Content-Type: multipart/form-data; boundary=${BOUNDARY}" \
--data-binary #multipart_body.txt \
https://access-alexa-na.amazon.com/v1/avs/speechrecognizer/recognize \
> response.txt
Any ideas anyone? I'm gettin a bit frustrated with this.
EDIT 1: Just to clarify. The total size of the data is about 200kbytes with the audio data included. The header size with the token is about 1200bytes. I'm sending the stuff in 1k blobs and I get the error after 4k or so. So I don't manage to send the whole thing before the server responds with the error. Also some of the similar cases in Amazon side indicates that 400 in this case points to problem with the header. However they aren't manually forming the posts so I cannot see the whole thing anywhere.
EDIT2:
Also as this is chunked data, I wonder how it affects this?
I mean if I fe chunk the header into parts defined by the --BOUNDARY1234 and max of 512 bytes, how would that work? I mean fe:
--BOUNDARY1234\r\n\ Content-Disposition: form-data; name=\"metadata\"\r\n\ Content-Type: application/json;
charset=UTF-8\r\n\ \r\n\ {\"messageHeader\": {},\"messageBody\":
{\"profile\": \"alexa-close-talk\",\"locale\": \"en-us\",\"format\":
\"audio/L16; rate=16000; channels=1\"}}\r\n\ \r\n\r\n\
Should the there be chunk size right in the start of the transfer before the --BOUNDARY1234 or does the "Content-Disposition" or "Content-Type" affect this somehow? Or should I add the chunk size only to binary payload? Problem here is that the max send block with my HW is 1k. And the total header size is ~1,5k.
I'm trying to understand (and eventually make it work) batch request on the google group API.
With Oauth2 Playground I know how to perform a single request with:
on step 1 authorised API are
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/admin.directory.group.member
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.group
on step 3 I'm making a post request with:
request URI: https://www.googleapis.com/admin/directory/v1/groups/mytestgroup#domain.ext/members
and the body is:
{
"email": "lya#example.com",
"role": "MEMBER"
}
So far so good, but now I'm trying to do the same in a batch request
I tried to follow the explanation here:
https://developers.google.com/admin-sdk/directory/v1/guides/batch#example
but I didn't understood everything so I went there:
https://developers.google.com/storage/docs/json_api/v1/how-tos/batch
So I did the following request with, on step 1 the same API but on step 3:
a post request to:
https://www.googleapis.com/batch
with a custom content-type:
the header is now
multipart/mixed; boundary="batch_foobarbaz"
and in the body request:
--batch_foobarbaz
Content-Type: application/http
POST /admin/directory/v1/groups/mytestgroup#domain.ext/members HTTP/1.1
Content-Type: application/json
content-length: 58
{
"email": "liz#example.com",
"role": "MEMBER"
}
--batch_foobarbaz--
I also tried different variants but I never get to do the correct request, I systematically get 400 error.
Can someone help me with that, I don't know what I can do to correct that.
Thanks in advance, Harold
Okey sorry for the inconvenience, I found my answer. Here is what I've done:
on step 1 authorised API are:
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/admin.directory.group.member
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.group
on step 3 I'm making a post request with:
https://www.googleapis.com/batch
with a custom content-type: multipart/mixed; boundary="batch_foobarbaz"
body request:
--batch_foobarbaz
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /admin/directory/v1/groups/mytestgroup#domain.ext/members HTTP/1.1
Content-type: application/json
{"email": "ldn#example.com", "role": "MEMBER"}
--batch_foobarbaz--
the important part here are the carriage return. They are mandatory after Content-Transfer-Encoding: binary and after Content-type: application/json