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.

Sign up for GitHub

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

Jump to bottom

Resolve a relative URL in resources on a bundle's URL, instead of doc… #700

Merged
merged 2 commits into from Oct 27, 2021
Merged

Resolve a relative URL in resources on a bundle's URL, instead of doc… #700

merged 2 commits into from Oct 27, 2021

Conversation

hayatoito
Copy link
Collaborator

…ument's base URL

The discussion is:
#699 (comment)

@hayatoito hayatoito requested a review from irori October 27, 2021 02:39
@irori
Copy link
Collaborator

irori commented Oct 27, 2021

What about scopes?

I'm confused whether scopes is valid or not in current proposal. In the TOC of this explainer, "Defining the scope" is under the "Alternate designs" section, but Defining the scopes is under the Content Security Policy (CSP) section.

@hayatoito
Copy link
Collaborator Author

What` about scopes?

scopes should obey the same rule, resolving a relative URL on the bundle's URL.

It seems the current explainer has a structural issue.. Let's fix that later in another PR.

irori
irori reviewed Oct 27, 2021
View reviewed changes
Copy link
Collaborator

@irori irori left a comment

Choose a reason for hiding this comment

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

Then let's mention about scopes.

explainers/subresource-loading.md Outdated Show resolved Hide resolved
@hayatoito @irori
Update explainers/subresource-loading.md
eb7f761 
Co-authored-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
@hayatoito
Copy link
Collaborator Author

I've committed a suggestion. Thanks.
We should fix a structural issue in the explainer anyway later.

irori
irori approved these changes Oct 27, 2021
View reviewed changes
Copy link
Collaborator

@irori irori left a comment

Choose a reason for hiding this comment

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

lgtm

@hayatoito hayatoito merged commit ad9865d into WICG:main Oct 27, 2021
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 27, 2021
@hayatoito @chromium-wpt-export-bot
<script type=webbundle>: Resolve a relative URL on the bundle's URL
c58bb87 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
@chromium-wpt-export-bot chromium-wpt-export-bot mentioned this pull request Oct 27, 2021
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 27, 2021
@hayatoito @chromium-wpt-export-bot
<script type=webbundle>: Resolve a relative URL on the bundle's URL
5abdeae 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 27, 2021
@hayatoito @chromium-wpt-export-bot
<script type=webbundle>: Resolve a relative URL on the bundle's URL
8fa669c 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
FrankEnderman pushed a commit to FrankEnderman/cursemium that referenced this pull request Oct 27, 2021
@hayatoito
<script type=webbundle>: Resolve a relative URL on the bundle's URL
f06d042 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935333}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 27, 2021
@hayatoito @chromium-wpt-export-bot
<script type=webbundle>: Resolve a relative URL on the bundle's URL
9304433 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935333}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 27, 2021
@hayatoito @chromium-wpt-export-bot
<script type=webbundle>: Resolve a relative URL on the bundle's URL
6bbec86 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935333}
@hayatoito hayatoito mentioned this pull request Oct 28, 2021
Closed
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Oct 29, 2021
@hayatoito @moz-wptsync-bot
Bug 1737958 [wpt PR 31395] - <script type=webbundle>: Resolve a relat…
4be9500 
…ive URL on the bundle's URL, a=testonly

Automatic update from web-platform-tests
<script type=webbundle>: Resolve a relative URL on the bundle's URL

The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935333}

--

wpt-commits: 6bbec86c72b31033d100beb6c571c37f1cdc5446
wpt-pr: 31395
jamienicol pushed a commit to jamienicol/gecko that referenced this pull request Nov 1, 2021
@hayatoito @moz-wptsync-bot
Bug 1737958 [wpt PR 31395] - <script type=webbundle>: Resolve a relat…
f331b32 
…ive URL on the bundle's URL, a=testonly

Automatic update from web-platform-tests
<script type=webbundle>: Resolve a relative URL on the bundle's URL

The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935333}

--

wpt-commits: 6bbec86c72b31033d100beb6c571c37f1cdc5446
wpt-pr: 31395
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this pull request Nov 18, 2021
@hayatoito @Gabisampaio
<script type=webbundle>: Resolve a relative URL on the bundle's URL
ea6e807 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935333}
@hayatoito hayatoito deleted the relative-url-on-bundle branch March 7, 2022 08:55
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this pull request Oct 14, 2022
@hayatoito
<script type=webbundle>: Resolve a relative URL on the bundle's URL
14d67c4 
The explainer PR is: WICG/webpackage#700

One of the gaps between the Subresource Loading with WebBundles and
Bundle Preloading proposals is "how to resolve a relative URL of
resources". The former is using document's base URL, and the latter is
using the bundle's URL. We have to align.

At the era of <link>-based API, using a document's base URL might make
sense because `resources` are specified in the link element's
attribute.

Now we use <script>-based APIs, and `resources` is specified in JSON, so
we no longer have any strong reason to use a document's base URL.

See the spec discussion for details:
WICG/webpackage#699 (comment)

Bug: 1263807
Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935333}
NOKEYCHECK=True
GitOrigin-RevId: f06d042b5412ac6654e62c62a602468fa3646ecc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@irori irori irori approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@hayatoito @irori