Re: ISSUE-195: form-http-req - Chairs Solicit Proposals

Apologies, i missed cc'ing the list so replying to the missing thread
with permission.

On Tue, Feb 14, 2012 at 6:48 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2012-02-14 19:34, Cameron Jones wrote:
>>
>> On Tue, Feb 14, 2012 at 8:33 AM, Julian Reschke<julian.reschke@gmx.de>
>>  wrote:
>>>
>>> On 2012-02-13 16:33, Cameron Heavon-Jones wrote:
>>>>
>>>>
>>>> Hello Chairs,
>>>>
>>>> I would like to submit the following change-proposal for ISSUE-195 -
>>>> Enhance HTTP request generation from forms:
>>>>
>>>> http://www.w3.org/wiki/User:Cjones/ISSUE-195
>>>>
>>>> Thanks,
>>>> Cameron Jones
>>>> ...
>>>
>>>
>>>
>>> Re: methods: why is HEAD there (it has the same semantics as GET, only
>>> differ in the response format)? Why is CONNECT here (switches the
>>> protocol,
>>> how is this supposed to work)? Why is PATCH missing?
>>>
>>> Best regards, Julian
>>
>>
>>
>> HEAD is included because i see no reason not to include it...i agree
>> at first it doesn't seem to make much sense, however it could be
>> valuable for providing tests which list server or service status
>> reports. this integrates well with _asyc_ in which a response body is
>> not necessarily desired.
>
>
> It would be good to understand that use case better.

the use case is the means to test URIs without the additional load of
having a response which is not needed. for liveness tests a simple
status code is ample response, especially if the response would
otherwise incur heavy server processing or include large assets. being
able to process a response asynchronously allows the page to update a
state indicator based on response status.

further to this, admin or dev pages may provide pages as a means of
documentation with forms to initiate and test services through normal
synchronous requests. response headers are available through UA debug
tools, and possibly in future some browser 'chrome' could be initiated
via status code or metainformation.

another distinct use case is the ability for submit buttons to
retarget requests using different HTTP methods. this may allow
distinct "test" and "apply" buttons on forms initiating accessibility
tests prior to performing the action to check for resource
modification by way of etags or last-modified. essentially this
amounts to an optimistic lock check.

>
>
>> CONNECT is included to provide means to navigate across proxies and
>> enable communication channels. there is nothing inherently insecure in
>> the method and it provides access to new services that may otherwise
>> be unavailable.
>
>
> See above. It's totally unclear to me why you would ever want to do that
> from an HTML form, and how the response processing would work.
>

There is the possibility that the server being connected is the origin
server and this may have its own use cases.

What i've been interested in is the possibility to enhance the
abilities of public web proxies for users who are otherwise under
restrictive surveillance or access policies and require some degree of
assistance in order to circumnavigate restrictions.

The CONNECT method may include request data which is sent with the
connection request and, in terms of form response processing, there is
no necessity for the connection to remain open. There may be potential
for greater functionality in the 'response' event as is available
through XHR and connection states. The more aligned these are the
better, i believe. The form element may be regarded as a UI
representation of this interface.

As the CONNECT method is currently disallowed from XHR (as
SecurityError which seems a misnomer) and as the justification for it
is more speculative than necessitive i can see how it may be undesired
and could be removed.

>
>> PATCH is missing only because it is an extension to HTTP/1.1 and while
>> it may be valid for inclusion i avoided extending the methods beyond
>> the base protocol. there are a number of extensions to HTTP which i
>> would highly disagree with, PATCH is not one of them though so i agree
>> it could be added.
>
>
> Which raises the question whether the proposal should whitelist specific
> methods, or just blacklist others.
>
> PATCH is one of the few methods where form support would indeed be useful.
>

Yes, PATCH is useful and should be included. the proposal is in
essence a whitelist.

If implemented as a blacklist, it could follow the XHR blacklist for
simplicity.

are there any other methods you're specifically thinking for
inclusion, LINK or such? having open specifications is a boon for
innovation.

Thanks,
Cameron Jones

Received on Thursday, 16 February 2012 17:49:06 UTC