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

[Spec] Network revocation patches for WebSocket and WebTransport APIs #206

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

blu25
Copy link
Collaborator

@blu25 blu25 commented Jan 10, 2025

This ensures that the following things happen for both WebTransport and WebSocket objects:

  • All open connections associated with a context are closed when untrusted network access is revoked.
  • New connections cannot be created after network access is revoked.

Preview | Diff

@blu25 blu25 requested a review from VergeA January 13, 2025 19:48
@blu25 blu25 marked this pull request as ready for review January 13, 2025 19:48
spec.bs Show resolved Hide resolved
spec.bs Show resolved Hide resolved
@VergeA
Copy link
Collaborator

VergeA commented Jan 14, 2025

LGTM % 1 comment

@blu25 blu25 requested a review from VergeA January 16, 2025 22:06
Copy link
Collaborator

@VergeA VergeA left a comment

Choose a reason for hiding this comment

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

Looks great, thanks!

@blu25 blu25 requested a review from domfarolino January 17, 2025 15:56
@@ -2123,6 +2135,16 @@ Issue: This will require a RFC to add a test-only function to the WPT web driver
1. [=set/Append=] |nonce| to the user agent's [=network revocation nonce set=].

1. [=fetch group/terminated|Terminate=] |settings|'s [=fetch/fetch group=].

1. [=list/For each=] {{WebSocket}} object |webSocket| whose [=relevant settings object=] is
Copy link
Collaborator

Choose a reason for hiding this comment

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

This algorithm is called in parallel so I don't really think it's valid for us to be inspecting "each" WebIDL WebSocket object of a given settings object, and running algorithms on it that (a) HTML currently runs as a task on the Document's event loop, and (b) the WebSocket spec itself only runs as proper event-loop-bound networking tasks. So we should probably (a) figure out a better way to restructure this, and (b) add a step at the beginning of this algorithm to assert that this is running in parallel, to make it easier to catch this kind of stuff in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants