-
Notifications
You must be signed in to change notification settings - Fork 342
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
Return a "controller" instance from fetch #1329
Conversation
@annevk i think this is ready for another review, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This good, thanks for working on this! I suggest we wait a bit with landing this until @jakearchibald is back home (next week iirc) as he worked on this last and might have some relevant insights.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
\o/ looks even better. I'll file a follow-up on where we should define fetch params and such.
This PR should also update the "Invoking fetch" section with a few words about the return value of fetch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few nits really.
@@ -2247,14 +2278,14 @@ functionality. | |||
|
|||
<p>A <a for="fetch group">fetch record</a> has an associated | |||
<dfn export for="fetch record" id=concept-fetch-record-fetch>fetch</dfn> (a | |||
<a for=/>fetch</a> algorithm or null). | |||
<a for=/>fetch controller</a> or null). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see any cases where it's null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we tackle this in a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you file an issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed the detailed CR comments.
As noted on Matrix we need to account for service workers and in particular "handle fetch". Either we make it so that "handle fetch" returns a controller for the service worker fetch event, or we pass the controller into "handle fetch" so the service worker can observe it. The former seems a bit nicer as it reuses the pattern introduced here and could be used for other kinds of information exchange in the future. It would require "handle fetch" to take a callback. @yutakahirano @jakearchibald @noamr thoughts? |
I like the idea of returning a controller from SW's fetch rather than having SW query its caller fetch for "is terminated"... |
Yeah, I think we need to tackle it as otherwise fetch termination in service workers ends up in UB territory. |
It is currently in undefined behavior territory, this doesn't change much about it. can't we fix this iteratively? |
In conjunction with whatwg/fetch#1329. When the SW fetch starts, it emits an `onStart` callback with a controller instance. That controller instance can be used to terminate the service worker fetch and it's internal fetches.
In conjunction with whatwg/fetch#1329. When the SW fetch starts, it emits an `onStart` callback with a controller instance. That controller instance can be used to terminate the service worker fetch and it's internal fetches.
See w3c/ServiceWorker#1612 and latest revision of this PR.
(It currently fails to build because of the dependency on the SW patch) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you working on a new service worker PR? I think the Fetch side looks good, though I'd like to do another detailed read once we have the full story. @jakearchibald what do you think?
@annevk I was working on the corresponding SW PR: #1329 and I see that it's closed for some reason, I must have closed it by mistake and I don't seem to be able to re-open. Opened a new one: w3c/ServiceWorker#1620 |
@@ -2247,14 +2278,14 @@ functionality. | |||
|
|||
<p>A <a for="fetch group">fetch record</a> has an associated | |||
<dfn export for="fetch record" id=concept-fetch-record-fetch>fetch</dfn> (a | |||
<a for=/>fetch</a> algorithm or null). | |||
<a for=/>fetch controller</a> or null). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we tackle this in a follow-up.
@jakearchibald @yutakahirano could you please review this PR as well as w3c/ServiceWorker#1620? |
@annevk ping? The corresponding service-workers PR has already been merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a couple minor remaining issues. Also pinging @jakearchibald and @yutakahirano again for review.
@@ -2247,14 +2278,14 @@ functionality. | |||
|
|||
<p>A <a for="fetch group">fetch record</a> has an associated | |||
<dfn export for="fetch record" id=concept-fetch-record-fetch>fetch</dfn> (a | |||
<a for=/>fetch</a> algorithm or null). | |||
<a for=/>fetch controller</a> or null). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you file an issue for this?
Co-authored-by: Anne van Kesteren <[email protected]>
Co-authored-by: Anne van Kesteren <[email protected]>
Co-authored-by: Anne van Kesteren <[email protected]>
@jakearchibald ping? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. One comment, but it can be a followup
|
||
<dl> | ||
<dt><dfn for="fetch controller">state</dfn> (default "<code>ongoing</code>") | ||
<dd>"<code>ongoing</code>", "<code>terminated</code>", or "<code>aborted</code>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be a state that represents a fetch that can no longer be aborted or terminated? I guess that would be "complete".
It seems weird that a fully completed fetch would have a state of "ongoing".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! I will add it when "Finalize and report timing" would move to the fetch controller, otherwise no one would set that value :)
This looks good to me too. One thing we'll need is a tentative commit message that summarizes the changes and links the various follow-up issues, the resolved issues, and the related service worker PR. Is that something you can put together @noamr? In a new comment would be best. |
Sure, I will post follow up issues and comment with a commit message. |
Commit message:Return a "controller" instance from the fetch algorithm, which allows clients of fetch to perform certain actions on an ongoing fetch, initially to abort or terminate it, and later on to conclude it. This will eventually remove the need of using Followup action items: |
Use the controller for external timing reporting and aborts.
This allows removing the 1:1 dependency between timing info and a response, as a response can be shared across fetch
instances (e.g. when restoring a response from cache, or when forwarding a response through a service worker).
See #1208
At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff