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.

[bfcavaco]

Hi,

Using this code: (version 106)

string strResource = AnexoOrdemTrabalhoURL + RefOrdemTrabalho.Replace("/", "%2F") + "/upload";
RestClient client = new(strResource);
RestRequest request = new("", Method.POST);
request.AddHeader("Authorization", CalibryAuthentication.CalibryToken);
request.AddFile("file", strFile, "application/pdf");
var restResponse = client.Execute(request);

I have this: (the file was uploaded)

Then updated to version 107.1.2-alpha.0.14
and user the same code (just changing the necessary that is required on this version):

string strResource = AnexoOrdemTrabalhoURL + RefOrdemTrabalho.Replace("/", "%2F") + "/upload";
RestClient client = new(strResource);
RestRequest request = new("", Method.Post);
request.AddHeader("Authorization", CalibryAuthentication.CalibryToken);
request.AddFile("file", strFile, "application/pdf");
var restResponse = await client.ExecuteAsync(request);

And got this: (the file was not uploaded)

I must be doing something wrong, the only response I get from the server is: "StatusCode: InternalServerError, Content-Type: application/json, Content-Length: 16)"

Do I have do add any other parameter or change something in the code in order for it to work on version 107?
I'm sorry but I just can't manage to solve this.

[alexeyzimarev]

What does this code mean, do you know?

[alexeyzimarev]

Your code with RS 106 is making this request:

Same, with RS 107 latest alpha:

[alexeyzimarev]

The only difference I have seen before is filename*=utf-8.... and it is gone now. The only difference right now is that the parameter name and file name are not quoted. I can make this as a final change, further on I have no idea what could be wrong. If the next alpha won't work again, I'd say you need to ask the server owner/vendor.

[alexeyzimarev]

Here's the request made with 107.1.2-alpha.0.18

You can see those requests for yourself here https://requestbin.com/r/enp1nn2lipju/248wgSbG7XvRjoAPT7teiswbRUn

[bfcavaco]

I'm gonna check with the server maintainer what that StatusCode mean.
I seams that the problem is on the server side, some parameter that I must specify.
I'll give feedback as soon they answer me.

[bfcavaco]

Good news,
It's working on this last version 107.1.2-alpha.0.18
Possibly was that quoted filename you referred.
The same code is working now.

[alexeyzimarev]

Nice. I'm glad that we found the root cause.

[bfcavaco]

Nice. I'm glad that we found the root cause.

Thanks a lot :)