Add new System.Net.Http.Json project/namespace #33459

jozkee · 2020-03-11T01:24:38Z

This PR includes the necessary setup to generate the NuGet package for this project.

Once this is in, our CI will start to generate the preview package requested by the Blazor team.
cc @mkArtakMSFT @terrajobst

Dotnet-GitSync-Bot · 2020-03-11T01:24:41Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

jozkee

Open questions.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs

jozkee · 2020-03-11T01:30:37Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs

+
+            if (mediaType != JsonContent.JsonMediaType &&
+                mediaType != MediaTypeNames.Text.Plain)
+            {


As per the spec, we allow application/json and text/plain only.

If Content-Type is null we assume it as "application/octet-stream" in accordance with section 7.2.1 of the HTTP spec.
This is how Formatting API works as well.

And at the same time, it is contrary to how HttpContent.ReadAsStringAsync works (it allows null content-type and tries to read the content using UTF-8 for that case).

IMO, null Content-Type should default to application/json; charset=utf-8.

And at the same time, it is contrary to how HttpContent.ReadAsStringAsync works (it allows null content-type and tries to read the content using UTF-8 for that case).

I know that JSON does have some rules about BOMs (I believe writing them is forbidden, reading them is left up to implementer?). We should make sure we're consistent with that.

The web is a pretty wild place 👍. There are specs but there are also lots of implementations that don't conform in subtle ways, so this is good advice (and similar to what we do on the server side with JSON).

I would expect this to also support suffix content types. application/<something>+json - https://tools.ietf.org/html/rfc6839

In use by places like github: https://developer.github.com/v3/media/ - it's a newer spec, but lots of more serious and large scale kinds of API design will prefer this over application/json.

We might be able to get away with ignoring text/json which had some usage long ago, but isn't to spec.

I'm a little bit surprised about text/plain. I'm not sure I've seen that in use for JSON.

I can't remember why I put it in the spec; I think it was based on feedback of someone because I wouldn't have been smart enough to put either of these mime types in. If you believe text/plain is wrong let's remove it. Do we consider adding additional mime types in the future as a breaking change? IOW, would people commonly catch exceptions can do something different if a given mime type isn't accepted/produced by the server?

+1 on the support for suffix content type. As of now, you are unable to read problem details responses that MVC produces for error responses. It has a application/problem+json content type.

What I get from this is that we need to white-list the following:

application/json

application/<something>+json

~~text/plain~~

@rynowak @pranavkm Is that correct or is there any other Content-Type you want to add?

Sounds right to me.

Yup, this looks fine. ASP.NET Core has two implementations for calculating media-type subsets:

https://github.com/dotnet/aspnetcore/blob/master/src/Mvc/Mvc.Core/src/Formatters/MediaType.cs#L286-L291

https://github.com/dotnet/aspnetcore/blob/master/src/Http/Headers/src/MediaTypeHeaderValue.cs#L385-L396

The first has fewer code dependencies and might be easier to easier to copy to S.T.Json if you'd like to use it as an implementation.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

joperezr · 2020-03-11T01:53:59Z

src/libraries/System.Net.Http.Json/Directory.Build.props

+  <Import Project="..\Directory.Build.props" />
+  <PropertyGroup>
+    <StrongNameKeyId>Microsoft</StrongNameKeyId>
+    <IsNETCoreApp>true</IsNETCoreApp>


Do we want to ship this inbox as well? I thought this was only goin to be OOB. Assuming that is still the case then you’ll have to remove this line

I think in .NET 5 we probably want this in box (would be my guess) but clearly not for .NET Core 3.1 anymore

...ries/System.Net.Http.Json/tests/FunctionalTests/System.Net.Http.Json.Functional.Tests.csproj

joperezr · 2020-03-11T01:59:27Z

src/libraries/pkg/descriptions.json

@@ -1035,6 +1035,15 @@
      "System.Net.HttpListener"
    ]
  },
+  {
+    "Name": "System.Net.Http.Json",
+    "Description": "Provides extension methods for System.Net.Http.HttpClient and System.Net.Http.HttpContent that focus on ease of use of JSON as the data interchange format for HTTP clients (pending approval).",


Cc @terrajobst to validate what should go here

I'd say:

Suggested change

"Description": "Provides extension methods for System.Net.Http.HttpClient and System.Net.Http.HttpContent that focus on ease of use of JSON as the data interchange format for HTTP clients (pending approval).",

"Description": "Provides extension methods for System.Net.Http.HttpClient and System.Net.Http.HttpContent that perform automatic serialization and deserialization using System.Text.Json.",

joperezr

Left a couple of comments to address, but other than that infrastructure related stuff looks good.

scalablecory

First pass done. There are some possible optimization opportunities, but it looks good overall.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Get.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Put.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs

scalablecory · 2020-03-11T10:14:28Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs

+                throw new NotSupportedException("The provided ContentType is not supported; the supported types are 'application/json' and 'text/plain'.");
+            }
+
+            // Code taken from https://source.dot.net/#System.Net.Http/System/Net/Http/HttpContent.cs,047409be2a4d70a8


Please try to move this code into the Common directory so we can avoid duplicating it.

That code has semantics of determining the encoding out of the content.
Do we want that to apply here as well?

It looks like this code was removed from implementation, so original comment no longer applies.

It is still there, I just moved it to a separate method called GetEncoding, see here. Sorry for not making that clear.

Compared with the logic used to determine the encoding in HttpContent.ReadAsStringAsync (see here), which is very similar to GetEncoding method in this class.

Do we want to apply the same rules here? More precisely, do we want to use the BOM to determine the encoding when is not present in the response? Is it safe? cc @GrabYourPitchforks

@rynowak has any BOM usage shown up in users requests/responses?

I don't see a problem with the logic in GetEncoding - but it probably does more than we need. There's a few issues at play.

Something I learned when drilling into the question (and would love for @GrabYourPitchforks and/or @Tratcher your weigh in on)...

The RFC for application/json actually mandates encoding sniffing. https://www.ietf.org/rfc/rfc4627.txt (section 3).

JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.

Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.

00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8

This seems a little bit terrifying... For the record, server-side ASP.NET Core does not implement this. We use the CharSet to get the encoding, and the fallback to UTF8 without BOM.

There are many things that get written in RFCs and not doing in practice. It's pretty common to see JSON with a CharSet even though it's not to spec. So I guess - my preference would be to just use UTF8 when not otherwise specified.

I don't think we need detection based on BOM because it's not common to have a BOM, and it's not common to have non-UTF8. If users are blocked by this, they can work around it by reading the content to a string first.

I tested out what happens you submit UTF8 text with and without a BOM to an ASP.NET Core server. Today we happily accept the content without BOM.

has any BOM usage shown up in users requests/responses?

I can think of an easy way to hit a case with a BOM:

Create a file on disk saved with a UTF8 BOM, call it pokemon.json

Set up a webserver to serve that file

Your webserver will likely assign application/json to the response based on the file extension (ASP.NET Core and IIS both do). Your webserver will likely pass through the entire file contents including the BOM.

I don't have any data about usage info - because I'd need to answer for pretty much every server on the 'net.

Server-side ASP.NET Core does not write a BOM when producing JSON - and we tolerate a BOM while reading JSON - so there's little user evidence about whether this is common.

@rynowak the latest json RFC (there have been a few updates) states:

JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].

Previous specifications of JSON have not required the use of UTF-8 when transmitting JSON text. However, the vast majority of JSON-based software implementations have chosen to use the UTF-8 encoding, to the extent that it is the only encoding that achieves interoperability.

Implementations MUST NOT add a byte order mark (U+FEFF) to the beginning of a networked-transmitted JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.

@rynowak I didn't interpret RFC 4627, Sec. 3, to mandate encoding sniffing. It simply says "SHALL be encoded in Unicode." It gives a technique for implementers to sniff the encoding if they desire, but there's no text here precluding an implementation from using a sidecar mechanism (such as the Content-Type header) to determine the proper encoding to use. I think ASP.NET's behavior is fine. :)

Re: byte-order marks, I'm impartial as to whether we support them. In my experience I've not seen web sites specify both a charset and a BOM in the response. Even in the "reading files from disk" scenario, most web servers realize that they're acting as a pass-through and shouldn't make judgment calls about what the proper charset of the content should be.

If we do support byte-order marks, we shouldn't sniff the BOM itself. Instead, we should continue to rely on the incoming charset, stripping out the BOM only if: (a) it matches the selected encoding's BOM; and (b) it occurs at the beginning of the payload.

But honestly I wouldn't add this behavior unless somebody's asking for it. It's just going to complicate matters.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

scalablecory · 2020-03-11T10:35:44Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

+            => Create(value, CreateMediaType(mediaType ?? throw new ArgumentNullException(nameof(mediaType))), options);
+
+        public static JsonContent Create<T>(T value, MediaTypeHeaderValue mediaType, JsonSerializerOptions? options = null)
+            => new JsonContent(JsonSerializer.SerializeToUtf8Bytes(value, options), typeof(T), value, mediaType);


We don't currently have an HttpContent class with a factory method. That doesn't mean we can't, but I'm interested to hear what people think about a JsonContent<T> class instead.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

stephentoub · 2020-03-11T15:14:41Z

This hasn't been API reviewed yet, has it?

ericstj · 2020-03-11T17:11:48Z

I thought this was API reviewed. I know we've had a couple API review meetings and discussed it. @terrajobst

stephentoub · 2020-03-11T17:14:47Z

Immo's comment on that issue suggests it hasn't:
"We did a brief run in a smaller group; at this point we should go ahead with the implementation first to see what issues we encounter and do the API review after with the complete API set and all modifications we made since then."
and the issue is still marked as being a suggestion rather than approved.

src/libraries/System.Net.Http.Json/ref/System.Net.Http.Json.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Get.cs

stephentoub · 2020-03-11T17:18:29Z

src/libraries/System.Net.Http.Json/pkg/System.Net.Http.Json.pkgproj

+  <Import Project="$([MSBuild]::GetPathOfFileAbove(Directory.Build.props))" />
+  <ItemGroup>
+    <ProjectReference Include="..\ref\System.Net.Http.Json.csproj">
+      <SupportedFramework>net461;netcoreapp2.0;uap10.0.16299;$(AllXamarinFrameworks)</SupportedFramework>


We'll still want an asset for .NET 5, right? Some of the base types involved here have new virtual methods in .NET 5 we'll want to override such that when building for / running on .NET 5, things work as well as possible.

I believe we don't list the latest framework, we list the oldest framework we support and I believe with netcoreapp2.0 should be enough because of the compatibility, but given the new TFM, not sure in this case, @ericstj ?

Correct, this list is fine as it is. The tfm for the ref assembly targets ns2.0 so this support table is correct. As Santi points out, by specifying nca2.0 here it will ensure to valudate from that version and all the newer ones as well.

src/libraries/System.Net.Http.Json/ref/System.Net.Http.Json.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Put.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs

stephentoub · 2020-03-11T17:31:53Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

+        }
+
+        public static JsonContent Create<T>(T value, JsonSerializerOptions? options = null)
+            => Create(value, CreateMediaType(JsonMediaType), options);


This implementation is going to box the T if it's a value type. Is that impactful? The API as it's currently defined can't avoid that, but simply tweaks to the API could, such as if the Value property were made virtual.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Get.cs

stephentoub · 2020-03-11T19:01:03Z

src/libraries/System.Net.Http.Json/ref/System.Net.Http.Json.cs

+    {
+        public static System.Threading.Tasks.Task<object?> GetFromJsonAsync(this System.Net.Http.HttpClient client, string requestUri, System.Type type, System.Text.Json.JsonSerializerOptions? options = null, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) { throw null; }
+        public static System.Threading.Tasks.Task<object?> GetFromJsonAsync(this System.Net.Http.HttpClient client, System.Uri requestUri, System.Type type, System.Text.Json.JsonSerializerOptions? options = null, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) { throw null; }
+        public static System.Threading.Tasks.Task<T> GetFromJsonAsync<T>(this System.Net.Http.HttpClient client, string requestUri, System.Text.Json.JsonSerializerOptions? options = null, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) { throw null; }


This design means that if I want to supply a cancellation token, I always either need to pass a JsonSerializerOptions or I need to name the argument, e.g. cancellationToken: cancellationToken?

That seems unfortunate indeed. We could inject an overload that just takes and a non-optional cancellation token.

scalablecory

only small things. looks good once outstanding comments are addressed.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Get.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Post.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingReadStream.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingWriteStream.cs

jozkee · 2020-03-24T21:16:02Z

@stephentoub I think I already addressed all of the comments; is there anything else you want me to change?

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

GrabYourPitchforks · 2020-03-24T22:33:08Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingReadStream.cs

+        private static readonly int OverflowBufferSize = Encoding.UTF8.GetMaxByteCount(1); // The most number of bytes used to represent a single UTF char
+
+        internal const int MaxByteBufferSize = 4096;
+        internal const int MaxCharBufferSize = 3 * MaxByteBufferSize;


Where did the constant 3 come from?

I think from this thread dotnet/aspnetcore#8362 (comment)

In UTF-8, 1 char worst-case expands to 3 bytes. 1 byte does not expand to 3 chars.

As discussed offline, It does not make sense to expect a char buffer that is 3X the size of byte buffer, should we remove this all together and just use sourceEncoding.GetMaxCharCount(MaxByteBufferSize)?

cc @pranavkm

Feel free to call GetMaxCharCount if you want. Otherwise you can just re-use MaxByteBufferSize for simplicity. Either solution should work.

GrabYourPitchforks · 2020-03-24T22:47:14Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingReadStream.cs

+            if (_charBuffer.Count == 0)
+            {
+                int bytesRead = await ReadInputChars(cancellationToken).ConfigureAwait(false);
+                shouldFlushEncoder = bytesRead == 0;


I don't think this flag is being set correctly. It's possible that if ReadInputChars returns 0, both _byteBuffer and _charBuffer are non-empty. This means that there's still data remaining to be decoded in the source buffer, so we shouldn't set flush = true on the encoder.

This goes back to my question at the top of this file - where did the constants come from? I'm having trouble reasoning about how those affect the logic in ReadInputChars.

As discussed offline, we should flush when no more bytes are read from the underlying stream and _byteBuffer.Count == 0

GrabYourPitchforks · 2020-03-24T22:55:54Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingReadStream.cs

+            // If the destination buffer is smaller than GetMaxByteCount(1), we avoid encoding to the destination and we use the overflow buffer instead.
+            if (readBuffer.Count > OverflowBufferSize || _charBuffer.Count == 0)
+            {
+                _encoder.Convert(_charBuffer.Array!, _charBuffer.Offset, _charBuffer.Count, readBuffer.Array!, readBuffer.Offset, readBuffer.Count,


This could fail if _charBuffer is empty, _encoder contains some leftover state from the previous call, flush = true, and readBuffer is too small to contain the transcoded result. At that point the Convert routine won't be able to make any forward progress at all, and it will throw.

The fix would be to make sure that the destination buffer to which Convert writes is always large enough to make at least some forward progress. I think using your overflow buffer would work well here.

GrabYourPitchforks · 2020-03-24T22:59:54Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingWriteStream.cs

+    internal sealed class TranscodingWriteStream : Stream
+    {
+        internal const int MaxCharBufferSize = 4096;
+        internal const int MaxByteBufferSize = 4 * MaxCharBufferSize;


Where did the constant 4 come from?

This decision comes from dotnet/aspnetcore#12142 (comment).
EDIT: Disregard this comment, I didn't notice that the linked comment is talking about the OverflowBuffer, not the MaxByteBufferSize.

There should at minimum be a comment explaining why the constant was chosen. Keep in mind that the max chars-to-bytes expansion for UTF-8 is 3 (not 4) bytes per char. But clearly we're not transcoding to UTF-8 (since the input was already UTF-8), so using any UTF-8 specific constant would not be correct.

It's perfectly ok if we say something like "this is a reasonable guess for a worst-case expansion for a typical encoding". But IMO there needs to be a comment that says something. :)

Done.
Added the following comment:

Upper bound that limits the byte buffer size to prevent an encoding that has a very poor worst-case scenario.

Now that makes me question if we should limit the char buffer on the Read side for the same reason.

GrabYourPitchforks · 2020-03-24T23:09:05Z

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingWriteStream.cs

+                _charsDecoded += charsDecoded;
+                bufferSegment = bufferSegment.Slice(bytesDecoded);
+
+                if (!decoderCompleted)


No need to put this inside an if block. The decoder will always make as much progress as possible, so it's optimal to call WriteBufferAsync unconditionally.

I don't quite understand what the original author was trying to achieve by skipping WriteBufferAsync on the last decoding but I assume that if we remove this condition, we no longer need to call WriteBufferAsync on FinalWriteAsync.

cc @pranavkm

src/libraries/System.Net.Http.Json/tests/FunctionalTests/JsonContentTests.cs

GrabYourPitchforks

All my remaining comments were nits / code cleanup. The logic LGTM. Thanks for driving this! :)

stephentoub

I left a bunch of additional comments, but otherwise assuming .NET 5-specific work will be done subsequently (e.g. all of the overrides we've discussed), LGTM.

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

src/libraries/System.Net.Http.Json/tests/FunctionalTests/HttpClientJsonExtensionsTests.cs

src/libraries/System.Net.Http.Json/tests/FunctionalTests/HttpContentJsonExtensionsTests.cs

src/libraries/System.Net.Http.Json/tests/FunctionalTests/JsonContentTests.cs

jozkee · 2020-03-26T05:55:52Z

CI issues seem to be unrelated.

jozkee · 2020-03-26T06:04:32Z

I will proceed to merge this.

Next steps:

Add suggestions for .NET 5-only on a subsequent PR.
Port last commits (c4282f2 and beyond) to https://github.com/dotnet/corefx/tree/release/3.1-blazor.

jozkee added area-System.Net.Http area-System.Text.Json labels Mar 11, 2020

jozkee added this to the 5.0 milestone Mar 11, 2020

jozkee requested review from steveharter, layomia, joperezr and a team March 11, 2020 01:24

jozkee self-assigned this Mar 11, 2020

Dotnet-GitSync-Bot added the new-api-needs-documentation label Mar 11, 2020

jozkee commented Mar 11, 2020

View reviewed changes

joperezr reviewed Mar 11, 2020

View reviewed changes

...ries/System.Net.Http.Json/tests/FunctionalTests/System.Net.Http.Json.Functional.Tests.csproj Outdated Show resolved Hide resolved

joperezr reviewed Mar 11, 2020

View reviewed changes

scalablecory reviewed Mar 11, 2020

View reviewed changes

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 11, 2020

davidfowl reviewed Mar 11, 2020

View reviewed changes

src/libraries/System.Net.Http.Json/ref/System.Net.Http.Json.cs Outdated Show resolved Hide resolved

stephentoub reviewed Mar 11, 2020

View reviewed changes

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Get.cs Outdated Show resolved Hide resolved

stephentoub reviewed Mar 11, 2020

View reviewed changes

src/libraries/System.Net.Http.Json/ref/System.Net.Http.Json.cs Outdated Show resolved Hide resolved

davidfowl reviewed Mar 11, 2020

View reviewed changes

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs Outdated Show resolved Hide resolved

stephentoub reviewed Mar 11, 2020

View reviewed changes

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Put.cs Show resolved Hide resolved

stephentoub reviewed Mar 11, 2020

View reviewed changes

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpContentJsonExtensions.cs Outdated Show resolved Hide resolved

stephentoub reviewed Mar 11, 2020

View reviewed changes

src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/HttpClientJsonExtensions.Get.cs Outdated Show resolved Hide resolved

stephentoub reviewed Mar 11, 2020

View reviewed changes

scalablecory approved these changes Mar 24, 2020

View reviewed changes

jaredpar mentioned this pull request Mar 24, 2020

WinHttpHandler test UseClientCertOnHttp2_OSSupportsIt_Success failing #34010

Closed

jozkee added 2 commits March 24, 2020 13:24

Address latest comments.

8190ae6

Perform case-insensitive comparisons on MediaType instead of ToLower.

231085d

GrabYourPitchforks reviewed Mar 24, 2020

View reviewed changes

Address comments related to Transcoding classes.

4970a53

jozkee removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 25, 2020

GrabYourPitchforks approved these changes Mar 25, 2020

View reviewed changes

jaredpar mentioned this pull request Mar 25, 2020

Test Failed: GetAsync_SetCookieContainer_CookieSent failed #12043

Closed

stephentoub approved these changes Mar 25, 2020

View reviewed changes

jaredpar mentioned this pull request Mar 25, 2020

Errors installing the SDK during builds #34015

Closed

jozkee added 3 commits March 25, 2020 19:40

Address feedback

c4282f2

Document TranscodingWriteStream.MaxByteBufferSize

8e16505

Replace MediaTypeHeaderValue.Parse with .ctor since it performs better.

afd6d59

This was referenced Mar 26, 2020

System.CodeDom.Compiler.Tests.CodeCompilerTests.GetResponseFileCmdArgs_ValidCmdArgs_ReturnsExpected test failing in CI #34112

Closed

PostAsyncExpect100Continue_NonSuccessResponse_RequestBodyNotSent - IOException: End of Stream #31220

Closed

joperezr mentioned this pull request Mar 26, 2020

Add new System.Net.Http.Json project/namespace dotnet/corefx#42889

Merged

jozkee merged commit c6d463c into dotnet:master Mar 26, 2020

joperezr mentioned this pull request Mar 26, 2020

Addressing feedback, Documenting TranscodingWriteStream.MaxbyteBuffer Size and Replacing MediaTypeHeaderValue.Parse with .ctor since it performs better dotnet/corefx#42894

Merged

jozkee deleted the HttpJson branch March 26, 2020 19:36

This was referenced Apr 1, 2020

Address .NET 5-specific suggestions for System.Net.Http.Json #34355

Closed

Blazor - Add JsonSerializerOptions as parameter to HttpClient.GetJsonAsync<T> #31551

Closed

jozkee mentioned this pull request Apr 8, 2020

[System.Net.Http.Json] Post method miss overloads for reading content #34157

Open

kinosang mentioned this pull request May 12, 2020

Use System.Net.Http.Json once available openiddict/openiddict-core#922

Closed

jozkee mentioned this pull request Jul 7, 2020

System.Net.Http.Json: Consider relaxing content type verification in ReadFromJsonAsync #38713

Closed

ghost locked as resolved and limited conversation to collaborators Dec 10, 2020

	"Description": "Provides extension methods for System.Net.Http.HttpClient and System.Net.Http.HttpContent that focus on ease of use of JSON as the data interchange format for HTTP clients (pending approval).",
	"Description": "Provides extension methods for System.Net.Http.HttpClient and System.Net.Http.HttpContent that perform automatic serialization and deserialization using System.Text.Json.",

Add new System.Net.Http.Json project/namespace #33459

Add new System.Net.Http.Json project/namespace #33459

Conversation

jozkee commented Mar 11, 2020

Dotnet-GitSync-Bot commented Mar 11, 2020

jozkee left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rynowak Mar 11, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jozkee Mar 23, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

terrajobst Mar 11, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

terrajobst Mar 11, 2020 • edited Loading

Choose a reason for hiding this comment

joperezr left a comment

Choose a reason for hiding this comment

scalablecory left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rynowak Mar 23, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephentoub commented Mar 11, 2020

ericstj commented Mar 11, 2020

stephentoub commented Mar 11, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephentoub Mar 11, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scalablecory left a comment

Choose a reason for hiding this comment

jozkee commented Mar 24, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jozkee Mar 25, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jozkee Mar 25, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GrabYourPitchforks left a comment

Choose a reason for hiding this comment

stephentoub left a comment

Choose a reason for hiding this comment

jozkee commented Mar 26, 2020

jozkee commented Mar 26, 2020 • edited Loading

rynowak Mar 11, 2020 •

edited

Loading

jozkee Mar 23, 2020 •

edited

Loading

terrajobst Mar 11, 2020 •

edited

Loading

terrajobst Mar 11, 2020 •

edited

Loading

rynowak Mar 23, 2020 •

edited

Loading

stephentoub Mar 11, 2020 •

edited

Loading

jozkee commented Mar 24, 2020 •

edited

Loading

jozkee Mar 25, 2020 •

edited

Loading

jozkee Mar 25, 2020 •

edited

Loading

jozkee commented Mar 26, 2020 •

edited

Loading