[cors] Review

*** Substantial issues

* POST as a "simple" method - POST is listed as a simple method (i.e.,  
one not requiring pre-flight) because there are already security  
issues that allow an HTML browser to send cross-site POST requests.  
However, other contexts of use may not have this problem, and future  
developments may close that hole. Requiring a pre-flight for POST  
because it is unsafe is the right thing to do for both of these reasons.

* Field-name verbosity - The defined header field-names are quite  
long, and contain misleading (this isn't really access-control  
information, at least on requests) and redundant (e.g., "request- 
method"). Suggest using:  CORS-Allow-Origin, CORS-Maxage, CORS-Allow- 
Cred, CORS-Allow-Methods, CORS-Allow-Headers, CORS-Method, CORS-Headers.

* Unnecessary request headers - removing the Access-Control-Request- 
Method and Access-Control-Request-Headers fields would substantially  
simplify the design; it would necessitate that the server list all  
methods and headers that are to be sent cross-origin in the preflight  
response, but this is not an onerous requirement.

* Preflight cache - As specified, the preflight cache is very complex  
and hard to understand. Removing the request headers above will help,  
and would enable a switch from OPTIONS to HEAD for pre-flights, again  
simplifying the design and allowing the use of a standard HTTP cache,  
instead of a purpose-built one. Failing that, the material related to  
the cache desperately needs a rewrite for clarity.

* Access-Control-Allow-Credentials - Has the WG considered making this  
header more fine-grained (e.g., allowing the authentication realm to  
be carried)? What about including the challenge on the pre-flight  
response?

* Request header deletion - The model of giving the server control  
over any and all additional request headers tightly couples the origin  
to the format of requests. It may be desirable in some cases to add  
local request headers (e.g., targeted at firewalls or proxies)  
programmatically, but this would not be possible using this design  
without coordination with the origin. Instead of a whitelist of  
"simple" headers, why not have a blacklist of headers that have to be  
explicitly allowed by the server (e.g., Cookie, Authorization)?

* Response header deletion - Again, deleting all but a pre-defined  
list of response headers is too draconian, and seriously limits  
extensibility on the Web. Again, why not just a blacklist? What's the  
attack vector here?

* 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.

* Procedural definition - This specification is defined as a set of  
procedural instructions for implementations. The advice that "User  
agents MAY employ any algorithm to implement this specification, so  
long as the end result is indistinguishable from the result that would  
be obtained by the specification's algorithms" is at best fallacious  
(besides leaving out servers); it sidesteps the question of what's  
meaningful in determining what is "indistinguishable." Specifications  
in this style unnecessarily constrain implementations, are more  
difficult to understand (e.g., it's difficult to understand the  
operation of a protocol mechanism such as a header without stepping  
through every single algorithm in the spec), and often preclude their  
reuse for unforeseen purposes.


*** Minor and Editorial issues

* Abstract - the use of "API" is a bit confusing.... suggest  
"Specifications that enable an API to make cross-origin requests to  
resources can..."

* Introduction - What does "limit the amount of unsafe HTTP requests"  
mean -- I may just not be getting the metric for 'amount.'

* Introduction - "Web application technologies" is stilted; while the  
WG has a good concept of what a webapp is, in the greater world this  
phrase means a server-side app.

* Introduction - "A resource can include..." --> "A response can  
include..."

* Introduction - "User-agents are enabled to discover..." --> "User- 
agents can discover..."

* 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)

* Introduction - There's a large section at the end that's indented;  
what's the significance of this?

* Introduction - "If a server author has a..."  This phrase naturally  
applies to the authors of servers; e.g., Apache, lighttpd, etc. It  
would be more clear and correct to say 'resource author." (here and  
elsewhere)

* Introduction - "...the resource combined with a header..." --> "the  
response"

* Introduction - "Using XMLHttpRequest a resource on http://hello-world.example 
  can access the document as follows:" --> "A client-side web  
application whose origin is http://hello-world.example can access the  
resource using XMLHttpRequest as follows:"

* Conformance Criteria - "A conformant server is one that..." --> "A  
conformant resource is one that..."

* Terminology - "simple method" is misleading and too generic. Suggest  
just using the term 'safe' in the RFC2616 sense (see substantial  
comment about POST).

* Syntax - Have the authors considered using ABNF, since HTTPbis is  
already using it?

* Syntax - If the 2616 BNF is retained, you need to explicitly point  
out that LWS is allowed.

* Syntax - all of these headers need to be registered with IANA; see  
RFC3864. Note that publication as a W3C Rec is enough, but the  
registration template needs to be in the document.

* Origin Request Header - will this refer to the Origin spec if/when  
it is published?

* Server Processing Model - This section repeatedly uses the term  
"URL" where "resource" is appropriate; a URL is an identifier for a  
thing, not the thing itself.

* Server Processing Model - shouldn't the list of origins include the  
same origin, or is that considered completely external to this  
process? A note about this would be helpful in either case.

* Simple Cross-Origin Request and Actual Request - What should the  
outcome be if the origin header is missing?

* Simple Cross-Origin Request and Actual Request - "Note: by failing  
this request servers..." What does "failing this request" mean in this  
context?

* Preflight Request - "... or if parsing failed, do not set any  
additional headers and terminate this set of steps."  Does this mean  
that the server should continue processing as if CORS were not in  
effect, or should a specific status code, etc. be returned? If it's  
the former, this should be explicitly specified.

* Preflight Request - "If any of the headers is not..." --> "If any of  
the header field-names is not..."

* Preflight Result Cache - it's not clear whether user-agents are  
required to implement a cache or not; I'm assuming it's optional.

* Generic Cross-Origin Request Algorithms - for clarity, can this be  
split up into separate subsections?

* Generic Cross-Origin Request Algorithms - "new URL" --> "the URL  
conveyed by the Location header in the redirect response"

* Resource Sharing Check - "...and the resource contains zero or more  
than one Access-Control-Allow-Credentials headers..." should end in  
"header values" because a HTTP header can contain multiple values.

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

Received on Friday, 29 May 2009 07:28:24 UTC