- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 2 Jun 2009 22:55:38 +1000
- To: public-webapps@w3.org
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/
Received on Tuesday, 2 June 2009 12:56:14 UTC