Re: Form HTTP Extensions

Hi Mike,

On Thu, Apr 17, 2014 at 10:19 PM, mike amundsen <mamund@yahoo.com> wrote:

> I really *want* to see PUT, DELETE and (yes even) PATCH supported in the
> HTML media type.
>

Yes, that was the initial requirement however supporting additional HTTP
methods is of little benefit nor use without the ability to define HTTP
headers like Last-Modified and E-Tag. Performing a PATCH, especially, is of
no use if there is no definition of optimistic concurrency versioning.

The reasons for the design within the specification was initially laid out
in the rationale for ISSUE-195:

http://www.w3.org/wiki/User:Cjones/ISSUE-195


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

The "magic strings" defined as "form control fields" represent predefined
controls for triggering specific behavior by the UA. This is a common
pattern within HTML as it is also used, for example, in the @target
attribute on anchors for denoting specific link-following behavior.

In the specific case of form submission @name attributes, there are 2
existing control fields - "isindex" and "_charset_". Ignoring "isindex"
(for good reason), if we look at "_charset_" we see that this is
specifically designed to provide a trigger for behavior during the Form
Submission Process. This is the same approach taken for the
protocol-dependent "_username_", "_password_" and "_logout_" field control
names.

The use of the @type attribute is unsuitable as this negates the use of
type="password" fields for capturing sensitive data and integration with
password managers.


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

There is no predisposition to basic-auth, the mechanism for HTTP
Authentication is the same employed within XHR and is defined by
"WWW-Authenticate" negotiation. It is currently limited to the two most
common authentication parameters which satisfy both BASIC and DIGEST, but
there is no reason new parameters could not be introduced if such HTTP
Authentication schemes are developed/introduced/gain widespread adoption.

The problem with creating new attributes on <form> is that these are
outside the scope for user-input.


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

The @enctype is for the media type of the data encoding, the @payload
attribute is outside this scope and defines the respective part of the HTTP
request which the data should be bound to. It is so that you can target
either the URI query parameters, HTTP headers and Media content both
separately and at the same time. For example, here it can generate a HTTP
request with complete flexibility, from user input and using any desired
<input> @type and parameters (@pattern for example):

<form action="http://www.example.com/service" method="POST">
    <input name="Myqueryparam" value="query-value" payload="_action"/>
    <input name="Myheaderparam" value="header-value" payload="_header"/>
    <input name="Mydataparam" value="data-value" payload="_body"/>

    <button type="sumit"/>
</form>

Will generate the following HTTP request structure:

======
POST /service?Myqueryparam=query-value HTTP/1.1
Host: www.example.com
Myheaderparam: header-value

Mydataparam=data-value
======

I can definitely appreciate that "payload" is probably not the most
intuitive of names since it has connotations within TCP and HTTP, however
the preferred name for this, "target", is already taken and using something
even more vague like "bind" or "load" i thought might be more confusing.

As it is, the interpretation of the semantics of "payload" is intended to
mean - "What part of the payload is targeted by this <input>?"

I am open to any suggestions on a better choice, however i thought that
given the protocol-independence of this attribute, it would need to be
generic enough to be applicable to any current or future URI scheme and
transmission protocol.

Note that the use of @payload is also relevant to the "mailto:" scheme and
adds benefit there too.


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

The @enctype is only for the "Content-Type" header. Since the expected
media type is defined by server capability, there is no use case for any
further configuration of this header and it is an explicitly restricted
header along with the others which have been copied verbatim from XHR.

Using <form> attributes for HTTP headers excludes the possibility of
user-defined header values, and would either require minting new attributes
for each one or minting a new free-form prefix-attribute which is a less
desirable approach as it would be protocol dependent and would also be
limited by HTML attribute syntax instead of HTTP header syntax.


> 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.
>
>
I've outlined the reasons why protocol-dependent attributes and types are
unfeasible. What is the purpose of to "isolate/ignore the extension"? These
represent progressive enhancements and must be declared to be used, so
people can choose to use them if they see benefit for their use cases.

The introduction of new form control fields would be an area where there
could be a clash with existing implementations, however the behavior is
triggered through the document being served with the "WWW-Authenticate"
header for HTTP Authentication negotiation. As such, it precludes the scope
for clashing with current implementations as no-one would serve a login
page using cookie-based authentication in addition to HTTP Authentication
as this would induce both a login form and a login popup by the UA.


Thanks,
Cameron Jones


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