One other thing - as I understand the current design, if a preflight
request is redirected, the redirect is required to have a Access-
Control-Allow-Origin header. This is implied in the client redirect
steps, but should be spelled out in the server requirements as well.
Cheers,
On 29/05/2009, at 5:27 PM, Mark Nottingham wrote:
*** 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/
--
Mark Nottingham http://www.mnot.net/
