- From: Brad Hill <hillbrad@gmail.com>
- Date: Mon, 5 Aug 2013 16:48:57 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>, public-webapps@w3.org
- Message-ID: <CAEeYn8ghE3jfocLXXxnoPo65Mx4+=924KH9dakNH6N-CJW=ktA@mail.gmail.com>
I'd like to issue this as a formal Call for Consensus at this point. If you have any objections to CORS advancing to Proposed Recommendation, please reply to public-webappsec@w3.org. Affirmative response are also encouraged, and silence will be taken as assent. The proposed draft is available at: http://webappsec-test.info/~bhill2/pub/CORS/index.html This CfC will end and be ratified by the WebAppSec WG on Tuesday, August 13, 2013. Thank you, Brad Hill On Tue, Jul 16, 2013 at 12:47 PM, Brad Hill <hillbrad@gmail.com> wrote: > WebAppSec and WebApps WGs, > > CORS advanced to Candidate Recommendation this January, and I believe it > is time we consider advancing it to Proposed Recommendation. In the > absence of an editor, I have been collecting bug reports sent to the > public-webappsec list, and now have a proposed draft incorporating these > fixes I would like to run by both WGs. > > The proposed draft can be found at: > > http://webappsec-test.info/~bhill2/pub/CORS/index.html > > A diff-marked version is available at: > > > http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2F&doc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html > > (pardon some spurious diffs indicated in pre-formatted text that has not > actually changed) > > A list of changes is as follows: > > 1. Changed "Fetch" references. The CR document referenced the WHATWG > Fetch spec in a number of places. This was problematic due to the maturity > / stability requirements of the W3C for document advancement, and I feel > also inappropriate, as the current Fetch spec positions itself as a > successor to CORS, not a reference in terms of which CORS is defined. The > proposal is to substitute these references for the "Fetching Resources" > section of the HTML5 spec at: > > http://www.w3.org/TR/html5/infrastructure.html#fetching-resources > > I do not believe this produces substantive changes in the reading of CORS> > > 2. In the "Terminology" section, added a comma after "Concept" in response > to: http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html > > > 3. Per discussion to clarify the interaction of HTTP Authorization headers > with the user credentials flag, > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013 and > http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0366.html, > I have inserted the following clarification: > > "user credentials for the purposes of this specification means cookies, > HTTP authentication, and client-side SSL certificates > <!-- begin change --> that would be sent based on the user agent's > previous interactions with the origin. <!-- end change --> > > 4. In the defintion of the Access-Control-Allow-Methods header, in > response to > http://lists.w3.org/Archives/Public/public-webappsec/2013Apr/0046.html , > clarified that "The Allow header is not relevant for the purposes of the > CORS protocol. > > 5. http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.htmland > > http://lists.w3.org/Archives/Public/public-webappsec/2013Mar/0096.htmlpoint out > that header and method are not defined correctly in the response > headers for preflight requests. > It appears that the intent was to respond with the list provided as > part of the preflight request, > rather than the potentially unbounded list the resource may actually > support > > The following clarifications were made: > > (for methods) "Since the list of methods can be unbounded, simply > returning the method indicated by > Access-Control-Request-Method (if supported) can be enough. > > (for headers) "Since the list of headers can be unbounded, simply > returning the headers from > Access-Control-Allow-Headers (if supported) can be enough. > > 6. In response to: > http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html, > removed spurious 'than' > > 7. In response to: > http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html, > added comma after "Concept" > > 8. In response to thread beginning at: > http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0078.html, > added 204 as a valid code equivalent to 200 for the CORS algorithm. > > If these changes are acceptable to the WGs, I believe the only remaining > steps are to prepare an implementation report and update the test suite to > cover the 204 and 308 status codes. I'll let us discuss these for a bit > here before beginning a formal call for consensus. > > Please send comments to public-webappsec@w3.org > > Thank you, > > Brad Hill > > >
Received on Monday, 5 August 2013 23:49:26 UTC