* On the client end, support a FORM field which can accept input of
arbitrary MIME content (not just text/plain from the keyboard). The
most natural way would be to upgrade the behavior of TEXTAREA.
* For the POST submission, support a multipart encoding scheme that
circumvents the overhead of the current www-url-encoding for large
inputs.
Here are the main reasons I am opposed to Ernesto's proposal:
1. While it's true that the proposal would not alter the syntax of
HTTP, it would force a drastic change in the semantics: making HTTP
servers stateful, with all of the problems that entails. Thus,
during the multiple back and forth transactions would be required to
completely transmit the data in a FORM, the server would have to
somehow generate unique "transaction URLs" that allow the client to
connect back to the correct transaction, and furthermore, it would
have to manage the partial transaction data for the different clients
as it accumulates. This would also add serious complications to CGI,
(for example, requiring global script changes to handle a simple
change of field from type TEXTAREA to FILE). These are rather large
issues to stir up for one extra feature (important as it is).
2. Having a special "FILE" INPUT type deprives users of the choice
to enter small amounts of ASCII data directly into the FORM, if they
so choose. Even for small input, they would instead have to prepare
an external file with the data, and then use a file browser to
register that file with the FORM.
--------------------------------------------------------------------
Paul Burchard <burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------