-
Notifications
You must be signed in to change notification settings - Fork 373
Bypass blob URL partitioning for top-level self fetches #1879
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
base: main
Are you sure you want to change the base?
Conversation
Implements the fetch spec sid of bypassing partitioning when a top-level blob URL document attempts to fetch itself. For more info see: w3c/FileAPI#210
fetch.bs
Outdated
| <ul class=brief> | ||
| <li><p><var>global</var> is a {{Window}} object; | ||
|
|
||
| <li><p><var>global</var>'s <a for=Window>navigable</a> is not 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 wonder if there are cases where this would be null and you can get this far into a fetch. Hmm.
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.
Specifically where client is non-null but not associated with a Window object? Would worker fetches count here? Maybe even navigation requests themselves, with their reserved client machinery...
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 mirrored this off of the logic in https://fetch.spec.whatwg.org/#populate-request-from-client, but I'm not certain that the cases there are possible here as well...
fetch.bs
Outdated
| <li><p><var>requestEnvironment</var>'s <a for="environment">creation URL</a> | ||
| <a for=url>equals</a> <var>request</var>'s <a for=request>current URL</a>, |
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.
Do we want to ignore fragment identifiers here?
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.
Hmm, what are your thoughts on this?
In Chrome we implemented exact matching because that's how the media fetch breakage we were aiming to work around presented itself (when navigating to a blob URL with a media mime type, the media element src is always exactly the URL you navigated to, fragment included if present)... But for other cases I could see ignoring the fragment identifier be a reasonable thing to do.
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'm okay with keeping it strict.
Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
|
|
||
| <li><p>Let <var>blob</var> be the result of <a>obtaining a blob object</a> given | ||
| <var>blobURLEntry</var> and <var>navigationOrEnvironment</var>. | ||
| <var>blobURLEntry</var> and <var>stringOrEnvironment</var>. |
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 realized that stringOrEnvironment is undefined when request's client is null.
Implements the fetch spec side of bypassing partitioning when a top-level blob URL document attempts to fetch itself. For more info see: w3c/FileAPI#210
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff