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