ISSUE-195: Enhance HTTP request generation from forms
- 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
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.
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 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 @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.
- 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['VND.ExampleInc.foo'].value = a.value + '; ' + parseFloat(b.value)"> <label>Text</label> <input type="text" name="a"/> <label>Range</label> <input type="range" name="b" min="0" max="1" step="0.1"/> <label>Result</label> <output name="VND.ExampleInc.foo" payload="_header"/> <button type="submit">Submit</button> </form>
In order to generate the following HTTP header from user input:
VND.ExampleInc.foo: SomeText; 0.1
- 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.
- 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 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 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 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.
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.
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 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 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.
- 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
- 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 <output> element to the list of submittable elements and enable it for inclusion in the construction of the form request set
- Add the following special values to the list of restricted values for form element's "name" attribute in section "184.108.40.206 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
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
- 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
- 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
- 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
- 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
- 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 
- ISSUE-195: Enhance HTTP request generation from forms 
- XMLHttpRequest 
- Hypertext Transfer Protocol -- HTTP/1.1 
- HTTP Authentication: Basic and Digest Access Authentication 
- Gecko Bug 583288 - Authorize PUT and DELETE methods for form submission