Rename http.route to http.request.route?

[trask]

After #374, http.route will be the only http.* attribute that is not under either http.request.* or http.response.*.

I think I'm in favor of keeping http.route as-is, but wanted to open this to give others a chance to weigh in if they feel differently.

[cartermp]

I would agree with not changing it. In particular we have customers who rely on checking http.route contents via something like a Contains operator, and this is the basis for things like SLOs, Alerts, etc. with no obvious way to migrate when it's split in two. The other changes (that customers are affected by, at least) are 1:1 translations that are easier to perform on our backend.

[cartermp]

Ah, right, sorry, I got confused and was thinking of http.target, which is being split. E_TOO_MANY_HTTP_SEMANTIC_CONVENTIONS.

I'm...ambivalent I guess, since whatever process we have to convert on the backend can work for http.route if it changes to a single attribute. But the less change, the better?

[Oberon00]

(Aside: It is unclear what the upvotes on the issue mean. "Yes" to the question in the issue title whether we should rename, or "Agree" to the sentence in the description that we should rather keep the name as-is)

[joaopgrassi]

I'm also in favor of not changing and keep it as-is.

[JamesNK]

Keep it as http.route. The route isn't information on the request. It is calculated on the server.

[joaopgrassi]

I guess we have a majority on keeping it as http.route? Do you think we can close this @trask? Or you want to bring it up in the meeting before?

[trask]

The route isn't information on the request. It is calculated on the server.

closing, this is a great reason to keep it where it is, thx @JamesNK