Deserialization fails when Content-Type is null

[Tylerflick]

I recently found a bug where a DELETE response object causes a null reference exception when the response meets the following:

• content-type: null
• body: null
• content-length: 0

This most likely affects all request types.

Looking through the source the issue appears to be line 624 in RestSharp/RestClient.cs where raw.ContentType is being accessed:
if (response.ErrorException == null) { IDeserializer handler = this.GetHandler(raw.ContentType);

There should either be a null check here, or the IRestResponse object raw should be passed into GetHandler() and the null check should be done there.

[hallem]

i agree the code should fail more gracefully but content-type is a required field for restsharp. i'll see what i can do to make this fail better.

[uxsoft]

I was not able to reproduce this issue. How did you get to a state where your response had body and content type null? If i point RestSharp to a server returning an empty response it is handled by RestSharp correctly.

Moreover what object was actually null? if raw.ContentType == null Deserialize doesn't throw and GetHandler checks for null contentType. If raw is null then that is an expected outcome. No codepaths in RestSharp generate a null response.

Unless you can provide a code sample to reproduce this issue I consider it resolved.

[Tylerflick]

I ended up using a different version of the library which did not propagate the error.
I'm fine with closing the issue out.

[uxsoft]

And could you please test it with the version now in master? Maybe the null checks were added after you opened this. If the issue still appears could you please provide a code sample?

If i can reproduce it I can fix it for everybody:)

[Tylerflick]

Maybe the null checks were added after you opened this

They may very well have.

It might be a bit before I can get to it as it was for a project at work which I'm no longer working on. Sorry for not being able to check on this at the moment.

[Qwin]

I got the same issue, and I know why its happening. The following:
await Client.ExecuteTaskAsync<T> (request, token);

Say I put for T is Object. However the server that I am calling won't return any content. Thus the ContentType would be null and the GetHandler would throw a ArgumentNullException. If I had done:
await Client.ExecuteTaskAsync(request, token);

It wouldn't have thrown an error. Mainly because it doesn't expect anything to deserialize.
What I would like to see is that when the contentType is null dont throw an error and just handle it the same way as if there wasn't any content returned.

[kevin-skeepers]

Hello,
I had the same issue as @Qwin I think.
I'm using Polly to wrap RestSharp calls.

And I had some calls that were retrying for no reason: it's because RestSharp itself was throwing an ArgumentNullException, I investigated real quick and managed to grab the content-type null error that RestSharp was throwing. My calls were being retried because RestSharp was going crazy.

Here is my setup:
The client POST or DELETE to my server using await Client.ExecuteTaskAsync<T> (request);
Sometimes the server replies BadRequest.

When ExecuteTaskAsync is typed then I got the RestSharp content-type error. There is no content-type since the method is POST or DELETE.
When ExecuteTaskAsync is not typed then there is no error.

Thanks @Qwin to have mentioned this error, you made me save a solid day of investigating, I made separate calls to ExecuteTaskAsync without type when it's a POST/DELETE/PUT and now my code works fine.

[alexeyzimarev]

Well, as far I can see in the code, we assign deserialiser based on content type. If it is null - we have no idea what to do. But I will have to look once more.

[kevin-skeepers]

Yeah, makes sense. Maybe it should be just extra documentation?
Or, when the method is not GET then ignore the serialize, type, etc. ?

[jdextraze]

I also experience that issue on mono. After looking into the implementation, it seems mono return a null content type from the HttpWebResponse when the header is not present. Other implementation return string.Empty.

Mono source | .Net Core source | .Net Framework source decompile:

[__DynamicallyInvokable]
public override string ContentType
{
  [__DynamicallyInvokable] get
  {
    this.CheckDisposed();
    return this.m_HttpResponseHeaders.ContentType ?? string.Empty;
  }
}