grpc-js: support content-subtype option in http2 transport

[noahziheng]

Hi all,

HTTP2Transport has set the Content-Type Header as application/grpc by default, which library users cannot modify.

The gRPC protocol spec allows using of "content-subtype" just like application/grpc+proto at https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests.

Some gRPC server implementation such as cloudwego/kitex depends on this header to detect the payload codec(like thrift, JSON, etc.).

So this PR has added ~~a new channel option grpc-node.http_content_subtype~~ to let end-users modify the subtype if they need it.

---

Updated(2023-03-15): move option to MetadataOptions as simpler contentSubtype.

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: Ileriayo / name: Ileriayo Adebiyi (9c3291eeaa646d4f2c02ea0fae9004b9c60eb77e, 76717f88a6b3dfd32b4ab74fefb9e421cd857383, 300a23698c970f00554718f0f9951e769860394b)
• :white_check_mark: login: jtimmons / name: Justin Timmons (7c0511f2df79226d1575dff74b559945da44e2ec)
• :white_check_mark: login: murgatroid99 / name: Michael Lumish (a1fde62101881c919dd931d59151d2d6073fa6bd, 5e2fa71713efbf48a90a71f106f007c3f8a7088e, 7e5f58b11220aca8344573fe756393df1df0c3f2, 9886ee2da71ead90f61fb0d6688abb56525a60fd, 5b44a4428fd4a9a9ee6521a3a8bd7f8bb7982841, c2e72e833b46069d0e4d3605b7858fc169e1aed3, 3f527fbdf98684d30152e27fa6e5c4d292b39c68, 321b6603b064f929d839b06815a7bae90edf94e7, 9b61f4adc0cd4fa4fc3a8a53a04030630cdc587b, 0ba7d70fb903fc17b48436ab6a0d7b0bb9dd04a0, 0207979a4d8266f5f2183798e59ff4701d172636, 1bc1cd573c5f953ac62abd1cab24921b5ba71657, c10d973d3815479b2a85fc0e42115956bc6ff430, a114b9f152bf40f9aa293b900a8f0950bf03a6fd, cfa80720995d39e50b08d33efbd90e8a93a35a57)
• :white_check_mark: login: noahziheng / name: Noah Gao (740b315412630367a70d3dc3108b599a0159f4e4, 9f4f880dce792100ee7064d6e6a162cc3adf31db)

[noahziheng]

By the way, the current @grpc/[email protected] branch is not in sync with the master. Is this expected?

[murgatroid99]

The 1.10.x branch being out of sync with master is just a temporary state. It shouldn't impact this change.

This change should be on master, because it's an API addition. I make an exception for channel arguments that are already defined, but aren't implemented, but this doesn't qualify.

Regarding the change itself: as far as I am aware, gRPC Go is the only implementation that currently supports configuring the content subtype, and it does it with a call option. That makes more sense to me, because the content type is really a property of the individual request, not the whole channel. They also have the concept of default call options for the channel is a whole, which we could also consider using in this library to make configuring that behavior simpler.

[noahziheng]

@murgatroid99

Great idea!

Because we haven't other options like "Call Option" that can be passed from Call to Transport. I have moved the contentSubtype option to MetadataOptions, the end-user can set it per call for now.

On the other hand, if this feature needs to be applied to the master. Should I close this PR, and reopen one to merge the master and wait for you or other maintainers to apply it on the @grpc/[email protected] branch?

[murgatroid99]

You can just rebase the changes onto the master branch and then change the PR's branch target to master (or I can do the second part)

[noahziheng]

@murgatroid99

I have rebased and changed the base branch of this PR. Please check it~

[murgatroid99]

I discussed this change with my team, and we have decided not to accept it. As far as I know, only Go supports content subtypes, and we do not want to add that behavior in other languages. Instead, we would be willing to consider other solutions that involve other, non-standardized headers. A gRFC would be needed to formalize the behavior for implementation across the different libraries.

[ejona86]

For some of the reasoning on why we don't want to do the subtypes, see https://github.com/grpc/grpc-java/issues/10959#issuecomment-2015352359 . (I think this is the first written record of the issue.)