AddFile() version 107.1.2-alpha.0.7 not working

[bfcavaco]

Describe the bug
"StatusCode: InternalServerError, Content-Type: application/json, Content-Length: 16)"

To Reproduce
RestClient client = new(strResource);
RestRequest request = new("", Method.Post);
request.AddParameter("Accept-Encoding", "multipart/form-data", ParameterType.HttpHeader);
request.AddParameter("Authorization", CalibryAuthentication.CalibryToken, ParameterType.HttpHeader);
request.AddFile("file", strFile, "application/pdf");
var restResponse = client.ExecuteAsync(request).Result;

Expected behavior
Should return statusCode == "OK"

Stack trace
There is not stack trace for this issue, only the return status:
InternalServerError, Content-Type: application/json, Content-Length: 16)

Desktop (please complete the following information):

• OS: Windows 10
• .NET version 4.8
• Version: 107.1.2-alpha.0.7

Additional context
The bug does not crash the code, only keeps returning the same error.

[CryptxzzX]

I'm also having this issue in version 107.1.1 however its slightly different.
It's not even utilizing the fact I'm using AddFile, my server returns Undefined index from PHP because its not receiving anything at all.

[alexeyzimarev]

I commented in another issue where you commented. I am not sure why you are adding the accept encoding header. File uploads work fine.

[alexeyzimarev]

It's not even utilizing the fact I'm using AddFile, my server returns Undefined index from PHP because its not receiving anything at all.

AddFile works. You can debug your request using requestbin.com

[alexeyzimarev]

@bfcavaco Trace you request, I am sure it's the parameters you add that break it. You only need AddFile.

[alexeyzimarev]

Also, it seems like the server returned you a JSON response, but you never posted it in the issue. The server must be telling you what the issue is.

[bfcavaco]

@bfcavaco Trace you request, I am sure it's the parameters you add that break it. You only need AddFile.

I could be that but:
I tried without the accept-enconding parameter but sill when I run the ExecuteAsync it takes over a minute to finish and returns the following: "StatusCode: 0, Content-Type: , Content-Length: )". According to the API documentation the "accept-enconding" was required, at least on version 106 of restSharp.
I thought was something on the server side, but this code works on previous version 106 of restSharp, so I don't know what I'm doing wrong, after updating to version 107.1.1 the file no longer uploads. Not with this code anyway, maybe it's my fault, but I already tried several different approaches and had no success upload files.

[alexeyzimarev]

Accept-Encoding header is for specifying the encoding accepted by the client for the response. But you are setting it to a value which is not a valid encoding, it's a content type.

Again, you got a JSON response from the server, which probably tells you what is wrong, but you don't expose what the server returned you.

Also, it is always a good idea (and the issue template suggests that) to make test calls to a call tracer like requestbin.com, both with a working request, and a failing request. That way you can easily compare what is the difference between those.

I totally understand your PoV that it used to work, and it doesn't work now. But it is not enough to diagnose the issue. RestSharp v107 doesn't compose requests as the previous version does. It uses content classes derived from HttpContent and adds the content to the HttpRequestMessage, which is sent to the server by HttpClient. And normally it "just works", but there are tons of awkward servers that have weird requirements and fail on legit requests, so without knowing (best) what the server wants or (at least) being able to compare a working request with failing request, the issue is impossible to diagnose.

[bfcavaco]

Hi Alexey, Here is the API documentation for uploading a file: [image: image.png] And here are the setting using Postman: [image: image.png] Using postman it works, I'm able to upload the file. So, there must be a parameter I'm using incorrectly on restSharp. Best Regards, Bruno Cavaco. Alexey Zimarev ***@***.***> escreveu no dia sábado, 22/01/2022 à(s) 14:28:

…

Accept-Encoding header is for specifying the encoding accepted by the client for the response. But you are setting it to a value which is not a valid encoding, it's a content type. Again, you got a JSON response from the server, which probably tells you what is wrong, but you don't expose what the server returned you. Also, it is always a good idea (and the issue template suggests that) to make test calls to a call tracer like requestbin.com, both with a working request, and a failing request. That way you can easily compare what is the difference between those. I totally understand your PoV that it used to work, and it doesn't work now. But it is not enough to diagnose the issue. RestSharp v107 doesn't compose requests as the previous version does. It uses content classes derived from HttpContent and adds the content to the HttpRequestMessage, which is sent to the server by HttpClient. And normally it "just works", but there are tons of awkward servers that have weird requirements and fail on legit requests, so without knowing (best) what the server wants or (at least) being able to compare a working request with failing request, the issue is impossible to diagnose. — Reply to this email directly, view it on GitHub <#1715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI46KT3VWETLVUXPRKZ63QTUXK5I7ANCNFSM5MOCYYUA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[alexeyzimarev]

No images, sorry

[alexeyzimarev]

I traced the request using your code, for RS 106.15 and the latest 107 alpha. I expected you to do it, but ok.

Here is the request with RS 106:

Here is the same request using RS 107 latest alpha

Apart from the fact that both requests have the wrong Accept-Encoding because you explicitly set it, they look identical. The form boundary looks different, but the form boundary value is a free text according to the standards, so it should work either way.

RS 106 didn't support Brotli, but you can disable it by changing the AllowedDecompressionMethods.

[alexeyzimarev]

I found that people complain about HttpClient with StreamContent is using the filename*=utf-8... that is a part of some obsolete RFC. I am not familiar with the issue, but I made a small change that overrides the default behaviour. In the RestSharp.107.1.2-alpha.0.9 you will get the same content disposition as before.