8000 WorkerGlobal scope's URL accessed for fetch blob partitioning before being set · Issue #11340 · whatwg/html · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
WorkerGlobal scope's URL accessed for fetch blob partitioning before being set #11340
Open
@shannonbooth

Description

@shannonbooth

What is the issue with the HTML Standard?

While fixing a bug in ladybird to correctly return an opaque origin for data URLs in workers, I came across a very minor ordering issue for worker global scope's URL for blob workers.

The environment settings object uses global scope's URL to to return an origin to check if global scope's URL is a data URL for that opaque origin case:

The origin
Return a unique opaque origin if worker global scope's url's scheme is "data", and inherited origin otherwise.

However, that origin getter and worker global scope URL is accessed early on in the fetch for blob URLs for blob partitioning. But worker global scope's URL is not set by that stage since that is done while processing fetch body in: https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model.

Considering that check is only really needed for that data URL case and redirects isn't really an issue, I just ended up also setting worker global scope's URL before making the fetch in addition to the process body case. As always, happy to contribute a patch, but trying to figure out if there is a better spec mechanism fetch hook to get the ordering of setting the URL right.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0