Using Server-timing to carry TraceID

[plehegar]

From https://docs.google.com/document/d/1Gr9QD6kt3_DcxRJSFpuoqWWMAJMRqCGd1kPcroNUyh8/edit#heading=h.9512imm5np07

The Distributed Tracing folks are looking into carrying trace information in response headers (right now, it's limited to requests only). One idea would be to have special name/value pair for TraceID with the Server-timing pairs?

cc @mtwo @SergeyKanzhelev @danielkhan

[yoavweiss]

Why does it have to be special?

[SergeyKanzhelev]

@yoavweiss I think there are two questions in one:

1. are there existing plans for Server-Timing to carry server side request identification? Do you hear this request often?
2. will it be seen as a Server-Timing header abuse to define name/value pair? (be it part of this specification or another)

[yoavweiss]

Apologies for the extremely late reply... :/

1. are there existing plans for Server-Timing to carry server side request identification? Do you hear this request often?

I can't say that this is a request we heard often. Might be worthwhile to run some analysis on usage in the wild and see if it's something many folks do.

2. will it be seen as a Server-Timing header abuse to define name/value pair? (be it part of this specification or another)

Not sure what you mean? Are you saying you want to define a specific name and value as part of another specification? Can you provide some more concrete example?

[SilentImp]

The common way to use it at the moment: https://opentracing.io/ It would be nice to actually have a clear way/guide how to use it in a way that as good as opentracing are.

[yoavweiss]

I think it's fine for opentracing or other libraries to build on top of server timing. The part that's unclear to me is if server timing needs to somehow change in order to better support that.

[plehegar]

I don't think that the server timing spec would need to change necessarily. However, It will have to be extended beyond just a pair/value definition however.

server timing only carry a metric duration with a description at the moment. trace information aren't double however since they aren't about timing.

So I can imagine something like:

[Exposed=(Window,Worker)]
partial interface PerformanceServerTiming {
  readonly attribute DOMString response;
  readonly attribute DOMString parent;
  readonly attribute DOMString id;
};

For those entries, the name attribute would return 'trace' and the duration value would return 0.

[plehegar]

as a side, the current proposal is leaning towards defining separate http headers at the moment. See https://github.com/w3c/trace-context/pull/365

[yoavweiss]

This was discussed on a past call.

Essentially, Server Timing can use the description to carry trace information today. I don't see browsers doing something in particular with that trace information, and certainly don't see them propagating that info to cross-origin servers.

As such, I don't think this is actionable. Closing. (but feel free to re-open if you disagree)