Runtime: Compression support in System.Net.Http.Json

[Rychu-Pawel]

I'm wondering would it be a good idea to add compression support to the System.Net.Http.Json? For example when you send a post request to a known server that you are sure that accepts gzip compression it would be good to have a method like PostAsGzipJsonAsync or an overload of existing ones taking Compression enum as a param having None by default and GZip and Deflate as options.
It should be fairly easy to achieve this by creating a new JsonGzipContent class inheriting JsonContent that sets one additional Content-Type: gzip header and wraps stream with GZipStream in SerializeToStreamAsync before passing it to the base method.
I'm willing to prepare a PR for it if you agree. If not could you at least please unseal the class?

[scalablecory]

@Jozkee @rynowak

[samsosa]

Transport compression is a classic feature of OSI layer 6. The transport path must provide this, i.e. the http server and the http client. The server and the client must negotiate a compressed encoding which allows payload compression.
IMHO it's not the payload that has to be compressed, it's the transport layer that has to provide it.

See RFC7694 for example.

[ericstj]

@Jozkee please have a look.

[Jozkee]

We currently don't have any other HttpContent that does automatic compression; I don't know if we should be adding a method like PostAsGzipJsonAsync to JsonContent, but I do think that this is a good use case to extend JsonContent and allow users to add compression on top.

thoughts on unsealing JsonContent @stephentoub @terrajobst @rynowak?

[scalablecory]

I'd recommend creating a delegating handler for HttpClient that wraps request content with gzip compressed content. Don't bake it into the content directly.

We could consider adding transparent content compression support directly into SocketsHttpHandler, but I don't know if there's a strong use case for it.

[samsosa]

Don't bake it into the content directly.

Yes, I agree. Payload compression should be kept general and central.

Otherwise, think about where this is all leading to:
StringContent --> StringGzipContent
ByteArrayContent --> ByteArrayGzipContent
MultipartContent --> MultipartGzipContent

[Rychu-Pawel]

Something similar to AutomaticDecompression on HttpMessageHandler?

My original post was suggesting JsonGzipContent because I simply identified an easy way of achieving this by only few lines of code but what I generally mean is that it would be good to have a built-in support for requests compression of any kind in HttpClient 👍

[Jozkee]

It seems like you don't have to extend JsonContent after all. Thanks @scalablecory that's a pretty good suggestion.

I will close this issue now.

[Jozkee]

it would be good to have a built-in support for requests compression of any kind in HttpClient 👍

If you think there is a good use case to have automatic compression on requests over HttpClient, please feel free to open a new issue maybe providing your expected behavior and tag @dotnet/ncl in it.

I think it is a non-trivial topic that would require a bit more discussion.