What to do with non well-known http.method values?

[trask]

http.method is a required field in both traces and metrics, but it's not clear what instrumentation should do with non well-known values, e.g. if someone sends a request with http method XYZ, should instrumentation preserve that value? or normalize it to something like OTHER?

on the tracing side it seems to make sense to preserve the XYZ value, but on the metrics side this could leave you open to cardinality problems, so it seems to make sense to normalize it to OTHER on the metrics side.

but having different values captured for traces and metrics seems bad, so I think it makes sense to normalize it to OTHER for both.

[Oberon00]

I don't think there are "invalid" HTTP method values. Using custom HTTP verbs seems unusual but valid. Special considerations may apply to span names (and maybe metric attributes?) but otherwise I see no reason to scrub non-well-known values.

https://www.rfc-editor.org/rfc/rfc9110.html#section-9.1-5:

The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive method names. By convention, standardized methods are defined in all-uppercase US-ASCII letters.

https://www.rfc-editor.org/rfc/rfc9110.html#section-9.1-11:

Additional methods, outside the scope of this specification, have been specified for use in HTTP. All such methods ought to be registered within the "Hypertext Transfer Protocol (HTTP) Method Registry", as described in Section 16.1.

[trask]

I don't think there are "invalid" HTTP method values

good point, thx, I've updated the title and description

Special considerations may apply to span names (and maybe metric attributes?) but otherwise I see no reason to scrub non-well-known values.

I think it's a bit awkward to have different definition of http.method for traces and metrics, so I guess my preference would be to only capture well-known values by default and scrub others to OTHER. And instrumentation could offer an option to expand the list of "well-known values" if needed.

[Oberon00]

I'm torn on this. I think the safe option is to add the on-by-default optional special case for non-well-known verbs. But it comes with some information loss especially in "interesting" cases and also you'll have to add the list of verbs.

Also we might break certain cases we don't know of. And I am not sure a "on/off" switch is good enough here, because if you need the normalization to be protected from flooding, this is independent from whether you use custom verbs or not. So you'd rather have a configurable list of accepted verbs.

Maybe this is better scrubbed/normalized on the collector?

If still possible, we may want to remove the assumption that http.method is low-cardinality. E.g. remove it from the span name suggestions and whatever is required in the metrics.

[trask]

@open-telemetry/technical-committee can you post the results of the vote here? thx!

[reyang]

@open-telemetry/technical-committee met and voted last Wednesday (Jun. 14th, 2023) and here are the results:

• Go with the Option A direction Limit HTTP request method cardinality: original_method (option A) semantic-conventions#17 - 5 votes
• Acknowledge the problem but do nothing at this point, move on the stabilize HTTP semconv as-is - 4 votes

Please close other options and push Option A through the finishing line.

[reyang]

I think this is resolved by open-telemetry/semantic-conventions#17.