User:Cjones/ISSUE-195

From W3C Wiki
< User:Cjones
Revision as of 18:13, 11 February 2012 by Cjones (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


ISSUE-195: Enhance HTTP request generation from forms

Summary

This proposal is for the enhancement of HTML forms in complete integration with the HTTP protocol and the ability to generate entire requests through declarative HTML markup in the absence of scripting support. This proposal leverages the maturity of the XHR specification by exposing the additional functionality afforded through javascript direct to declarative HTML code.

The first requirement of this proposal is to extend the supported HTTP methods to include the entire range of non-client-hazardous methods from HTTP/1.1:

   HEAD, GET, OPTIONS, CONNECT, PUT, POST, DELETE

Note: TRACE has been specifically excluded due to the potential for exposing otherwise restricted client-controlled information to the DOM

The second requirement of this proposal is the introduction of declarative authoring of HTTP headers within form fields. This is essential to the extension of methods due to their required semantics for the control of ETags and representation versioning. The approach for introducing this functionality is by means of addition of a "payload" attribute to be included on submittable elements:

   button
   input
   keygen
   object
   select
   textarea

The attribute consists of a set of enumerated values for targeting different areas of the generated request:

   _action
   _header
   _body
   _none

The third extension to the specification is the addition of form control fields representative of the named parameters to the XHR "open()" method to be treated in the same manner for controlling the operation of the form request. The forth field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:

   _user_
   _password_
   _async_
   _logout_

The forth extension to the specification is the addition of the <output> element as a submittable element. This element is currently capable of representing calculations over <input> and <output> values and the result of these calculations should be available to be sent as part of a request to avoid those same calculations being duplicated by the request processor.


Rationale

The rational for these enhancements can be initially explained by first exploring the role of HTML within the suite of technologies comprising the World Wide Web, namely URIs for identification, HTTP for communication and HTML for declaration.

The first point to be highlighted is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTTP and HTML, and is self-evident in the understanding of these technologies with regards to their communication and representation of Resources and the means to identify them by URIs.

This irreducible system has proven itself through its successful global deployment and universal adoption, however there exists a limitation of the system in the ability of self-description within HyperText and this omission limits its overall effectiveness.

The declaration aspects of the system within HTML have been reduced to a level of 'read' and 'write' operations with all other operations being 'tunneled' through these. While this is sufficient in achieving a system which can function it precludes the system from its full potential.

The main beneficiaries of these enhancements are not end users directly, but the community of authors, developers and implementers who will be empowered with the exposure to the transfer protocol for the technological benefits that come with having access to the entire feature set. This pays dividends in productivity, understanding, and innovation that come from the ability to interact with complete protocol features.

The application of the ability to control request generation is defined to be unlimited in what methods may be used, what aspect of the payload may be targeted and from which method they may be used with. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and bodies may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of openness is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.

The additional functionality exposed in this set of enhancements is the ability for declarative authoring of HTTP Authentication through forms. This represents a significant advancement for the web in the native support for web sites to use these authentication methods over the proliferation of 'session' based cookie schemes which is the predominant security hole exposed through agent software. The application of HTTP authentication with TLS\SSL transport-level security provides a session-less authentication and authorization mechanism with capability to be used on sites with the most heavy security requirements.

The "_logout_" form control field is a method for form-based control of in-site HTTP authentication credentials. As with other form control fields it is used to initiate custom browser controlled behaviour over the handling of form requests. A form configured with this control field will construct and send a HTTP request to the URI constructed through the action attribute retaining the existing HTTP Authentication headers in its cache. This request is used to indicate to the server that the limit of authentication has ended and the user has requested to be 'logged out'. On a successful response from the server, the UA will clear the cache for the origin thereby completing the logout process. The ability to control the HTTP authentication cache is currently unavailable in browsers through any means and represents an unacceptable security hole in the adoption of HTTP authentication.

The exposure of the "_async" form control field currently available to XHR scripting will allow AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this will lead to innovation in the development of rich 'webapp' style HTML documents and additional enablement of frames for such purposes. The "onresponse" event type is added to enable declarative script handling of the responses and data in-line.

In summary, the changes proposed herein represent the progressive enhancement to HTML forms as initially proposed by HTML5 and already available albeit in the much less accessible manner of XHR and scripted client environments. This set of changes radically open up the expressiveness of the language with the exposure of preexisting functionality which has reached the level of maturity ready for universal adoption.

Details

  • Add the HTTP methods types as keywords and states to the list of valid enumerated attributes for the "method" and "formmethod" content attributes:
   HEAD, OPTIONS, CONNECT, PUT, DELETE
  • Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"
  • Add the restriction of state of the "payload" content attribute to one of the following enumerated values:
   _action, _header, _body, _none
  • Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":
   _user_, _password_, _async_, _logout_
  • Add the definition of the "_user_" special form control on a Text control as the value and behaviour of the XHR authentication parameter "user"
  • Add the definition of the "_password_" special form control on a Password control as the value and behaviour of the XHR authentication parameter "password"
  • Add the definition of the "_async_" special form control on a Hidden control as the value and behaviour XHR parameter "async"
  • Add the definition of the "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.
  • Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the form elements whose "payload" attribute is resolved to the value "_action"
  • Update the form submission algorithm by specifying the state of the "request headers" to be the set of form elements whose "payload" attribute is resolved to the value "_header".
  • Update the form submission algorithm by specifying the state of the "form data" to be the set of form elements whose "payload" attribute is resolved to the value "_body".
  • Update the form submission algorithm by specifying that the set of form elements whose "payload" attribute is resolved to the value "_none" are not to be used.
  • Update the form submission algorithm by removing the method table and replacing it with a scheme switch to sections defining a scheme-specific set of processing instructions
  • Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:
  1. Let the definition of resolution of the set of elements with payload "_action" be those that have their attribute set to "_action" or with unset attribute and the resolved method state of HEAD, GET, OPTIONS or DELETE
  2. For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters
  3. Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"
  4. For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR
  5. Let the definition of resolution of the set of elements with payload "_body" be those that have their attribute set to "_body" or with an unset attribute and the resolved method state of PUT, POST or CONNECT
  6. For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR
  7. If there exists a form element corresponding to the special control "_user_", "_password_" or "_async" then these values must be applied to the request as with the same definition described in XHR
  8. Send the constructed request by HTTP(S) method defined by the submitter element's resolved method attribute state.
  9. If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.
  • Remove the definition of the FTP scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.
  • Remove the definition of the javascript scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.
  • Add the definition of the data scheme processing instruction set as defined by the following process:
  1. For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".
  • Add the definition of the mailto scheme processing instruction set as defined by the following process:
  1. For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.
  2. For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.
  3. For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="
  4. Navigate the target browsing context to destination represented by the action
  • Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response
  • Add the <output> element to the list of submittable elements and enable it for inclusion in the construction of the form request set

Impact

Positive Effects

  • Declarative specification of HTTP web services
  • Enables HTTP web services for scriptless clients
  • Simpler explanation, documentation and education of HTTP web services
  • Correct use of HTTP without tunneling through unsemantic and non-idempotent POST method
  • Headers allow for complete request representations supporting the requirements of the semantics of idempotent methods and the ability for further declaration of response negotiation through methods such as "Prefer" headers
  • Greater functionality of form submission attributes on buttons for customizing the data set with different request parameters
  • Flexibility for specifying all aspects of the request for any method, ie query parameters for POST, etc
  • <input> and <output> defined header fields configured using any type or calculation
  • Body targeting enables digital keys for capability-based security within GET requests
  • HTTP Authentication driven by forms bypasses unfriendly browser popups and allows site controlled and familiar CSS user-interfaces
  • Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache
  • Asynchronous requests enable rich webapp style documents
  • Mailto forms can construct messages with multiple recipients and full control over scheme headers and body contents

Negative Effects

  • The introduction of payload targeting introduces a more complex form request generation algorithm, however backward compatibility is maintained
  • Introduces greater reference to XHR specification
  • Introduces greater requirements on implementations
  • Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality required for the functions of a 'webapp'

Conformance Classes Changes

  • Additional conformance defined through the the application of changes in the "Details" section
  • HTTP Authentication is non-required conformance on implementations
  • Asynchronous requests are non-required conformance on implementations
  • FTP and javascript schemes are non-required conformance form actions

Risks

  • Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.
  • Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers should be applied as requests generated from XHR.
  • Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.
  • Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behaviour to be triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of form controls to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.

References

  • Bug 10671 - consider adding support for PUT and DELETE as form methods [1]
  • ISSUE-195: Enhance HTTP request generation from forms [2]
  • XMLHttpRequest [3]
  • Hypertext Transfer Protocol -- HTTP/1.1 [4]
  • HTTP Authentication: Basic and Digest Access Authentication [5]