Add ctor to JsonSerializerOptions that takes serializer defaults

[NikiforovAll]

Fixes #34626

I decided to take over because of no activity of the current assignee. Let me know if I'm moving in the right direction.

[NikiforovAll]

skipped docs/coding-guidelines/updating-ref-source.md: ref-source was updated manually

[stephentoub]

Thanks for working on this.

[layomia]

Pinging ASP.NET folks and @terrajobst as there was some discussion about whether options.Encoder should be set to JavaScriptEncoder.UnsafeRelaxedJsonEscaping when using Web defaults - https://github.com/dotnet/aspnetcore/pull/21016/files#r411571846.

@pranavkm previously mentioned that UnsafeRelaxedJsonEscaping is only safe if the JSON isn't interspersed with markup, and that Web defaults might not convey that this is meant for REST/API scenarios. I just want to be sure about the conclusion here before this PR is merged.

[rynowak]

@layomia - asked me to drop by and confirm whether this matches ASP.NET's expectations. The relevant code is here for anyone who wants to compare.

Some items worth of discussion:

• MaxDepth
• relaxed encoder

For MaxDepth - we did not scientifically compute the number for maxdepth. We have just always had a value of 32 - and yours is 64. I don't foresee a problem with us using 64. So I think we can agree to use your default of 64.

For the encoder - (this is the fun one) we do some pretty subtle stuff. Our main options class doesn't specify an encoder, and we special case it in two places:

• For writing output as JSON response from the server we opt in the relaxed encoder
• For writing JSON in HTML we force the default (strict) encoder

If we want to be technical - JSON as a document/request/response with the content type application/json is always unicode. The JSON specs all agree, that JSON is all unicode all of the time. We use the relaxed encoder when sending JSON over the wire as its own self-contained payload because all consumers should expect it to the unicode.

We don't use the relaxed encoder when JSON is being embedded inside an HTML response, because that's browser-land, and it's much more of a wierd place.

I think regardless of which encoder is used as the default we'll keep our behavior the same. I won't try to cosplay as a security expert. My assumption is that the common task using the "web" settings is to read and write JSON documents for communication with a REST API, so my intuition is that using the relaxed encoding is right.

/cc @GrabYourPitchforks @pranavkm

[NikiforovAll]

My assumption is that the common task using the "web" settings is to read and write JSON documents for communication with a REST API, so my intuition is that using the relaxed encoding is right.

I agree with you on that. Although, just Web option could mislead code clients to potential vulnerability issues. We could provide a more verbose name that communicates usage and intentions.

What do you think about adding separate enum? I this case, developer hits dot in IDE and sees that there is another thingy for HTML

• General
• Web (relaxed encoding)
• WebHtmlClient (default encoding)

---

Waiting for the final decision on this.

[layomia]

I discussed with @terrajobst - since specifying the unsafe relaxed encoder isn't recommended in some scenarios, we shouldn't specify it in a generic "web" default. Developers should specify it atop the default, depending on the scenario, as is done in an example @rynowak provided above. So, the current implementation works fine.

We don't want to have various "web" default variants (WebRest, WebHtml etc) as this would likely introduce the overhead of figuring out what the differences are, particularly if the set of defaults grows.

We'll leave max depth (effective) as 64, since we don't foresee issues with ASP.NET switching to this number.

[NikiforovAll]

@layomia. Could you please clarify the final decision regarding the Encoder?

[layomia]

Just a couple comments, otherwise LGTM. We can merge when addressed & conflicts are fixed.

[NikiforovAll]

@layomia I assume you want me to add/update .NET API Reference Docs. Also, I would like to add a little section to docs/standard/serialization/system-text-json-how-to.md, something like "Use predefined JsonSerializerOptions", but I'm not sure if it is valuable enough.

[NikiforovAll]

@layomia
Unfortunately, I've not found guidance on how to update API Reference Docs. Could you please assist? 🙂

[layomia]

@NikiforovAll, I didn't intend for you to update the docs. We'll handle that e.g. with dotnet/dotnet-api-docs#4284. I was assigning authors to PRs as part of triage. Thanks for reaching out, and sorry for the noise.