Re: [webappsec + webapps] CORS to PR plans

Based on the feedback received during the Call for Consensus, I've updated
the draft CORS PR at:

http://webappsec-test.info/~bhill2/pub/CORS/index.html

Language about an implementation report has been removed, and the only
substantive modification from the previous proposed draft is that
references to status codes 200 and 204 have been replaced with "the 2xx
range" based on conformance testing that showed interoperability across the
broad set of codes.

A supplemental test report on the 2xx status codes as well as 308 redirect
handling is available at:

http://webappsec-test.info/~bhill2/pub/CORS/cors-test-supplement.htm

2xx handling is implemented consistently across Opera (Presto), IE,
Firefox, Chrome and Mobile Safari.

308 handling is implemented consistently with 307 handling in Opera
(Presto) and IE, and partially implemented in Firefox, satisfying the WG's
criteria of two independent interoperating implementations.

Additional test result submissions are welcome and encouraged.  (I don't
have a desktop Mac environment easily at hand.)

This message resets the call for consensus by an additional seven days, to
23-Aug-2013.  Please send feedback to public-webappsec@w3.org.  Positive
feedback is encouraged and silence will be considered assent.  I have
updated the target date for PR to 26-Sep-2013.

Thank you,

Brad Hill




On Mon, Aug 5, 2013 at 4:48 PM, Brad Hill <hillbrad@gmail.com> wrote:

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