gvfs-helper: emit X-Session-Id headers for requests#862
gvfs-helper: emit X-Session-Id headers for requests#862derrickstolee wants to merge 2 commits intomicrosoft:vfs-2.53.0from
Conversation
| } else { | ||
| /* No gvfs.sessionkey configured, use just SID */ | ||
| strbuf_addf(&header, "X-Session-Id: %s", sid); | ||
| } |
There was a problem hiding this comment.
Add some client-identifying data to the HTTP queries using the X-Session-Id header. This will by default identify the helper process using its SID. If configured via the new gvfs.sessionKey config, it will prefix this SID with another config value.
Can we split up this commit into two parts, one being the 'always add the SID to the request' and then the other being 'add a common/static prefix'?
I don't have any complaints about including the X-Session-Id: <SID> part. I'm not sure how I feel about the extra redirection for specifying a SID-prefix.
So I understand, the idea is that the gvfs.sessionkey will point to the other Git config key, who's value is the prefix?
X-Session-ID: < config( config(gvfs.sessionkey) ) : <SID> >
Is there an objection to just having one config option gvfs.sidprefix / sessionidprefix / sessionprefix / whatever 🚲 that is the SID prefix?
There was a problem hiding this comment.
My motivation is that we set an otel.trace2.id config value when creating a new repo, and this is an important config value for the trace2 collector. I'd prefer to use this value directly without creating a duplicate config value with the same value. Thus, saying "what config key should Git use to get a config value to prefix the SID?" avoids the potential duplication of values.
I do like the value of splitting into two commits.
In order to assist with tracking user experience between the Git client and the GVFS Protocol servers, start sending the SID for the client Git process over the wire as the X-Session-Id header. Insert this header to all curl requests for each protocol. Signed-off-by: Derrick Stolee <stolee@gmail.com>
In different engineering systems, there may already be pseudonymous identifiers stored in the local Git config. For Office and 1JS, this is present in the 'otel.trace2.id' config value. We'd like to be able to collect server-side telemetry based on these pseudonymous identifiers, so prefxing the X-Session-Id header with this value is helpful. We could create a single 'gvfs.sessionPrefix' config key that stores this value, but then we'd need to duplicate the identifier and risk drift in the value. For now, we create this indirection by saying "what config _key_ should Git use to look up the value to add as a prefix?" Signed-off-by: Derrick Stolee <stolee@gmail.com>
derrickstolee
force-pushed
the
session-id
branch
from
d93d2d1 to
f78ee34
Compare
2 participants
A common problem when tracking GVFS Protocol queries is that we don't have a way to connect client and server interactions. This is especially true in the typical case where a cache server deployment is hidden behind a load balancer. We can't even determine which cache server was used for certain requests!
Add some client-identifying data to the HTTP queries using the X-Session-Id header. This will by default identify the helper process using its SID. If configured via the new gvfs.sessionKey config, it will prefix this SID with another config value.
For example, Office monorepo users have an 'otel.trace2.id' config value that is a pseudonymous identifier. This allows telemetry readers to group requests by enlistment without knowing the user's identity at all. Users could opt-in to provide this identifier for investigations around their long-term performance or issues. This change makes it possible to extend this to cache server interactions.
GVFS Protocol.