From W3C Wiki
< User:Cjones
Revision as of 16:33, 27 June 2012 by Cjones (Talk | contribs)

Jump to: navigation, search

ISSUE-195: Enhance HTTP request generation from forms


This is the proposal for the enhancement of forms in integration with the HTTP protocol and the ability for forms to generate entire requests through declarative HTML markup, without requiring javascript. This proposal includes the following set of changes:

  • Form can initiate any protocol request method
  • Submittable elements can bind to protocol action, headers or body request payload
  • Output element enabled for form submission allowing clients to send the results of UI calculations in a request
  • Declare HTTP authentication within forms enabling custom login\logout forms using standard input controls
  • Declare asynchronous UI requests enabling single-page 'webapp' style documents for code-on-demand clients


The HTML Working Group is chartered to deliver HTML5 as "A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web". With HTTP being the transfer protocol of the web and with forms being the semantic markup of protocol interaction for users, completing integration with the protocol is one of the core deliverables for HTML5 and one of the progressive enhancements to the language which will the benefit of the largest numbers of users, authors and developers.

The support for the additional HTTP methods "PUT" and "DELETE" was introduced in HTML5 to cater for the demand from authors to declare interaction with web services which leverge the guarentees and protections affored to different method semantics. The initial specification of this functionality did not address the necessity to be able to control protocol mechanisms such as ETags for these methods to be useful. This resulted in the opening of a bug report questioning the removal of this functionality citing a lack of workable use cases.

This proposal is the culmination of the subsequent research and development of the working group into the requirements and necessary design of the solution as constrained by maintaining logical compatibility with HTML4 and with strict adherence to the specification of HTTP, HTTP Authentication and with reference to XmlHttpRequest which has enabled the benefits of protocol integration for the javascript environment.

Form Method

  • The form @method attribute is extended to allow any value as the name of the HTTP request method, with the exception of the following list of explicitly prohibited blacklist methods:

This allows authors to declare user interaction with web services which use the different HTTP/1.1 methods to manipulate resources. The HTTP protocol includes the methods "PUT" and "DELETE" which are idempotent and impose guarantees that multiple identical requests will have the same effect as a single request. This protocol feature is the essential network programming paradigm of optimistic locking which solves the problem of coordinating resource modification in distributed systems which asynchronously alter remote state. As with any layered system, it is possible to replicate this functionality within a higher layer, however these implementations are application specific and need to be designed and implemented for each new application within the layer and forgoes the benefits that come with a lower-level implementation and the reduction of complexity of the layered deferment of responsibility.

The extension of the @method attribute does not limit the values which may be entered to only those methods defined in HTTP/1.1 allowing extensions and new protocols to be integrated within HTML without need for additional specification. This benefits the HTML language by removing the need for the set of allowable methods to be controlled and administered by the working group and allows innovation to proceed unencumbered from the process of specification publication and implementation. This directly benefits the communities of users who have extended HTTP for additional use cases, for example the "PATCH" extension which is used for partial resource modification where an otherwise identical request would have a different consequence.

The blacklist of prohibited methods is added as a security mechanism to protect users from initiating HTTP requests which are incompatible or insecure for a HTML client. The "TRACE" and "TRACK" methods are used in HTTP for debugging protocol requests and echo otherwise restricted protocol information back to the client as response content which is accessible from javascript.

Payload Binding

  • The @payload attribute is added to each of the submittable elements:
  • The @payload attribute consists of a set of enumerated values for targeting different areas of the generated request:

This attribute enables declarative configuration of the entire request through any submittable element. Without this support the types of requests which are capable of being constructed by forms is limited to either exclusively binding all values to the action URI as a set of query parameters for GET requests, or binding all the values within the request's body for POST requests. This is a limitation of the declarative expressiveness of forms and the ability for authors to declare interaction with web services which utilize HTTP headers or alternate combinations of URI and body request configurations.

The ability to configure HTTP headers is a primary requirement for supporting the semantics of the state changing idempotent HTTP methods. These methods use HTTP headers for communicating the version of the resource as an optimistic lock token for concurrency control. This provides in-built protocol protection for end users against the risk of concurrent modification which is an inherent problem for any stateless communication protocol.

The design of the @payload attribute has been found thorough investigation of the requirements and analysis of the potential solutions. A number of alternatives were considered which initially proposed to deliver the goal of providing declarative HTTP headers, however all of which have failed to solve the issue and offer the kind of expressiveness and functionality as exhibited in the final design. Each of the following alternatives was considered and resolutely thrown out for being incapable of supporting a primary use case:

  • Form attributes for headers names
    • Too many and requires explicit specification
  • Form attribute @header-*
    • Not integrated with user input or other submittable elements
  • Input name="__header__"
    • Entire header name\value pair would need to be captured within the input @value attribute
  • Input type="header"
    • Can not capture different input types, eg: number, time, url

The final solution uses a new attribute which is added to each of the submittable elements. This allows any submittable element to target any area of the request and especially benefits the requirements of web services which use unique tokens for session identification or validating the authenticity of requests, for example CSRF tokens. The implementations of these tokens can take the form of URI query parameters, HTTP headers, or encoded body parameters, however without adequate payload request binding the ability to implement these solutions invariably causes contentions in system design through the exclusivity of HTML4 request binding.

The introduction of the @payload attribute has additionally been deliberated with the alternative potential of providing the additional functionality within the existing @target attribute on submission elements. At first there appears a good semantic fit between the attribute name and the 'targeting' of different areas of the request, and as the scope for @target is restricted to forms and 'submit' inputs\buttons for referring to reserved or named browsing contexts, there would appear to be no overlap in functionality. All that would be required is the extension of the @target attribute to allow the additional reserved payload names. However, as it would be valid for a submit button to both declare the target context of the response and configure the payload of the button name in the request, the attribute definition would need to be extended to a multi-value text attribute with the resulting additional complexity that this would introduce. For this reason, and to leave open scope for extension to either the @payload or @target attributes in future, the chosen implementation for this functionality is the new attribute.

Submittable <output>

  • The <output> element is added as a submittable form element.

The <output> element represents dynamic calculations over <input> and <output> values controlled by the client. These values must be available to be sent to the server otherwise there is a direct coupling between the client and server; the server would have to have pre-existing knowledge of the exact algorithm used by the request's client to be able to acquire the same result. This is brittle and does not cater for the scenario where there are multiple or 3rd party client implementations which communicate with a common web service.

The results of <output> are also useful in constructing a value from multiple or complex input sources. The value may be programmatically defined and then bound to target the request payload, for example:

	<form oninput="elements[''].value = a.value + '; ' + parseFloat(b.value)">
		<input type="text" name="a"/>
		<input type="range" name="b" min="0" max="1" step="0.1"/>

		<output name="" payload="_header"/>

		<button type="submit">Submit</button>

In order to generate the following HTTP header from user input:	SomeText; 0.1

HTTP Authentication

  • The form control fields "_user_" and "_password_" representative of the named parameters to the XHR "open()" method are added for declarative HTTP authentication using form inputs.
  • The "_logout_" form control field is added for clearing an origin's HTTP authentication on successful completion of the form request.

HTTP Authentication has been traditionally provided within HTML browsers through native platform support whereby if a request is issued which requires authentication the browser initiates native UI controls allowing the user to enter their login credentials and resend the initial request. This has several drawbacks to not only require 2 requests to satisfy the intent but also the interface for supplying credentials is outside the control of the web site and can not be styled or customized which creates a jarring user experience and has proven to be difficult for users to understand and trust. Once a user has initiated HTTP authentication on a site there is currently no method available by either declarative or imperative programming for a site to clear the browser's authentication cache which is applied to requests to the site. This lack of 'logout' support leaves users with open authentication for the lifetime of their browser application denying an essential use case and potentially exposing the user to additional risk of CSRF attacks.

The primary requirement for remedying these shortcomings and improving security on the web is for HTML to control the initiation and scope of authentication. The solution must allow for credentials to be supplied using form input controls to allow for sensitive data to be captured using password fields. The solution must also allow these credentials to be potentially captured and applied for any request, as these are the semantics of HTTP authentication as controlled through the application of HTTP headers and valid for inclusion on any request.

The method for delivering this functionality is by extension of the set of form control fields to include the new reserved names outlined above. Form control fields are used within HTML to declare customizations to the form submission process applied by the browser. Existing control fields are "_charset_" and "_isindex_" which redefine the submission process by configuring the character encoding or form data set respectively. This behavior is aligned with the functionality required for supporting protocol authentication as a form submission customization and, as credential information is not sent in the payload of the request, using special input names is not restrictive and serves to protect authors against inadvertently leaking sensitive data.

The "_logout_" form control field is also used to control the form submission process. This reserved name may be applied to an input control to declare that the browser should clear the origin's authentication cache on a successful response from the server. When constructing and sending the request the browser applies any existing authentication state within the request so that the server has knowledge of which user the request is from and can clean up any remote session-based state it may be retaining. This is strictly not required by the HTTP protocol or HTTP authentication which are stateless, however there are practical benefits to retaining some state across requests on a server and the request notification also serves to remove any session-style cookies from subsequent client requests. The authentication cache is only cleared by the browser on a successful response to cater for potential error conditions originating from either the client or the server and to allow the site to define the location and content of the response.

Asynchronous Requests

  • The “async” boolean attribute is added to <form>, <input> and <button> elements for toggling between synchronous and asynchronous UI form submission.

The addition of the "async" submission form attribute is functionality currently available to XHR scripting and allows AJAX style requests to be declared from HTML markup. The default operation is retained as a synchronous UI operation where the request's response is processed and rendered within the targeted browsing context. Asynchronous operations are processed within a background thread by the browser and the response is passed to the target context through calling the "onresponse" event with the result. The event adapter can then update the browsing context's DOM with the nature of the response without causing document refresh or location change.

This affords to HTML documents the ability to declare structural page controls within the document yet to have the kind of user interfaces which would otherwise have to be transcribed through javascript and XHR.

Form Submission

  • The form submission process is defined by the resolved scheme of the form's action
  • The form action URI is constructed through applying all submission elements with resolved payload "_action"
  • The form header set is constructed through applying all submission elements with resolved payload "_header"
  • The form data set is constructed through applying all submission elements with resolved payload "_body"
  • The mailto scheme algorithm is upgraded to allow configuration of action, headers and body
  • The javascript and ftp schemes are not supported due to lack of use cases

The form submission process is required to be updated in order to support the logic of the declerative controls. The existing process currently attempts to force all protocol interaction in forms to either a logical "GET" or "POST" operation. This exhibits the most basic support for any state-changing protocol in reducing the mode of operation into either 'read' or 'write' operations, however the only supported protocol which this can even apply to is HTTP. The current approach of defining a method-based switch over the submission process is flawed in its attempt to define a HTML-only protocol abstraction layer.

The "mailto" and "data" schemes both serve a single purpose which is the capture and construction of a request representation. Due to the lack of expressiveness for controlling the form data set, the "mailto" scheme is defined to switch the construction set to configuring either the mailto headers or the body based on the resolved @method state. This switch has no semantic meaning and does not make sense when the method of operation remains the same. The "data" scheme is also defined with alternate operation based on the state of the @method attribute, this operation is defined as either a navigation to the action URI for a "GET" method, or as the construction of the URI from the form data set which the browsing context is then navigated to. The mode of operation for "GET" methods serves no purpose as the only form attribute used in the resulting request is the unmutated @action attribute.

The schemes "javascript" and "ftp" both also suffer from this lack of functional capability. These two schemes only support the "GET" method and neither of them constructs any data set representing a request. The ability to navigate to ftp or javascript URIs is possible through standard HTML anchors which satisfy the use cases for their access.

The form submission algorithm is therefore changed to be defined more naturally by the scheme of the resolved form @action URI. This eliminates the confusion arising from the re-purposing of an otherwise distinct attribute definition. This simplifies the process itself by keeping protocol specific behavior defined within an independent algorithm which is free to define the logic required.


The design and of HTML5 forms stems from the same requirements which spurred the creation of the XmlHttpRequest javascript interface for providing access to the HTTP protocol. When XHR was introduced to the browser environment the background operation of the scripts together with DOM access and the shared 'ambient authority' of authentication and cookies within browsers combined to open new security vulnerabilities for normal web users. At the time, this resulted in a large amount of FUD around the causes of the vulnerabilities and the protections required to mitigate against these new risks.

One of the erroneous judgements at the time was that different HTTP methods are more or less secure than others. As PUT and DELETE are state changing methods, and as they were not previously available within the environment, the were incorrectly categorized as "unsafe" for the web and have since been treated with skepticism and concern arising from this initial uncertainty. The POST method is also a state-changing method and arguable more "unsafe" from the perspective of the protocol due to the lack of resource state protections and the ability for a single intent to be applied multiple times due to network or user error.

The vulnerability of Cross Site Request Forgery (CSRF) was identified which allowed 3rd party sites to use the 'ambient authority' available within a user's browser to impersonate user intent and initiate nefarious requests for the purposes of violating user privacy and resource security. As the primary threat is with communication with non-origin sites, yet because GET and POST requests are unrestricted in terms of origin, a half-baked restriction is imposed limiting other methods with a same-origin policy. This does nothing to protect end users as they are still fully susceptible to attacks which use POST or even GET methods to steal user data. The protocol method is irrespective from the goals or capability of a hacker to transmit state from one machine to another.

Regardless, the Cross-Origin Resource Sharing (CORS) specification has been developed in answer to the need for the World Wide Web to operate the way it was designed. This allows any site to link to and define interaction with any other site on the web and to make that interaction available for users. The need and implementation of this are irrespective to the definition of HTML forms and this proposal does not introduce a requirement mandating the support of XHR, CORS, HTTP Authentication, Cookies or any other specification.

The specification of HTML does not impose requirements on implementations to support other specifications or mandate the inclusion of secondary features. This may not be immediately obvious when the primary audience is the main browser vendors which implement their products as the combination of multiple web specifications and internet protocols which inter-operate to provide a highly integrated operational environment. However, the scope of HTML is limited by a separation of concerns and this separation serves to allow for the simplest implementation to be a conformant one and without assumptions as to how it operates or who it is for.

For example, we can look to the use cases of public access terminals to provide validation of this postulation. These implementations provide a client environment for public access where user interaction is a potential threat from the perspective of the service provider. By implementing a simple HTML client which does not run javascript, does not have multiple tabs, does not support HTTP authentication, does not support HTTP cookies, this provider is capable of supplying a product which is fully conformant with the HTML specification and guaranteed the level of support defined but without the additional risks and complexity involved with such a combined solution.

It is for these reasons that this proposal does not introduce new dependencies or unduely constrain the required operation of implementations. Vendors are free to define the standards and specifications which their products support and are free to choose which combinations of these provide the environment for serving their target user base.

Counter-Proposal Responses

The following is the set of responses documenting the answers to concerns raised by the issue's counter proposal.

Lack of Provided Use Cases

...does not give use cases for each HTTP verb it proposes to allow in method="" 

The ability to control request generation is defined to be unlimited in what methods may be used and how the payload is constructed. 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 body content may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of flexibility 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.

We can see the explicit need for supporting the additional HTTP verbs from both the stated demand of the community and the resulting workaround and hacks which have been implemented in order to circumvent their omission. These workarounds take the form of using a "X-HTTP-Method-Override" attribute as either a HTTP header or hidden form field which triggers the alternate processing semantics within the web service. As noted within the rationale above, while these workarounds allow for the methods to be triggered, they do so without support on the protocol level effectively eliminating their practical usefulness.

...but theoretical purity is at the bottom of our Priority of Constituencies. 

The main beneficiaries of these enhancements are end users, authors and developers who are empowered with the exposure to the transfer protocol of the web for the technological benefits, guarantees and protections the protocol affords. This represents real practical gains over what is currently possible.

The perception of puritanical motives for these enhancements is no doubt sourced from the many active debates arising from recent revisiting of the ReSTful architectural style which was used in the design of World Wide Web. This debate has little to do with HTTP and is more the concerned with the application of the style itself to the architecture and design of systems implemented on top of the protocol.

As we refer to the HTML Design Principles themselves, it should be noted that the changes proposed herein demand the attention and weight of highest order due to the costs and difficulties their omission would otherwise cause:

In case of conflict, consider users over authors over implementers over specifiers over theoretical 
purity. In other words costs or difficulties to the user should be given more weight than costs to 
authors; which in turn should be given more weight than costs to implementers; which should be given 
more weight than costs to authors of the spec itself, which should be given more weight than those 
proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for 
multiple constituencies at once.

Complexity of Change

The Enhance HTTP request generation from forms Change Proposal describes a complex set of features to 
be added to HTML forms. It's hard to get these details right; Gecko had an implementation of PUT and 
DELETE for <form> that was pulled just before the release of Firefox 4 due to this.

The set of changes contained herein represent the results of critical review over the specification of forms from the expert domain knowledge of architects and designers of HTTP web services. While the changes included may appear to be complex, they represent the reduction of the problem down to the core set of requirements necessary for satisfying these needs. With the requirements for specification being defined by HTTP, there exists the clear and immutable set of constraints for specification to occur and for implementations to be tested.

The implementation of PUT and DELETE within Gecko has been the source of validation from calls for the removal of these methods. If we look into the bug report however we see that the broken implementation was around the handling of HTTP redirects, also affecting any requests generated from XHR. There is a misconception that there is additional complexity in handling requests based on what generated the request, this is a fallacy. It is equally possible for forms and XHR to generate identical requests and the resulting responses are mandated within HTTP to be processed identically by the UA as any identical representation would.

The changes to the form submission algorithm represent the only source of complexity within this proposal, and that complexity is limited with impact only to browser implementers. The new form methods, payload attribute and authentication control fields are all simple element and attribute definitions which do not consist of confusing behavior changes or overt dependencies on sibling elements. On the contrary, the simplicity of the design allows the new element definitions to complement one another resulting in conceptually simple and powerful declarative expression.

The complexity within the submission algorithm is solely based on the HTML4 implementation of HTTP request binding for GET and POST methods. This binding is based on the resolved form method to target the action or body of the request with form parameters. With the introduction of payload binding configuration this algorithm is naturally extended, however the need to maintain backwards compatibility with HTML4 documents and to support the default semantics of HTTP require the form's method to be used to define the default binding for elements which lack an explicit deceleration. This takes the form of providing a special form submission condition for implementations and represents the greatest complexity introduced by this proposal and that which is irreducible.

Lack of UA Implementor Interest

A solicitation of UA implementor interest from the Editor has gone unanswered for a month. Moreover, the spec
allowed PUT and DELETE in <form method> for years. They were dropped after the failed Gecko implementation
mentioned above.

The solicitation for UA implementor interest was posed by the editor and remains unanswered. This not only shows a lack of positive interest but also a lack of negative objection and no conclusions can be drawn from silence. Given that when PUT and DELETE were within the specification there were initial implementations happening within Gecko, this would seem to indicate that there is interest by some vendors to support these users.

The design of these changes is modeled on existing operation available within XHR and does not introduce any new functionality not in this interface. For these changes to be implemented the form is logically required to be 'mapped' into the same data structure as provided through XHR. This is a simple and limited programmatic task and given the convergence of these two input structures into a single protocol call this is expected and designed such that implementations can refactor and combine these inputs into a single programming construct.


Form Method

  • Update the valid state for "method" and "formmethod" content attributes to be any value excluding the HTTP methods defined by the following enumerated blacklist:

Payload Binding

  • 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

Submittable <output>

  • Add the <output> element to the list of submittable elements and enable it for inclusion in the construction of the form request set

HTTP Authentication

  • Add the following special values to the list of restricted values for form element's "name" attribute in section " Naming form controls":
   _user_, _password_, _logout_
  • Add the definition of the "_user_" special form control on a Text control as the value and behavior of the XHR authentication parameter "user"
  • Add the definition of the "_password_" special form control on a Password control as the value and behavior of the XHR authentication parameter "password"
  • Add the definition of the "_logout_" special form control as the value to require the UA to clear site authentication on successful response.

Asynchronous Requests

  • 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 "onresponse" event type which is triggered by receiving the request's response containing event data representing the response

Form Submission Process

  • Remove the definition of the FTP and javascript schemes from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of these scheme offers nothing over its declaration and use within a HTML anchor.

Form Data Set Construction

  • 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" or with unset attribute and the resolved HTTP method state of HEAD, GET, OPTIONS or DELETE.
  • 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" or with an unset attribute and the resolved HTTP method state of PUT, POST, PATCH or unknown method.
  • Update the form submission algorithm by removing the scheme method abstraction table and replacing it with a scheme switch to sections defining the specific set of processing instructions

HTTP(S) Scheme Submission Process

  • Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:
  1. For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters
  2. 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
  3. 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
  4. 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
  5. Construct the request using the HTTP(S) method defined by the submitter element's resolved "method" attribute state.
  6. Send the constructed request as either a synchronous or asynchronous request as defined by the submitter element's resolved "async" attribute state.
  7. 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.

Data Scheme Submission Process

  • 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:".

Mailto Scheme Submission Process

  • 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


Positive Effects

Form Method

  • Declarative specification of HTTP web services within the HTML language
  • Enables HTTP web services for scriptless clients and environments
  • Simpler visible programming, comprehension, 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

Payload Binding

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

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

HTTP Authentication

  • Form control fields re-use existing conventions for triggering custom User Agent request-generation behavior
  • 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

Async Submission Attribute

  • Asynchronous requests enable rich 'webapp' style documents without imposing procedural construction or limits to scriptless client environments

Negative Effects

  • The introduction of payload targeting introduces a more complex form request generation algorithm for implementors, however backward compatibility is maintained and there is explicit provisioning for the reduction if implementation code through refactoring
  • 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' and an increasing common usage pattern within modern sites

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


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


Acknowledgements and thanks go to the following people for their efforts which have contributed to this proposal:

  • Julian Reschke
  • Mike Amundsen
  • Dave Kok
  • Ian Hickson
  • Anne Van Kesteren
  • Ted O'Connor
  • HTML WG Chairs: Sam Ruby, Paul Cotton & Maciej Stachowiak


  • 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]
  • Gecko Bug 583288 - Authorize PUT and DELETE methods for form submission [6]