-
Notifications
You must be signed in to change notification settings - Fork 162
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
Comments
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. |
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 🤔 |
It definitely simplifies things if we simply clarify that |
Who will do the honors with a PR? ✨ |
Related to dotnet/docs#39223 (comment) and dotnet/runtime#97395 (comment)
During network protocol negotiation there are two protocol versions:
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:
network.protocol.version
description to clarify that it's the negotiated versionThe text was updated successfully, but these errors were encountered: