ISSUE-195: Enhance HTTP request generation from forms
The first requirement of this proposal is to extend the supported HTTP methods by extending the specification of the form method attribute to allow any value for the generated request. In order to protect the user from exposing client-controlled information to the DOM, and to alleviate the client from handling CONNECT operations, the method attribute restricts the allowed values to exclude the blacklist of prohibited methods:
CONNECT, TRACE, TRACK
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
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 “_logout_” field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:
_user_ _password_ _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 for payload binding or to be sent as part of a request body to avoid the same calculations being duplicated by the request processor.
The final extension to the specification is the addition of an “async” boolean attribute for form submission. This attribute is added to <form>, <input> and <button> elements for defining the mode of submission of the form request either as a blocking synchronous or non-blocking asynchronous user interface operation.
- 1 ISSUE-195: Enhance HTTP request generation from forms
- 1.1 Summary
- 1.2 Rationale
- 1.3 Details
- 1.4 Impact
- 1.5 References
The rational for these enhancements can initially be explained by 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 highlight is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTML and HTTP, 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 is a limitation of the system in the ability of self-description within HyperText and this omission limits the 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 addition of the "async" submission form attribute is functionality currently available to XHR scripting and allows AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this leads 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 for universal adoption.
- Update the valid state for "method" and "formmethod" content attributes to be any value excluding those defined by the following enumerated blacklist:
CONNECT, TRACE, TRACK
- 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
- Add the following special values to the list of restricted values for form element's "name" attribute in section "126.96.36.199 Naming form controls":
_user_, _password_, _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 "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.
- Add “async” as a new boolean content attribute for form submission with a default state of false to each of the submission elements:
form, button, input
- Add the “disabled” content attribute to the <object> and <output> elements and retain its state and operation as defined for the other submittable elements where the value represent by the element is excluded from the set of submittable form elements.
- 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 submittable 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 submittable 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 submittable form elements whose "payload" attribute is resolved to the value "_body".
- 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:
- 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.
- For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters
- Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"
- 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
- 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, PATCH or custom method.
- 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
- If there exists a form element corresponding to the special control "_user_" or "_password_" then these values must be applied to the request as with the same definition described in XHR
- Construct the request using the HTTP(S) method defined by the submitter element's resolved "method" attribute state.
- Send the constructed request as either a synchronous or asynchronous request as defined by the submitter element's resolved "async" attribute state.
- 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.
- Add the definition of the data scheme processing instruction set as defined by the following process:
- 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:
- 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.
- 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.
- 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="
- 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
- Declarative specification of HTTP web services within the HTML language
- Enables HTTP web services for scriptless clients and environments
- Simpler visible programming, explanation, documentation and education of HTTP web services and forms
- Correct use of HTTP without tunneling through the non-semantic and non-idempotent POST method
- Greater functionality in form submission attributes on buttons for customizing the data set with alternate request parameters
- Headers allow for complete request representations by including protocol or custom headers which are essential aspects of action and intent
- Headers support the essential semantics of idempotent methods
- Headers support additional response negotiation through techniques such as "Prefer" headers
- Enables scope for further innovation over the protocol which is increasing using headers as a representational state mechanism
- Allows the flexibility to specify any and all aspects of the request for any method
- Maintains backwards-compatibility with existing HTML4 forms and HTTP method conventions
- Allows query parameters for PUT and POST for resource targeting and non-representational intent
- Allows GET or other action methods to include embedded digital keys for capability-based security
- <input> and <output> elements can define header fields configured using any input type, validation or calculation
- Use of underscore prefix "_" for payload states uses the familiar conventions of browser context targeting while also retaining scope for further specification possibly in integration with UriTemplates or other name-based templating technologies
- Mailto forms can construct messages with multiple recipients and have full control over all email headers and the body contents without limitation from intent tunneling through HTTP methods
- All submittable elements have a “disabled” state allowing explicit exclusion of values used by documents for user communication or input capture from being mandatory in the request or generated "data:" representations
Form Control Fields
- Form control fields re-use existing conventions for triggering custom User Agent request-generation behaviour
- HTTP Authentication in forms bypasses the unfriendly browser popups and allows site controlled, familiar and flexible CSS user interfaces
- Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache with server notification
Submittable <output> Element
- Client-side calculations do not need to be dependent on identical server-side implementations which otherwise introduce client-server coupling
- Calculations over user inputs can be applied to construct complex header values
- Decouples input capture from data use or representation
Async Submission Attribute
- Asynchronous requests enable rich 'webapp' style documents without imposing procedural construction or limits to scriptless clients
- 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 is 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
- 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 may be applied by User Agents as with requests 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 being 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 new form control fields to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.
- Bug 10671 - consider adding support for PUT and DELETE as form methods 
- ISSUE-195: Enhance HTTP request generation from forms 
- XMLHttpRequest 
- Hypertext Transfer Protocol -- HTTP/1.1 
- HTTP Authentication: Basic and Digest Access Authentication