HTML forms and HTTP/WebDAV requests

Hi,

I would like to discuss with you the possibility of extending HTML-forms to
allow for generic HTTP requests.
As part of my PhD-research, I proposed an extension to HTML on the IADIS
WWW/Internet Conference last November in Lisbon, Portugal, dealing with this
issue. I would like to discuss this proposal with a group of experts and I
think this mailing list is the most suitable place to do so.

Currently only the HTTP methods GET and POST are allowed for the value of
the method attribute (in (X)HTML that is: XForms 1.0 adds PUT, but the
specifications are effectively still restricted to just a few), there is no
way to pass HTTP request headers from a form to a server and no request body
can be specified (only implicitly using POST). As a consequence, HTML forms
can only be used for specific HTTP queries: GET/POST(/PUT) without special
request headers.
This is an unnecessary restriction to the application domain of HTML. (Could
perhaps anyone tell me why HTML was designed to explicitly mention HTTP
methods in the first place? Were general HTTP request ever considered?)

In my opinion it would be a great improvement if general HTTP queries could
be generated using forms. Any HTTP-server could then be used using web pages
without having to resort to scripts (note by the way that scripts turn one
request into two: one for the result of the script and one for the actual
request done by the script).
Taking into account that the relatively new WebDAV protocol (an extension to
HTTP) is gaining in popularity, such a generalization of HTML forms could
enable (non-expert) users to build their own web interface to personal
repositories with relative ease. It is very likely that more HTTP-based
protocols will emerge in the near future (because of HTTP's installed base,
proven reliability and available features for authentication and proxying,
for example): for each of these protocols this restriction will be an
obstacle when web interfaces are needed.

In order to achieve generalization, I would suggest additional elements for
request-headers and the request body. Secondly, I would move the request-URI
from the action attribute to a separate element. The body element would just
be a container, as the proper way to pass content information (length,
encoding etc) is via headers (thus complying with the HTTP specification).
But at least there would be an element to specify what information should be
transferred in the request body. for those HTTP methods who use it. The
additional elements for request-URI and headers would be analogous to the
input-element, allowing users to enter values, select files or provide
static (type="hidden") values.
This would be the most flexible way (and perhaps the most consistent?) to
provide the user with freedom of design. A fourth additional element would
be needed to allow the user to provide a script he/she wants to use to
provide a layout for the HTTP-response. The current (X)HTML specification
states that the contents of the response body should be rendered: because
that would result in an empty page in case of a "HTTP/1.1 200 OK" result,
some other mechanism is needed. Hence this (what I call) "output" element
which indicates that the browser should issue a POST request to the script
provided with the value attribute with the (entire, but probably short)
initial HTTP response in the body as a parameter. Of course, leaving out
this element would imply current behavior (rendering of the result).

Using the deprecation mechanism this scheme would be backwards compatible,
as the action attribute would still be supported (but deprecated) and these
new elements would not be recognized.

So, to issue a WebDAV-Copy request using new elements <request-URI>,
<header> and <output>, the form would look like:

<form method="COPY">
  <output type="URI" value="http://some.server/cgi/copyresult.cgi">
  <request-URI type="FILE" value="">
  <header name="Destination" type="TEXT" value="">
  <input type="SUBMIT" value="COPY">
</form>

The result of hitting the "Copy" button would be that the resource the user
selects (using the file browser: type="file") is copied to the URI the user
enters in the textbox (destination type="text"), and the user is presented
with the output of the copyresult.cgi script. Note that older browsers would
not recognize the request-URI. Therefore, no resources would be affected by
possible unpredicted behavior due to the "COPY" method which is not
understood by the browser.

... and a general, backwards-compatible GET would look like:

<form method="GET", action="http://some.server/cgi/somescript.cgi">
  <request-URI type="HIDDEN" value="http://some.server/cgi/somescript.cgi">
  <input type="SUBMIT" value="GET">
</form>

Note that because the <output> element is left out, the result of the script
will be rendered in the traditional way by new browsers.

In conclusion: general HTTP requests can be done in a simple and compatible
way. We would only need the "missing" elements.
I'm not sure whether this issue has ever been discussed before on this
mailing list: I could not find related topics in the archives. If it was, I
apologize for raising the issue again (but could anyone tell me what the
conclusions were?).

Kind regards,
Frans Dondorp

(PS: For those who are interested in it: the (short) paper describing this
proposal in more detail can be found here:
http://www.isa.its.tudelft.nl/~dondorp/pdf/HTMLforms.pdf. I would appreciate
your comments on it.)

Received on Friday, 10 January 2003 07:11:12 UTC