Runtime: Add application/json to System.Net.Mime.MediaTypeNames.Application

[madelson]

API Proposal

(Added by @karelz based on original issue)

Add application/json MIME type (based on JSON RFC 4627 - https://www.ietf.org/rfc/rfc4627.txt)

namespace System.Net.Mime
{
    public static class MediaTypeNames
    {
        public static class Application
        {
            public const string Soap = "application/soap+xml";
            public const string Octet = "application/octet-stream";
            public const string Rtf = "application/rtf";
            public const string Pdf = "application/pdf";
            public const string Zip = "application/zip";
+           public const string Json = "application/json";
+           public const string Xml = "application/xml"
        }
    }
}

Motivation

Common StackOverflow question: https://stackoverflow.com/questions/477816/what-is-the-correct-json-content-type (8.6K upvotes)

Original report

The MediaTypeNames class contains constants for common mime types. Surprisingly, it doesn't contain the type for JSON, which is both extremely common and frequently confused (https://stackoverflow.com/questions/477816/what-is-the-correct-json-content-type). Would it be worth adding a constant entry for this?

[karelz]

Sounds like reasonable and simple request.
The MIME type is defined in JSON RFC: https://www.ietf.org/rfc/rfc4627.txt

@davidsh does it have any side effects we need to discuss? Or is it ok to pass it for API review?
Should we add more values in one batch?

BTW: @madelson I have updated top post to match formal API proposal.

[danmosemsft]

There are many other common media types. Should others be added?

[ghost]

All the non-obsolete ones https://www.iana.org/assignments/media-types/media-types.xhtml, including application/javascript.

[madelson]

@kasper3 that list seems enormous. I imagine that < 1% of these make of > 99% of real-world usage. I also worry that adding the full list would lead that the set of constants is exhaustive, which seems impossible to maintain. In my mind it seems better to establish the notion that these are constants for "commonly-used" mime types, where the type's purpose is preventing typos and similar mistakes when creating attachments or web responses in common scenarios.

[davidsh]

@davidsh does it have any side effects we need to discuss? Or is it ok to pass it for API review?
Should we add more values in one batch?

There are no side affects that I am aware of.

[karelz]

Thanks @davidsh, marking as ready for API review.
If anyone is aware of any other common MIME type used in .NET code, we can add it. I agree with @madelson that we should not add full list just because we can. The value of having long list is very small.

[ghost]

In aspnetcore repos, I found @Tratcher added a brief list: https://github.com/aspnet/BasicMiddleware/blob/1bd071d/src/Microsoft.AspNetCore.ResponseCompression/ResponseCompressionDefaults.cs#L11

Mozilla has a list of commonly used ones on the web (62 items): https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types

[PeterSmithRedmond]

I don't see any reason why this isn't a good idea. I agree that we should not add the entire list of MIME types; it would just get in the way of our end programmers. And in any case, it's not possible to make a complete list because of the common practice of making up new MIME types like application/MY_AWESOME_APP+json.

Many of the Mozilla ones are not useful to our end programmers. We aren't a web browser and we don't need a representation for css files, or open fonts.

The only item in the ASPCORE list that makes sense for us to add would be application/xml. We should actively avoid the test/json one because it's clearly contrary to the RFCs.
public const string Xml = "application/xml";

[karelz]

Updated top post with @PeterSmithRedmond's suggestion.

[madelson]

If we add application/xml here then we'll have both MediaTypeNames.Application.Xml and MediaTypeNames.Text.Xml. Hopefully we'll have sufficient doc comments to help users pick the right one.

[karelz]

@madelson what kind of guidance do you suggest? - It seems both variants are fine - see SO and RFC7303

[karelz]

Should be fairly simple to add (adding new API in ref is the only complication), anyone interested?

[madelson]

@madelson what kind of guidance do you suggest? - It seems both variants are fine

@karelz I'm just thinking that devs who look to this class to resolve issues like the SO question I posted in my original proposal and find both Application.Xml and Text.Xml will inevitably come away confused.

If the two are equivalent, then why list both? If the two are not equivalent, then the doc comments should explain why they are not equivalent to help the user pick the right one.

[karelz]

@madelson I am not sure if it is .NET's place to provide suggestions over RFC. Documenting they are equivalent (per the linked RFC) should address any potential doubts. Most developers in my experience will use the first thing they find anyway.