Re: policy-uri is slow

On 15/04/2011, at 10:47 AM, Adam Barth wrote:

> To confirm my understanding, if a document has a CSP policy consisting
> of a policy-uri, then the user agent is supposed to block processing
> of the document until it finishes fetching the policy-uri, right?
> That seems very bad for performance.

It can be, but so can putting verbose policy statements on every response you send. 

If the policy-uri is cacheable for a decent amount of time, the performance impact is only there when the cache is empty or expired.

The effects can be further mitigated by;
  - adjusting the client's cache eviction algorithm to be conservative about kicking out policy files
  - implementing connection pre-heating and HTTP pipelining (as Mozilla is currently) to decrease the impact of making that request
  - implementing stale-while-revalidate (RFC5861) in the client's cache so that when the cache is expired, the update happens in the background, in a controlled way.

If anything, I'd like to see this mechanism further optimised; i.e., instead of communicating the URI in each response (with the associated overhead in response size as well as the chance for introducing errors), have a well-known location (RFC5785) for policy files that the client can check proactively while it makes its initial request -- that way, it's much less likely to block anything. And even less bytes are in responses this way, of course. 

[snip]

> Should we drop support for policy-uri?

No.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 15 April 2011 02:56:08 UTC