Re: ISSUE-195: form-http-req - Chairs Solicit Alternate Proposals or Counter-Proposals

On Thu, Mar 22, 2012 at 10:33 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 22 Mar 2012 11:26:39 +0100, Julian Reschke <julian.reschke@gmx.de>
> wrote:
>>
>> At some point a previous proposal stated that for methods other than
>> GET/HEAD/POST, the same requirements as for XHR should apply.
>
>
> That could maybe work, although CORS failures are identical to network
> errors which do not seem desirable for end users to face. Additionally it
> would probably be better if we gained more experience with this feature via
> XMLHttpRequest first, before widening the scope.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Hi Anne,

The proposal advocating for the additional form methods has been
produced with due care and attention given to security issues and
especially in light of the work done over the years  in webapps,
webapp-sec and through the requirements and specification of CORS.

I'd first like to highlight that the specification of HTML rightly
does not impose the necessity of CORS in the same manner that many
other independent  specifications are not prerequisites for
implementation or use of HTML.

I’d also like to highlight that through the development of the
proposal i have gathered a review of web app security which
specifically addresses the premise of CORS and the wider impact of
implementation of such technology. This review has been submitted to
webapp-sec and as the group chartered with responsibility over the
functional area it would seem to be the forum to discuss those
security related concerns. As the editor of CORS i am specifically
interested in discussing the points brought forward through my review
with you and other members of the group such that they are addressed
by the group to a degree of resolution for implementation or
documentation. Here is a link to the archived copy of that review:

http://lists.w3.org/Archives/Public/public-webappsec/2012Mar/0027.html

To respond to your concerns raised herein, the proposal as written
defers all request generation restrictions to the specification of
XHR. This is specifically first due to the overall concept that the
same functionality afforded to XHR should be available to declarative
markup, and further to this that the specification of these features
follow a path of least resistance within the overall movements of web
standards and implementations.

Given that the specification of forms is vis-à-vis the specification
of XHR, there is no introduced user security or interface interactions
within the recommended proposal. Further to this, as the means to
expose the HTTP protocol to declarative markup there is no experience
to be gained from waiting as the protocol is both stable and
universally deployed and integrated.

Thanks,
Cameron Jones

Received on Thursday, 22 March 2012 11:39:13 UTC