User:Cjones/ISSUE-195

ISSUE-195: Enhance HTTP request generation from forms

Summary

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:

Rationale

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 for 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 leverage the guarantees and protections afforded 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 necessitive 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.

Use Cases

The primary use case supporting the enhancement of forms is to enable declarative capture and control of protocol request representations. The benefits of providing this support can be seen by examining the requirements of the different actors within HTML.

The principal actor is the end-user who interacts with HTML through User Agent software which provides the environment for dereferencing URIs and rendering the retrieved representations. Users have a choice of agent software based on their host environment, abilities, or preference which includes the category of User Agent defined within the HTML conformance classes as "User agent with no scripting support". This category of User Agent is limited in its operational capacity, either by implementation or configuration, to only providing a static representation of HTML documents and only providing state transitions through the request of declarativly defined links or form requests. Users operating this class of agent software can only be serviced through the inclusion of declarative controls for defining HTTP protocol representations. Without this support these users would be unable to use web sites which utilize the additional HTTP methods initiated through HTML.

User agent software may additionally be implemented, or configured through user preference, to restrict the use of HTTP cookies. This is a common configuration option by users who choose to operate an environment exhibiting greater security and privacy by means of the elimination of secondary functionality and the potential threats which these can incur. The impact of this is that these users are unable to be serviced with the use of HTTP cookies as a common means for implementing site login and session control. The HTTP protocol provides mechanisms for authentication through the use of specialized HTTP headers which are managed by the User Agent. This functionality is currently implemented within User Agents as native "popup" notification dialogs which request sensitive information and have proven to be difficult for users to trust due to the historic overuse of popups for advertising or other non-desirable user interaction. This has lead to the overwhelming use of HTTP cookies for authentication and session control as an application-defined protocol and implemented within the site's pages using standard form controls and styled within their user experience. The introduction of declarative controls for initiating HTTP authentication provides access support for users operating in non-cookie environments and provides web sites with the ability to utilize HTTP authentication without incurring a jarring user experience.

The HTTP protocol includes the state changing methods PUT and DELETE which are defined as idempotent operations providing guarantees to their operational effect. The implementation of forms within HTML4 does not include these methods and so all state changing operations are implemented by applications through the POST method. The impact of this to end-users is that any state-changing operation they perform can not be intelligently interfaced by User Agents, this manifests itself currently within browsers through the idiosyncratic behavior when users navigate using browser back or forward buttons, or in web sites which provide transactions which may have unintended consequences if submitted multiple times, in these situations popups warn the uninformed user of potential hazards. These scenarios are avoided through the appropriate use of the idempotent HTTP methods which contain the relevant information for their effect to be predicted over time and frequency alleviating users from error conditions and having to make uninformed decisions arising from low level technical details.

The use cases of HTML authors provide additional requirements on the specification of HTML and the constraints of perceived or practical authorability. With HTML being a declarative language it affords a programming language based on capturing and representing intent and is at a significantly higher level than that of Javascript and imperative programming languages which require a far greater level of intrinsic knowledge and syntactical expressional constraints. The ability for people with little or no programming experience to be able to author HTML documents with web site interaction without needing to know any Javascript is a significant advantage to producing functional and error-free applications and allows these users to learn or be taught HTML as a natural advancement from preliminary desktop publishing. The simplicity of declarative HTTP and MAILTO processing schemes affords these authors the ability to advance their abilities into the protocol level of interaction with web sites and internet operation. The exposure to this level of control, jumping the Javascript and imperative programming constraints, is a significant step for the advancement of the World Wide Web within educational institutions and alleviates the cognitive load which otherwise limits web programming to the technical elite.

The simplicity of the computational requirements for the authorability of HTML not only serves human authoring and educational use cases but also the needs of automated document generation and service interaction. The predominant method for the production of HTML documents is through the use of server-side "templating" technologies which augment base HTML documents with additional processing instructions which, when combined with request input or database entries, provide dynamically generated HTML documents. The tools which provide this functionality are based on the processing and output of the HTML language and the greater functionality that can be represented within this language as declarative expressions represents a significant benefit to the ease of production of server-side HTML. The alternative of requiring Javascript for the declaration of protocol and service interaction has far limited tooling support, is more error prone, and requires an operational environment for testing the integrity of generated code. Compare this with HTML which can be statically analyzed for integrity and does not require the construction of complex working memory and sequential and combinatorial execution of programming statements.

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:

CONNECT, TRACE, TRACK

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:

button
input
keygen
object
select
textarea

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

_action
_header
_body

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:

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 as 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.

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 declarative 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.

XHR, CSRF and CORS

The design 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.

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, HTTP 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 that 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 what purpose it serves.

For example, we can look to the use cases of public access terminals to provide validation. 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 protected and 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 the 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 specallowed PUT and DELETE in <form method> for years. They were dropped after the failed Gecko implementationmentioned 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 such silence. Given that when PUT and DELETE were within the specification there were initial implementations happening within Gecko, this indicates 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.

Details

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:

CONNECT, TRACE, TRACK

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 "4.10.19.1 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.

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:

For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters

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

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 and send the request using the HTTP(S) method defined by the submitter element's resolved "method" 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.

Data Scheme Submission Process

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

Mailto Scheme Submission Process

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

Impact

Positive Effects

Form Method

Declarative specification of HTTP web services within the HTML language

Payload Binding

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

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 of implementation code through refactoring

Conformance Classes Changes

Additional conformance defined through the the application of changes in the "Details" section

HTTP Authentication is 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 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

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

References

Bug 10671 - consider adding support for PUT and DELETE as form methods [1]