Add server-timing to timing info struct

[noamr]

Will be used by w3c/server-timing#87

Decode and split Server-Timing headers, and append the raw headers to the fetch timing info. The server timing spec would later parse these headers and expose them.

• At least two implementers are interested (and none opposed):

  • Already implemented

• Tests are written and can be reviewed and commented upon at:

  • Rigorously tested in https://github.com/web-platform-tests/wpt/tree/master/server-timing

• Implementation bugs are filed:

  • N/a

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

Why can't the calling specification look at the response itself?

Also, I thought these headers might appear as trailer headers?

[noamr]

Why can't the calling specification look at the response itself?

We didn't want to pass the whole response to resource timing. We're passing only the timing info.

Also, I thought these headers might appear as trailer headers?

They can, but I wanted to do this in iterations. Also they're not a widely adopted feature and I wanted to spec the consensus common denominator first.

[annevk]

So dealing with them in trailer headers doesn't have implementer agreement? It seems a little weird for Fetch to process this header as it doesn't seem to be related to information hiding, but if this is the only thing Resource Timing needs I guess it makes sense. Perhaps we should add some comments though that in case this changes we need to change the setup.

[noamr]

So dealing with them in trailer headers doesn't have implementer agreement? It seems a little weird for Fetch to process this header as it doesn't seem to be related to information hiding, but if this is the only thing Resource Timing needs I guess it makes sense. Perhaps we should add some comments though that in case this changes we need to change the setup.

Added a comment, is that sufficient? Not sure if any more clarification is needed at this point.

[annevk]

"So dealing with them in trailer headers doesn't have implementer agreement?" is something I'd still like an answer to. The note also doesn't tackle this adequately I think as trailers can be received at a much later point so you probably want a separate data structure for them.

I also didn't really mean to ask for note, but rather a comment that indicates we might want to change approach if we end up having to inspect and parse other headers for Resource Timing. At that point it might become better to just pass Resource Timing the header list.

[noamr]

"So dealing with them in trailer headers doesn't have implementer agreement?" is something I'd still like an answer to. The note also doesn't tackle this adequately I think as trailers can be received at a much later point so you probably want a separate data structure for them.

I don't think that would be necessary. Resource timing is only reported after response end, at which point those would be available. But in any case, I would defer this to when there's consensus about trailers.

I also didn't really mean to ask for note, but rather a comment that indicates we might want to change approach if we end up having to inspect and parse other headers for Resource Timing. At that point it might become better to just pass Resource Timing the header list.

Got it.

[noamr]

See #980, #981 and w3c/server-timing#68 for conversation about trailer suopport.

[noamr]

@annevk anything missing in this?

[annevk]

I'd like @ddragana or @valenting to comment as well given that Firefox does support trailers here if I'm not mistaken, but this looks okay to me. I pushed some minor commits that I hope are acceptable.

I'm not entirely sure about the approach to processing this header being shared across two specifications, but I also cannot really think of a better way of doing it.

[noamr]

I'd like @ddragana or @valenting to comment as well given that Firefox does support trailers here if I'm not mistaken, but this looks okay to me. I pushed some minor commits that I hope are acceptable.

Thanks, of course they are.

I'm not entirely sure about the approach to processing this header being shared across two specifications, but I also cannot really think of a better way of doing it.

I agree it's not ideal but it's also how it looks like in implementations, I believe it's the the lesser of evils.

[annevk]

The other thing I realized looking at Firefox's implementation a bit more is that it limits this feature to secure contexts. That's probably something we want to account for here and not on the API side.

[noamr]

The other thing I realized looking at Firefox's implementation a bit more is that it limits this feature to secure contexts. That's probably something we want to account for here and not on the API side.

Done, and added a WPT. Chromium implementation, however, currently allows Server-Timing in http. (Safari doesn't support Server-Timing at all).
@yoavweiss WDYT about limiting ST to HTTPS?

[yoavweiss]

I believe that would be a breaking change from Chromium's perspective. Is there any particular reason why Server-Timing should be limited to secure contexts? Any security/privacy issues that arise from the fact that it is not?
Also, what are the benefits of enforcing this limitation on the Fetch side?

[valenting]

Looking back at the intent to ship I think the main motivation for limiting this to secure origins was Mozilla's policy of doing so.

I also seem to recall a discussion where trailers were causing problems with middleboxes over HTTP, but I can't find any references to that at this time.

[noamr]

Looking back at the intent to ship I think the main motivation for limiting this to secure origins was Mozilla's policy of doing so.

I also seem to recall a discussion where trailers were causing problems with middleboxes over HTTP, but I can't find any references to that at this time.

Seems like the conversation didn't result in a consensus, which is unfortunate since currently server-timing is not interoperable in that way.

[annevk]

Also, what are the benefits of enforcing this limitation on the Fetch side?

Mainly principle of least privilege.

[yoavweiss]

Also, what are the benefits of enforcing this limitation on the Fetch side?

Mainly principle of least privilege.

OK. At the same time, that doesn't seem in line with what some implementations are doing.

[noamr]

I amended the PR to reflect the Gecko/Chromium status quo: the headers are always sent for https, and make http something that's up to the user-agent's discretion. It's not perfect in terms of interoperability but at least it makes the part that are in consensus specified.

[noamr]

@annevk anything missing?

[annevk]

@yoavweiss want to have another look?

[yoavweiss]

LGTM