- From: Cameron Jones <cmhjones@gmail.com>
- Date: Thu, 16 Feb 2012 17:48:34 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: public-html@w3.org
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