Are there any plans to support application/x-protobuf content type?

[ryanflowers]

I am hoping to move over to protobuf-es and connect-es. However all of my servers only support application/x-protobuf content type. I see after version 1.3 connect-es now has response content-type validation which does not include application/x-protobuf nor do the docs say its supported. Any insight there? Thank you in advance!

[timostamm]

Connect-ES supports the content-types defined by the Connect, gRPC, and gRPC-Web protocols. I assume your servers use a different or home-grown protocol?

If you're using transports from @connectrpc/connect-web (intended for Web Browsers, supports gRPC-Web and Connect), you can provide your own fetch implementation that rewrites request and response headers. But please keep in mind that all three protocols also define errors in a specific format.

[ryanflowers]

Hello thank you for the speedy response!

I understand that I can supply a fetch callback to connect-web and capture the response to then just override the content type application/x-protobuf to something else. The thing I am trying to figure out is what would that something else be that is the correct mapping. Would it map to application/proto?

I see that Connect protocol uses the application/proto and application/json Content-Types for unary RPCs. For streaming, it uses application/connect+proto and application/connect+json.

My real question was are you planning to support application/x-protobuf content type as an official protocol handler like you do with
application/proto for example?

Sorry I am new to this area so just trying to understand the expectations of this library with what I am working with. I see for example cloudflare supports application/x-protobuf so it seems it would be a legit option here?

[timostamm]

We are not planning to support other content-types as aliases for the existing content-types. Doing so would be a breaking change to all implementations, and it would make it more complicated to implement the protocol, while not adding any new capabilities to the protocol.

Cloudflare may have specific behavior tied to the application/x-protobuf content-type, but I'm quite sure this is unrelated to the Connect protocol.