How to pass x-www-form-urlencoded - grant_type=client_credentials in Karate.
Hi,
I am trying to pass value grant_type=client_credentials in the form of x-www-form-urlencoded in karate which i was doing with postman.
i know karate will default set the content type as x-www-form-urlencoded, but can u help what i am doing wrong here?
Karate script:
enter code here
Given url 'http://env/singlesignon/v1/access/token'
And header Authorization = 'Basic c2JsLWFwaWdlZS1lemJvYi1jbGllbnQ6c2JsLWFwaWdlZGllbnQ='
And header X-Correlation-Id = 'alibgefh'
And header X-Consumer = 'APIGEE'
And form field grant_type = 'client_credentials'
When method post
Then status 200
Request headers:
enter code here
Authorization: Basic c2JsLWFwaWdlZS1lemJvYi1jbGllbnQ6c2JsLWFwaWdlZGllbnQ=
Connection: Keep-Alive
Content-Length: 29
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Consumer: APIGEE
X-Correlation-Id: alibgefh
Response:
{"error_description":"Wrong Content Type","error":"Bad Request" }
Maybe your server doesn't like the charset=UTF-8 part (which is a bug on your server). Try adding this line before:
* configure charset = null
Else there is insufficient data in your question. Work with someone in your server-side team if possible. You can try to edit your question with a working cURL command, that might help.
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 tried to send cookies like this this:
PUT http://localhost:8080/platform/rs2/processes/data/4252
Accept: */*
Cache-Control: no-cache
Cookie: {{"TOKEN": "eyJzZXNzaW9uSWQiOiIyMTg2NTQ0Mi0zZDAxLTQ0ZWUtYTFjZC02MjI2MzllYTZhZGEiLCJjdXJyZW50VXNlcklkIjoiMjgxNDk2OTktYjNhMi00MzY1LWE4ZjAtMjYyMzljOTlmMWRkIn0"}}
But in fact they don't come to the server-side.
In 2021 version of IntelliJ you can send cookies with the request like this:
POST url
Accept: application/json
Cookie: name=value; name2=value2
Ref syntax: https://developer.mozilla.org/en/docs/Web/HTTP/Headers/Cookie
There is no need to specify cookie, there is a file http-client.cookies used for recive cookies. If your server-side response with cookie , it would be recorded in this file.
and will be sent to your server-side automatically
https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html#viewingResponse
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.
I would like to be able to attach a file to a conversation, using the REST API. Is it possible? There is a «attachments» to /conversations/{convId}/messages/{itemId} but is that usable? How? The description of that field is not available.
The file API of Circuit supports the upload of attachments. As soon as you received your access token you can POST a message with the byte data. The following example wold upload a file with name test.jpg
POST /rest/v2/fileapi HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Content-Length: 100
Content-Disposition: attachment; filename="test.jpg"
Cache-Control: no-cache
<your content in binary form here>
Usually I am using Postman for my tests since it is very easy to use and supports OAuth 2.0 token generation (https://www.getpostman.com/)
You will receive an result that looks like
{"fileId":"fb211fd6-df53-4b82-824d-986dac47b3e7","attachmentId":"ZmIyMT..."}
If you want to validate your upload you can check it via
GET /rest/v2/fileapi?fileid=fb211fd6-df53-4b82-824d-986dac47b3e7 HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Cache-Control: no-cache
Well that was the easy part, now that you have uploaded the file to the backend you must attach it to a conversation item. Today we do not support UPDATE, i.e. you need to create a new one.
POST /rest/v2/conversations/<conv ID>/messages HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
content=New+Text+Message&attachments=ZmIyMT...
You have to pass the generated attachment ID. After the execution of this requests the file is attached to the conversation.
If you skip the second step the file will not be linked to any conversation, is only accessible by the user who initiates the upload and will be deleted within the next 24 - 48h automatically.
Hope this helps, let me know if you have additional questions.
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.