RestSharp File upload works in v106.15 fails in 107.1.1 - restsharp

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.

Related

How to pass x-www-form-urlencoded - grant_type=client_credentials in Karate

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.

Multipart File Upload failing with new IntelliJ HTTP Client

I´m trying to get a file upload to my JAX-RS controller working with multipart. I´ve been using the integrated REST HTTP Client of IntelliJ, that is recommending me to switch to the new HTTP Client by using .http files.
However, once I´m doing that I´m unable to do any uploads and I´m running into this exception
exception
java.io.IOException: RESTEASY007550: Unable to get boundary for multipart
request.http
POST http://localhost:8080/content/upload
Accept: */*
Cache-Control: no-cache
Accept-Encoding: multipart/form-data
--null
< path/to/my/file
--null--
What is the correct syntax for performing multipart uploads?
Here's my .http file. Worked.
POST http://127.0.0.1:8000/v1/dataSource/1/table/
Content-Type: multipart/form-data; boundary=WebAppBoundary
--WebAppBoundary
Content-Disposition: form-data; name="csv_files"; filename="insight_modeling_base_node.csv"
< /home/core/Code/work/KG_test/data/insight_modeling_base_node.csv
--WebAppBoundary--
In your case, try adding boundary=null. Or just copy what I pasted here and make some adaptation.

File not being sent in Postman

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.

Postman shows "Could not get any response" even though response is OK

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.

Sending post request to API with multipart content-type

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.