W3C home > Mailing lists > Public > public-html@w3.org > April 2014

Re: Form HTTP Extensions

From: mike amundsen <mamund@yahoo.com>
Date: Thu, 17 Apr 2014 17:19:45 -0400
Message-ID: <CAPW_8m7d9U394S=SphATyH=w8=EuDiuY1tGBw06XthzSghwcNQ@mail.gmail.com>
To: Cameron Jones <cmhjones@gmail.com>
Cc: "public-html@w3.org LIST" <public-html@w3.org>
I really *want* to see PUT, DELETE and (yes even) PATCH supported in the
HTML media type.

However, I see several problems with this particular approach:

1) creating "magic strings" for INPUT@name is not a good idea and runs
counter to the way HTML handles data arguments. if you want new inputs
types, then use the "type" attribute, don't create special-case values for
the "name" attribute.

2) I think trying to support basic-auth for this extension is not needed.
Why this and not other auth formats? again, using INPUT@name for this is a
problem. if you really want to do this either mint INPUT@type values or
create new attributes on the FORM element.

3) we already have FORM@enctype so I don't see the need for "payload"

4) we already use "enctype" to map to content headers so I don't see the
need for a "_header" construct. If there are headers you think should be
made available for FORM submits, create atrtibutes on the FORM tag.

I also am not clear that this proposal is "backward-compatibility" safe.
using unique attributes or type names would make it much easier to
isolate/ignore the extension. As it stands now, it's possible that these
new names will clash with existing implementations.





mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Thu, Apr 17, 2014 at 9:42 AM, Cameron Jones <cmhjones@gmail.com> wrote:

> Dear all,
>
> I am about to submit an email to public-html-admin requesting the
> publication of an extension specification for Form HTTP Extensions. Prior
> to this and minting a FPWD snapshot i would like to initiate this thread
> for any further technical discussion over the specification. The current
> editor's draft resides here:
>
> http://cameronjones.github.io/form-http-extensions/index.html
>
> The extension specification resolves the previously tracked "ISSUE-195:
> Enhance http request generation from forms":
>
> http://www.w3.org/html/wg/tracker/issues/195
>
> In summary, the extension amount to the following changes:
>
>     * Remove restrictions on form HTTP methods to allow for PUT and DELETE
> methods, in addition to HTTP extension-methods for private\experimental use
> under CORS restrictions.
>     * Introduce @payload submission attribute on form controls allowing
> targeting URL queries, HTTP headers and message data from user input or
> hidden fields.
>     * Extends the use of named form control fields to include "_username_"
> and "_password_" for integration with User Agent HTTP Authentication, akin
> to XHR open() method arguments.
>     * Additional "_logout_" named form control field for initiating
> clearing of User Agent HTTP Authentication Cache defined by RFC2617
> "protection space".
>
> The following is a list of additional references with further discussion
> and/or information:
>
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/208357.html
> http://lists.w3.org/Archives/Public/public-html/2013Feb/0227.html
>
> Feedback is most welcome!
>
> Thanks,
> Cameron Jones
>
>
>
>
>
>
>
>
Received on Thursday, 17 April 2014 21:20:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:38 UTC