open-telemetry
Consider to use custom MIME types?
IANA allows to register custom media types https://www.iana.org/assignments/media-types/media-types.xhtml, should we consider to register "application/otlp-json" and "application/otlp-protobuf" for the HTTP request types?
Currently we are using the "Content-Type: application/json" and "Content-Type: application/protobuf" and rely on the "path" to determine the context format, this is a classic and good way to design a protocol.
The main downside is that multiplexing on the same path different "formats" is impossible (heard from a "friend"), so by registering our own types we can allow users to multiplex traffic on the same endpoint.
The main downside is that multiplexing on the same path different "formats" is impossible (heard from a "friend"), so by registering our own types we can allow users to multiplex traffic on the same endpoint.
This is true if we for example decide to support 2 different JSON formats or 2 different Protobuf formats on the same path. Presumably it could be a way to support future incompatible OTLP2 format on the same path. I am not sure whether this is necessary or we just use different paths to differentiate incompatible formats.
@tigrannajaryan from the issue triage mtg today, setting priority to p2 but feel free to update.
Independently, I wonder if we've considered putting some information such as telemetry.sdk.{name,version} into HTTP or gRPC headers, which would allow us to route traffic based on OTLP version in case of bugs we discover in the future that are not intentional changes of protocol/version?
I'd recommend not using custom formats - as @tigrannajaryan says, for our current two formats the current mime types work great. If they stop working then it may be time to consider but not now since it seems to fit better with the ecosystem - I know Armeria definitely supports the current types out of the box and believe grpc-gateway does too, though admittedly haven't used the latter.
Resurrecting an old issue here....surprised that we hadn't ever hashed this one out. I was looking at the Content-type for an OTLP HTTP request from Java instrumentation today and saw Content-Type: application/x-protobuf. I was a little surprised that we hadn't settled on a way yet for a receiver to know that the protobuf in question contains OTLP data, and which version of OTLP data it conforms to.
One idea is to simply append a parameter (part of the mime type rfc)-- something like Content-Type: application/x-protobuf;otlp=1.1.0. This would allow receivers to potentially route or drop or parse based on the additional parameter.
The version was proposed but didn't make past the proposal.
As for mime type this likely was not done because the need / use case was never clarified.
This would need an OTEP with justification to be added.