Skip to content
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

Overhaul how standards integrate with fetch #1165

Merged
merged 5 commits into from Feb 12, 2021
Merged

Conversation

annevk
Copy link
Member

@annevk annevk commented Feb 9, 2021

This makes some rather big changes:

  • Requests no longer have a synchronous flag. Blocking a thread is now up to the caller.
  • Fetch therefore no longer returns a response directly. In parallel callers will need to pass in "callbacks" that are either invoked on a parallel queue or on an event loop.
  • To hold onto these callbacks as well as some other information a fetch params struct is now passed around the various fetch algorithms. This will allow for cleanup around termination and aborting in the future. Potentially some bookkeeping state from request can move there going forward.
  • There's a dedicated navigate-redirect fetch algorithm for HTML as the HTTP-redirect fetch algorithm now wants a fetch params instance.
  • Some allowance for aborting early on in fetch was removed as all that is run synchronously with the code that invoked fetch to begin with. Closes "Return a network error" doesn't seem to go through "process response" #1164.
  • Algorithms that needed to be adjusted were changed to use the new Infra patterns for parameters. I also tried to improve naming, e.g., makeCORSPreflight rather than CORS-preflight flag.

Fixes #536.


Preview | Diff

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good! I'd like to work on a PR for HTML to use these in the fetching scripts section to see what that looks like, although I don't want to block too long. I'll check out the XHR PR as well...

Requests no longer have a synchronous flag. Blocking a thread is now up to the caller.

This seems kind of inconvenient. What does it buy us? What would it look like? I guess I should go check out the XHR PR... Maybe you could work on a PR to HTML to update some of the synchronous fetches, to see what it looks like there?

fetch.bs Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
</ol>
<li><p>If <var>request</var>'s <a for=request>client</a> is non-null, then set <var>global</var> to
<var>request</var>'s <a for=request>client</a>'s
<a for="environment settings object">global object</a>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we assert now that either global or algorithmQueue is non-null?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, for sync XHR both will have a value, for instance. And most things will need a non-null client (figuring out client more precisely is a separate can of worms).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant, assert that at least one of them is non-null.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would not allow fire-and-forget (e.g., pings or reports).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, those would have a body prolly and would need to use useParallelQueue as otherwise transmit-request-body loop breaks. I'll add this.

Copy link
Member Author

@annevk annevk Feb 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but elsewhere we have callers that don't set this. They do go directly to main fetch but still... I'm going to add this as a comment as something to evaluate over time once we've upgraded more callers.

fetch.bs Outdated Show resolved Hide resolved
This makes some rather big changes:

* Requests no longer have a synchronous flag. Blocking a thread is now up to the caller.
* Fetch therefore no longer returns a response directly. In parallel callers will need to pass in "callbacks" that are either invoked on a parallel queue or on an event loop.
* To hold onto these callbacks as well as some other information a fetch params struct is now passed around the various fetch algorithms. This will allow for cleanup around termination and aborting in the future. Potentially some bookkeeping state from request can move there going forward.
* There's a dedicated navigate-redirect fetch algorithm for HTML as the HTTP-redirect fetch algorithm now wants a fetch params instance.
* Some allowance for aborting early on in fetch was removed as all that is run synchronously with the code that invoked fetch to begin with. Closes #1164.
* Algorithms that needed to be adjusted were changed to use the new Infra patterns for parameters. I also tried to improve naming, e.g., makeCORSPreflight rather than CORS-preflight flag.
* "process response done" was removed as it seemed redundant with "response response end-of-body"; possible leftover from trailers.
* Removed duplicate task queueing at the end of main fetch for request's body.

Fixes #536.
@sideshowbarker
Copy link
Contributor

Do you know yet how much impact these changes will have on non-WHATWG specs that call into Fetch algorithms?

I’m wondering in particular about WebAppSec specs.

Regardless, I’m happy to help as needed both on assessing what other specs will be affected, and then also working on getting other specs updated as needed to align with these changes.

@annevk
Copy link
Member Author

annevk commented Feb 12, 2021

It affects everything that uses Fetch to fetch something. Based on https://fetch.spec.whatwg.org/#concept-request-destination I'd say most of that is HTML, but there is probably some reporting in WebAppSec that would need updating. It should all be fairly minor and I'm happy to help.

@annevk annevk merged commit 12dd6fa into main Feb 12, 2021
@annevk annevk deleted the annevk/formalize-callbacks branch February 12, 2021 11:01
annevk added a commit to whatwg/xhr that referenced this pull request Feb 12, 2021
annevk added a commit to whatwg/xhr that referenced this pull request Feb 15, 2021
jyasskin added a commit to jyasskin/webpackage that referenced this pull request Feb 24, 2021
horo-t pushed a commit to WICG/webpackage that referenced this pull request Feb 25, 2021
Bishwarupjee pushed a commit to Bishwarupjee/xhr that referenced this pull request Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

"Return a network error" doesn't seem to go through "process response" Odd format for fetch callbacks
3 participants