-
Notifications
You must be signed in to change notification settings - Fork 79
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
Resource hint blocking / "least restrictive" as specified does nothing? #633
Comments
Thanks, yes I can see the bug in the spec. Since this is implemented in Chromium I'll try to find where they diverge and amend the spec. |
I'm seeing that here we call "Get the effective directive for request" but that doesn't exist in chromium, istead there is something called the "operative directive". |
I think "Get the effective directive for request" corresponds in chromium to GetDirectiveTypeFromRequestContextType. I don't know the background, but I suspect that the implementation diverges from the spec for optimization reasons (for example for an image, the spec mandates to do a loop over all directives and perform the pre-request check of every directive, but that pre-request check will be useless unless the directive is
I think this is the best way to go. |
Apparently the previous wording was a no-op. Instead of calling the pre-request check, checking the resource list for the directives that have that as a value. Closes w3c#633
OK then! #637 |
@noamr can I check the wording of the default directive also:
In the absence of a |
"6.7.2.2 Does resource hint request violate policy?" executes the pre-request check on every directive.
The pre-request check of almost all directives looks like this (e.g. img-src Pre-request check):
6.8.1. Get the effective directive for request
6.8.4. Should fetch directive execute
6.8.3 Get fetch directive fallback list
So we probably need to extend 6.8.3. However that still means we would only match the explicit default-src. In the end it seems like using the pre-request check, for what is a totally unrelated request, is just bound to cause issues.
Maybe it would be better to have an explicit list of supported directives e.g. img/video/script etc. and just call § 6.7.2.4 Does request match source list? directly from 6.7.2.2.
#582
/cc @noamr
The text was updated successfully, but these errors were encountered: