Explainer for Document-Policy in Workers #1182
Conversation
|
|
||
| **Dedicated Workers:** | ||
| - For network scripts: Parse `Document-Policy` from the worker script's HTTP response headers | ||
| - If no `Document-Policy` header is present: Feature is disabled by default (e.g., self-js-profiling not exposed) |
There was a problem hiding this comment.
This should likely converge to existing behavior for document context which is for each configuration point to have a default value of its own. It might not seem that different for self-js-profiling, but Document Policy does define more than booleans.
| **Shared Workers:** | ||
| - For network scripts: The worker script response headers define the effective Document Policy | ||
| - When multiple documents attach to the same worker: | ||
| - The first document that creates the worker establishes its effective document policy from the script's HTTP response header |
There was a problem hiding this comment.
Might benefit from some re-wording? AFAIU the document doesn't really play a role other than initiating the request? So it would be the Document Policy is set from the script's HTTP response header when the worker is first created?
| - For network scripts: The worker script response headers define the effective Document Policy | ||
| - When multiple documents attach to the same worker: | ||
| - The first document that creates the worker establishes its effective document policy from the script's HTTP response header | ||
| - Later attachers with mismatched policies are ignored. |
There was a problem hiding this comment.
Do I understand correctly that it's not only documents attaching later, but Document Policy from worker clients is not considered at all for what the policy in the worker is? For example:
document 1: ``
worker script: self-js-profiling
So the feature is enabled on in the worker context regardless of the policy in the creating document?
2 participants
No description provided.