Re: [cors] Review

On Sun, 14 Jun 2009 03:58:31 +0200, Mark Nottingham <mnot@mnot.net> wrote:
> As I said, I raised have raised substantive issues before:
>    http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0226.html
> and don't believe they were formally addressed (note that I'm using  
> Process terminology here). That experience didn't lead me to believe  
> that it was worth spending the time to track the specification closely.

What do you mean? We replied in a timely manner and attempted to address all of your issues until you were either satisfied with the response or stopped replying.


>> We decided to do it this way for compatibility with XDomainRequest.  
>> POST has further restrictions applied to it though. What exactly do you  
>> mean with "other contexts" by the way?
>
> Not HTML.

You mean other than <form>? If so, yes. However the context does not really matter here. The problem stays the same.


>> It seems unlikely we can change this at this point with several  
>> implementations shipping already. Quite unfortunate as your names do  
>> seem a lot better.
>
> Are those implementations widely used? Can't they support both for a  
> while? I can't imagine that may resources in the wild actually use this  
> mechanism yet, since support for it is presumably still only in a few  
> UAs.

It is in Internet Explorer 8, Safari 4, Chrome 2, and Firefox 3.5 last I checked.

Nevertheless, I created

  http://www.w3.org/2008/webapps/track/issues/89

so we can consider it one final time.


>> Content providers wanted the flexbility of not having to list every  
>> header in advance. Both so debugging headers and such would not have to  
>> be exposed and to reduce the payload.
>
> Which content providers? How much extra payload do you really expect  
> this to be?

I believe Google, Microsoft, Mozilla, and SitePen.

I don't know how much payload would be saved, but that was not the only reason.


>>> * Preflight cache - [...]
>>
>> Could you elaborate on what is not clear? I'm not really sure how to  
>> make it better.
>
> Without producing a complete proposal, no.

Ok :/


>> Implementors did not want a blacklist. The attack vector is the server  
>> inadvertently exposing headers it did not want to.
>
> Has this been discussed in depth before? If so, do you have a ref? I  
> think it deserves some serious discussion if not.

It has not been exhaustively discussed, I think, although it certainly has been discussed. There have been plans for allowing the list to be extended if the server explicitly opts in to more headers.

Some prior discussion on response headers:

  http://lists.w3.org/Archives/Public/public-webapi/2008Apr/thread.html#msg58

Here's a thread on request headers:

  http://lists.w3.org/Archives/Public/public-appformats/2008Feb/thread.html#msg168


>> * Chattiness - The protocol set out here requires a pre-flight request
>>> every time a new URL is used; this will force Web sites to tunnel
>>> requests for different resources over the same URL for performance/
>>> efficiency reasons, and as such is not in tune with the Web
>>> architecture. A much more scalable approach would be to define a "map"
>>> of the Web site/origin to define what cross-site requests are allowed
>>> where (in the style of robots.txt et al; see also the work being done  
>>> on
>>> host-meta, XRDS and similar). I made this comment on an older draft a
>>> long time ago, and have still not received a satisfactory response.
>>
>> See crossdomain.xml. It is a security nightmare. Especially when a  
>> single origin is being used for several APIs.
>
> Waving your hands and saying "security" is not a substantial response.

Ok,

  http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0050.html
  http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0052.html
  http://lists.w3.org/Archives/Public/public-appformats/2008Jan/thread.html#msg248
  http://www.w3.org/2005/06/tracker/waf/issues/22
  http://lists.w3.org/Archives/Public/public-appformats/2008Jan/thread.html#msg303


>> Added servers. It's not clear to me how to rewrite the specification in  
>> a way that does not leave gaps. If you can find another editor who can  
>> do that for us that'd be ok I suppose.
>
> I don't think saying (roughly) "that's the best we can do with limited  
> resources" is a substantial response either, but I have a feeling it'll  
> be accepted nevertheless :-/

By and large it seems like an editorial request and as editor I do not see how to address it.

To discuss your specific complaints:

 * The constraints it places on implementations are intended. Any rewrite would have to make the same requirements.
 * I've heard varied responses over what type of specification is easier to understand.
 * If this specification need to be reused in a way that conflicts with this specification it seems we can update this specification at that point.


>>> * Introduction - "This specification is a building block for other
>>> specifications, so-called hosting specifications."  This is an
>>> unfortunate term. How about "Cross-Origin Application Specification",
>>> "API Specification" or similar? (here and elsewhere)
>>
>> Can you explain why it is an unfortunate term? (Things like "host  
>> language" seem to be used elsewhere within the W3C. I thought this  
>> would be a fine extension.)
>
> Right, I'm just not sure that translates well to talking about referring  
> to this from another specification. "host" is already overused anyway.

Ok, I used CORS API specification.


>>> * Conformance Criteria - "A conformant server is one that..." --> "A
>>> conformant resource is one that..."
>>
>> I haven't done this yet. Does it still make sense to talk about a  
>> server processing model if we do this?
>
> Probably "resource processing model..."

I started making changes in that direction and it did not make a whole lot of sense. E.g. how would you rephrase "In response to a simple cross-origin request or actual request the server indicates whether or not to share the resource."?


>>> * Generic Cross-Origin Request Algorithms - for clarity, can this be
>>> split up into separate subsections?
>>
>> I added spacing instead. Does this work?
>
> My personal preference would be subsections, to make sure they're  
> distinct.

I left it as is for now. If more people want this I'll make the change.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Sunday, 14 June 2009 12:25:17 UTC