Re: [AC] URI canonicalization problem with Access-Control-Policy-Path

>  > * Different syntax for the header to signal if access should be granted
>  > or not. I.e. changes to the syntax for the Access-Control header. I
>  > think this is basically the PEP discussion that has been raised a number
>  > of times.
> Yes. Sorry if I continue to believe that domain-based allow/deny 
> enforcement should be done on the server.

Please note that the policy *enforcement* is at the same place for both 
the AC Access-Control header, and the XDR XDomainRequest header. It's 
just a syntactic difference. I.e. does the client check for the value 
'1', or does the client compare the list in the allow header to the 
origin of the requesting site.

>  > * Some editorial changes to the spec to make it more explicit about
>  > various risks when opting into various features.
> Yes, but I wouldn't discount these editorial changes. In this case 
> (i.e., cross-site requests), education is important, and the spec will 
> be an important educational document.

Agreed. My list was not intended to say that I agree or disagree with 
your proposal. It was simply trying to reformulate it in order to make 
sure I had understood it.

>  > >  > Also, isn't doing the OPTIONS request moving the PEP into the 
> client ;)
>  > >
>  > > One key thing is that the allow/deny logic has moved to the server. 
> The
>  > > OPTIONS request in effect is just an optimization thing.
>  >
>  > What? The client MUST not send a DELETE or POST request unless it has
>  > checked with the server first, no? Or are you saying that the client MAY
>  > do the OPTIONS request if it wants to, or it is allowed to just go ahead
>  > and do send a DELETE request right away?
> No, the browser most definitely MUST honor the information sent back 
> from the server. If a particular method is not allowed within a 
> cross-site request, the browser MUST not send that request. What I was 
> saying is that the server should not assume that the client is 
> trustworthy and should not rely on client enforcement and instead should 
> check every subsequent request.
>  >
>  > > The server
>  > > should still check each request regardless of what it responded to the
>  > > OPTIONS request.
>  >
>  > But legacy servers will not do that right? So in order to protect those
>  > we need to rely on the client not sending harmful requests to them
>  > before checking using OPTIONS that that is ok?
> Right. That's the only possible thing we can do about legacy servers.

So it seems that we can agree that in order to protect legacy servers we 
have to rely on the client to do the right thing.

/ Jonas

Received on Saturday, 17 May 2008 00:56:27 UTC