Capture request/response media type

[Blacksmoke16]

What are you trying to achieve?

Capture media type information for a request/response.

Additional context.

Currently the semantic conventions for HTTP spans do not include any attributes related to the media type of the request/response. This makes it impossible to distinguish a request of one type from another of a different type to the same endpoint without manual instrumentation. E.g. how OTLP supports both JSON and protobuf payloads or an API returning JSON or XML encoded data based on the request's Accept header.

Partially related to #1898, as this would be another case of the content-type header being already captured.

The main questions that need figured out before a PR:

1. What should it be called? (request|response)_content_type or (request|response)_media_type
2. Should it also contain charset and/or boundary directives? Or should those be separate nested attributes?
3. Any reason to breakup the type/subtype?

[Oberon00]

Wouldn't it be enough to represent this just as http.(request|response).header.Content-Type? I guess not normalizing the header casing is annoying for that use case 😕

[Oberon00]

If we already have header capturing we should try to fulfill this use case as well. I would prefer not having to define a new semantic convention for every header. But I agree that the current header proposal may be insufficient.

[Blacksmoke16]

@Oberon00 My thought with that is if you're searching for that value wouldn't that treat application/json and application/json; charset=UTF-8 as separate values?

[Oberon00]

That is true. But I don't think instrumentations should start parsing HTTP header values. This should rather be done on the backend. I wonder if OpenTelemetry should define semantic conventions for such a use case nonetheless

[Blacksmoke16]

@Oberon00 That's fair. Some backends have the ability to create derived columns which could be a good way to handle it. I.e. regex match out the charset and stuff from the singular http.headers.content-type header.

This is also similar to #640 as the majority of that usecase could also be solved via http.headers.content-length, at least the size used for that value. I.e. might not be able to differentiate from uncompressed size versus compressed size.

[Blacksmoke16]

Probably good to close this with the introduction of #1898. Feel free to re-open if you disagree.