Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protocol negotiation and ambiguity of network.protocol.version #686

Closed
lmolkova opened this issue Feb 2, 2024 · 6 comments · Fixed by #817
Closed

Protocol negotiation and ambiguity of network.protocol.version #686

lmolkova opened this issue Feb 2, 2024 · 6 comments · Fixed by #817
Assignees

Comments

@lmolkova
Copy link
Contributor

lmolkova commented Feb 2, 2024

Related to dotnet/docs#39223 (comment) and dotnet/runtime#97395 (comment)

During network protocol negotiation there are two protocol versions:

  • one that client requested originally
  • one that was agreed upon during negotiation

If response was received at all, then it makes total sense to set network.protocol.version to the final version.
If response was not received, we can set the network.protocol.version to the request version (which might be misleading or not useful since it's at least sometimes per-client configuration)

So we:

  • need to update network.protocol.version description to clarify that it's the negotiated version
  • need to decide if we want to fallback to request/initial version if no response was received
@trask
Copy link
Member

trask commented Feb 2, 2024

since it's at least sometimes per-client configuration

I didn't follow this part, can you explain a bit more?

@lmolkova
Copy link
Contributor Author

lmolkova commented Feb 2, 2024

I didn't follow this part, can you explain a bit more?

On the request side, protocol is frequently a client property:

It's interesting that okhttp and netty allow to pass an array of supported protocols reiterating the point that request protocol version is somewhat useless.

The only benefit of falling back to request protocol version I see is when the client sends bad protocol version and/or server fails to respond to it. Then having requested version would be interesting.

@joaopgrassi
Copy link
Member

joaopgrassi commented Feb 29, 2024

The only benefit of falling back to request protocol version I see is when the client sends bad protocol version and/or server fails to respond to it. Then having requested version would be interesting.

Wouldn't the HTTP client log a message/exception, maybe containing the requested protocol version? I feel this is more a job of a log than recording this info in a span or somewhere else 🤔

@trask
Copy link
Member

trask commented Feb 29, 2024

It definitely simplifies things if we simply clarify that network.protocol.version is the negotiated version

@joaopgrassi
Copy link
Member

Who will do the honors with a PR? ✨

@lmolkova
Copy link
Contributor Author

lmolkova commented Mar 13, 2024

Adding it here so we don't forget

When addressing #520 we this text needs to be manually updated in dotnet-http-metrics.md.

#801 (comment)

I can do the PR after #801 is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants