When you can specify "http://example.com", I don't see any complexity in saying that you are allowed (not obliged) to add a path.
This is definitely a must have
(think about big environment with on unique front-end & host name and several back-ends).

Nick

On 31/8/2011 9:50, Adam Barth wrote:
On Wed, Aug 31, 2011 at 12:04 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
On 8/30/11 10:33 PM, Adam Barth wrote:
It seems like we could let folks specify paths in addition to schemes,
hosts, and ports.

script-src http://example.com/js
We've talked about exactly that in the past. I'm fine with it, iirc
we dropped it because people were already complaining about
"complexity".
Yeah, I agree that the main cost is complexity.  The main question is
whether this problem is actually "deadly" or whether lcamtuf is being
hyperbolic.

Adam


CSP is still behind vendor prefixes in the two
implementations I'm aware of, so making non-forwards compatible
changes is probably still fine.
If we cared enough we could make it forwards compatible by creating
"script-src2" which old implementations would ignore, and make new
implementations honor script-src if script-src2 is not present. But
then sites that want to be compatible with both old and new (and
take advantage of the path feature) have to enumerate their script
sources twice.

I'm not seriously suggesting we do that.

If we support path prefixing for script-src I'd want all the
content-load directives to support it for consistency. I also would
really like to avoid introducing regexp and instead limit this to
simple string prefix matching. I'd be fine allowing full-path match
down to the filename; someone requested that at one point. I think
in practice it would make policies too large (and again complex),
but if we're halfway there no harm in going the rest of the way.

-Dan Veditz