For images that load using the PingLoader (images that load while the page is being torn down), we currently don't re-apply img-src CSP directive on every redirect as the spec says we should.
(In reply to comment #0)
> For images that load using the PingLoader (images that load while the page
> is being torn down), we currently don't re-apply img-src CSP directive on
> every redirect as the spec says we should.
Is there a test case for this, or a site we know exhibits this behavior?
I briefly thought about this bug today. There seem to be at least two complications of the current WebKit architecture that make fixing this non-trivial: 1) the lifetime of a ping handle is different from the lifetime of the document that initiated the ping request 2) in WebKit2 ping loads are made in the network process.
Disregarding the need to emit a console message when CSP blocks a redirected ping request (would this be observable to web developers given that we are tearing down the page?), one way to avoid the need to tie the lifetime of the ping handle to the document is to have the ping handle/ping loader own a copy of the document's ContentSecurityPolicy object and use this copy to evaluate the CSP policy to determine if the redirect is allowed.
The reason it would be good to avoid having the lifetime of the ping handle be tied to the lifetime of the document is to avoid blocking the UI process/thread for a slow ping response. (Although we do not care about the response data for a ping, we do wait up to 1 minute for a response).
For completeness, if we wanted to have the lifetime of the ping handle be tied to the lifetime of the document then one idea is to move the ping handle/ping loader logic to a ResourceHandleClient-like model such that the handle calls back to the WebProcess portion of the ping loader when it needs to decide whether to take a redirect (a ResourceHandleClient::willSendRequest()-like callback). The ping loader can then query the CSP of the document to determine if the redirect is allowed.