Add interim response times

[noamr]

Add firstInterimResponseStart: the first response with an informational (1XX) status.

Bug: #345 Depends on whatwg/fetch#1483

For now not adding headers-end and body-start as they're not planned to be implemented.

---

Preview | Diff

[yoavweiss]

Seems reasonable once the Fetch bits land.

[annevk]

Why only the first 103? What about a 109?

[annevk]

Also, should we call this "interim" or "informational"? Is there any precedent in the web platform?

[noamr]

Why only the first 103? What about a 109?

Because it's the only informational/interim header processed by the web platform.

[noamr]

Also, should we call this "interim" or "informational"? Is there any precedent in the web platform?

That was the proposal on the issue and it seemed ok at the time. I don't really mind renaming it to informational. @tunetheweb @yoavweiss any objections?

[annevk]

Because it's the only informational/interim header processed by the web platform.

Well, we handle all of them. We have some special code for 101 and 103, but it's not like we bail out when we see a 102. (Also the current Fetch PR is not restricted to a 103.)

[tunetheweb]

@LPardue from the IETF HTTP WG had some strong opinions on "informational":

I disagree with calling things informational responses. RFC 9110 doeant use that term, instead it defines interim responses, which use informational status codes. Terminology needs to be precise and consistent unless there is a good reason to diverge.

[noamr]

@LPardue from the IETF HTTP WG had some strong opinions on "informational":

I disagree with calling things informational responses. RFC 9110 doeant use that term, instead it defines interim responses, which use informational status codes. Terminology needs to be precise and consistent unless there is a good reason to diverge.

Right, RFC9110 does use the term "interim". @annevk does that satisfy "precedent in the web platform"?

[annevk]

It certainly does, thanks for digging that up.

[noamr]

Because it's the only informational/interim header processed by the web platform.

Well, we handle all of them. We have some special code for 101 and 103, but it's not like we bail out when we see a 102. (Also the current Fetch PR is not restricted to a 103.)

By handle I mean actually do something meaningful with them. Perhaps this could be named firstEarlyHintResponse and be specific to the first 103?

[tunetheweb]

@LPardue had some strong views on that too :-)

Please don't prefix anything with early. If we want to support interim HTTP responses, call it that. Expect the HTTP to define more 1xx codes, because its been a part of HTTP since forever.

If we only want to record the time of the first interim response, that fine. But let's be clear. What these events measure. Maybe today first and last interim response are measured at the same time due to fetch. In the future, if fetch changes to support multiple interim responses, our first and last markers would be ready.

[annevk]

Right, but that means we should measure the first 1xx (if any), not the first 103. Which I tend to agree with.

[noamr]

@LPardue had some strong views on that too :-)

Please don't prefix anything with early. If we want to support interim HTTP responses, call it that. Expect the HTTP to define more 1xx codes, because its been a part of HTTP since forever. If we only want to record the time of the first interim response, that fine. But let's be clear. What these events measure. Maybe today first and last interim response are measured at the same time due to fetch. In the future, if fetch changes to support multiple interim responses, our first and last markers would be ready.

"Early" here is for "Early hints" which is the term used in RFC8297. I think it's a misunderstanding of the context of early in this name. @LPardue I'm a bit confused why this is wrong. We're amending fetch to mark the timing when we got the first 103 Early Hints response.

[tunetheweb]

I think @LPardue (and @annevk ?)'s point is that it shouldn't be limited to 103 (even if it is for now) in case we want to use it for any other 1XX responses in future.

[noamr]

I think @LPardue (and @annevk ?)'s point is that it shouldn't be limited to 103 (even if it is for now) in case we want to use it for any other 1XX responses in future.

OK with me. So in conclusion I'll change the description & spec & implementation to also include 100, and we'll keep the firstInterimResponseTime name?

[noamr]

I think @LPardue (and @annevk ?)'s point is that it shouldn't be limited to 103 (even if it is for now) in case we want to use it for any other 1XX responses in future.

OK with me. So in conclusion I'll change the description & spec & implementation to also include 100, and we'll keep the firstInterimResponseTime name?

Done. Also removed the two unimplemented timings.

[annevk]

It seems fine to expose less, but https://github.com/w3c/resource-timing/issues/345#issuecomment-1259852569 did have use cases for the others so that should still be tracked in some way I suppose?

Does this change also impact the request over at https://github.com/WebKit/standards-positions/issues/109?

[noamr]

It seems fine to expose less, but #345 (comment) did have use cases for the others so that should still be tracked in some way I suppose?

There is a use case for the others but decided to implement them gradually. Currently only firstInterimResponseStart is implemented. I can add all of them to the spec but I thought this would be a bit fictional. Perhaps we can leave the issue open for the other ones.

Does this change also impact the request over at WebKit/standards-positions#109?

The standard position should consider that firstInterimResponseStart is the part of it that's currently implemented and the rest are in backlog for Chromium.