Refit: [BUG] NotSupportedException thrown by SystemTextJsonContentSerializer.DeserializeAsync()

Created on 24 Mar 2020  路  3Comments  路  Source: reactiveui/refit

Describe the bug

In some cases streams associated with HTTP requests do not support getting the Length (I'm not sure which yet). This can lead to the new SystemTextJsonContentSerializer class throwing a NotSupportedException when trying to deserialize an object from the below line of code where the length of the stream is accessed:

https://github.com/reactiveui/refit/blob/cd5a5c4a1f8941244e1e705b839eac0205aa6be7/Refit/SystemTextJsonContentSerializer.cs#L63

 System.NotSupportedException: Specified method is not supported.
    at System.Net.Http.HttpBaseStream.get_Length()
    at Refit.SystemTextJsonContentSerializer.DeserializeAsync[T](HttpContent content) in d:\a\1\s\Refit\SystemTextJsonCo
ntentSerializer.cs:line 63
    at Refit.RequestBuilderImplementation.DeserializeContentAsync[T](HttpResponseMessage resp, HttpContent content) in d
:\a\1\s\Refit\RequestBuilderImplementation.cs:line 317
    at Refit.RequestBuilderImplementation.<>c__DisplayClass14_0`2.<<BuildCancellableTaskFuncForMethod>b__0>d.MoveNext()
in d:\a\1\s\Refit\RequestBuilderImplementation.cs:line 279

Steps To Reproduce

I don't yet have a repro outside of the codebase I'm trying to update Refit to 5.1.27 in. Will add if I work out what causes the difference.

Expected behavior

The object is correctly deserialized from the Stream.

Screenshots

N/A

Environment

  • OS: Windows 10
  • Version: .NET Core 3.1.2

Additional context

We had our own implementation of IContentSerializer for System.Text.Json (see #653) and was updating the project to use the built-in one added by #836 when this was found.

bug

Most helpful comment

@martincostello Good catch! You're right, the current implementation just assumes that the input Stream always supports seeking. Let me put together a fix for that real quick by checking whether that's supported, and falling back to the Stream-based deserializer if that's not the case 馃憤

All 3 comments

My guess is that if the response is more than a certain size (or there's no content-length response header) it gets streamed back to the client, so Length is unknown.

/cc @Sergio0694

@martincostello Good catch! You're right, the current implementation just assumes that the input Stream always supports seeking. Let me put together a fix for that real quick by checking whether that's supported, and falling back to the Stream-based deserializer if that's not the case 馃憤

Was this page helpful?
0 / 5 - 0 ratings