Should `http.scheme` be renamed to `uri.scheme`?

[reyang]

trafficstars

Strictly speaking scheme is not an HTTP concept.

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

[Oberon00]

This would be the kind of the opposite direction of #2056, wouldn't it? I could imagine renaming to http.url_scheme (or http.uri_scheme) but I don't think there is a real problem with the current name that warrants the disruption caused by renaming (even though it is eased by the convention schema mechanism).

[reyang]

FYI this is the ECS approach: https://www.elastic.co/guide/en/ecs/current/ecs-http.html#ecs-http

Use the url field set to store the url of the request.

[trask]

if we rename http.scheme to url.scheme, would we also rename http.url to url.full?

and (maybe) rename http.target to url.target, or (aligning with ECS) split http.target into url.path + url.query + url.fragment?

[trask]

cc @AlexanderWert

[reyang]

I think this is where we should borrow/learn from ECS, and maybe @AlexanderWert can help us a lot.

I will give an example which shows how we end up with if we call it http.url:

1. A vendor is building an anti-virus software which records all the outgoing networking access, and for L7 actions, the software supports both FTP and HTTP.
2. The vendor would want to have a table which looks like:

   | timestamp | user   | url.full              | blocked |
   | --------- | ------ | --------------------- | ------- |
   | T1        | reiley | http://wikipedia.org/ | no      |
   | T2        | reiley | http://microsoft.com/ | no      |
   | T3        | reiley | ftp://bad/malware     | yes     |
   

3. If we ask folks to use http.url and ftp.url, they will either end up with a sparse table that is hard to use, or they have to put things to different tables, or they will push for a new major version of semantic convention.

[trask]

http.client_ip -> net.client_ip or net.forwarded_ip similar to ECS network.forwarded_ip?

[AlexanderWert]

To provide some input from the ECS perspective to this:

Being more explicit about all the URL-related aspects and group them under a common namespace would allow to address the examples mentioned here and would also address https://github.com/open-telemetry/opentelemetry-specification/issues/2056

So basically:

• http.url -> url.original (+ optional and where applicable: url.full, url.scheme, url.domain, url.port, url.path, url.query, etc. )
• http.scheme -> url.scheme
• http.target -> url.original (+ optional and where applicable: url.path, url.query) -> addresses https://github.com/open-telemetry/opentelemetry-specification/issues/2056

Also, is it necessary to have different attributes for http.url (on CLIENT spans) and http.target (on SERVER spans)? Both are representing (parts of a) URL and with the SpanKind the semantics (client request URL vs server request target) of it is also clearly defined. So, why not using a common attribute (or a set of attributes) for it?

[trask]

let's move this conversation over to #3163 if no objections

[trask]

@reyang ok to close this in favor of the #3163?