Refit: [BUG] SystemTextJsonContentSerializer is always sending 8192 bytes

Created on 26 Mar 2020  路  8Comments  路  Source: reactiveui/refit

Describe the bug
The SystemTextJsonContentSerializer is always sending 8192 bytes even when data is less than this and is then leaking data from adjacent memory in the request.

Steps To Reproduce
Have not reproduced this outside of my project. I found it with Fiddler when running locally.

Expected behavior
Only the data being sent should be sent in the body.

Screenshots
From Fiddler Syntax View
image

Environment

  • OS: Windows 10
  • Version: 5.1.27

Additional context
This was found after upgrading to 5.1.27 where before I had a custom IContentSerializer performing this work using the following to serialize:
var content = new StringContent(JsonSerializer.Serialize<T>(item, _jsonSerializerOptions.Value), Encoding.UTF8, MediaTypeNames.Application.Json);

bug

Most helpful comment

On further investigation, this is a different issue. I'll open a PR with a proposed fix shortly.

All 8 comments

Hey @acgritt, would you mind testing this out with a new pre-release build that includes the fixes done in https://github.com/reactiveui/refit/pull/866, and see if the issue still persists for you? If it does, could you create a minimal repro or a simple test method I could use to investigate this?
Thanks! 馃槉

I will do so and update later today.

I tested and 5.1.50 does resolve the issue.

That's great, glad to hear that! 馃槃

cc. @clairernovotny looks like the new serializer is fine at this point 馃帀

I think there's a scenario related to this bug that isn't fixed by #866 in version 5.1.54.

I have some end-to-end tests in an application that perform an HTTP PUT of some JSON to another API for a combination for different input values and _sometimes_ the requests fail with an HTTP 400 where they previously worked.

If also tried with and without buffering enabled on the [Body] attribute of the parameter, but that doesn't help either. The intermittent nature of the error suggests to me that maybe there's an issue with the pooled buffer reuse causing later requests to be corrupted and being sent with invalid content.

_Edit_: actually those aren't the right payloads, I'll dig further to get the right ones.

Comparing two requests, it seems that a "bad" one sends Transfer-Encoding: chunked and is encoded, where as the "good" ones send Content-Length instead.

On further investigation, this is a different issue. I'll open a PR with a proposed fix shortly.

On further investigation, this is a different issue. I'll open a PR with a proposed fix shortly.

885

Was this page helpful?
0 / 5 - 0 ratings