Ah... I hated the <INPUT TYPE=FILE> proposal, but I've been noodling
on your application, and now that you phrase the question this way, a
lightbulb just went off and I can see how I think it could work...
Let me preface this by saying that I still haven't made a complete
study of WWW forms -- for the HTML 2.0 spec, we did a cut-and-paste
job from the HTML+ spec and we consulted the NCSA doc a little. Since
then, several people have told me it's wrong, but nobody's provided a
replacement spec.
Anyway, that said..
I wonder if you could use the ENCTYPE attribute of the FORM element
to express what you're interested in...
My current revision of the html.dtd,
$Id: html.dtd,v 1.16 1994/06/13 20:55:50 connolly Exp $
includes the following:
<!ATTLIST FORM
ACTION %URI #REQUIRED
METHOD (%HTTP-Method) #IMPLIED
ENCTYPE %Content-Type; #IMPLIED
>
So it is possible to express the content-type of the submitted
information. From the NCSA doc, I see:
From: http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/fill-out-forms/overview.html :
ENCTYPE specifies the encoding for the fill-out form
contents. This attribute only applies
if METHOD is set to POST -- and even then, there is only one
possible value (the default,
application/x-www-form-urlencoded) so far.
While this doesn't really give you the full expressive power of
a set of Accept: headers, you could:
1. Restrict your applications to one content type,
possibly using the "text/*" convention.
2. Hack and wedge more stuff in the ENCTYPE attribute
3. Propose a new attribute or a subelement of FORM that
gives the full expressive power of Accept:
4. Punt the idea of sticking the Accept: info in the
document, and have your client use a HEAD request
to find out what forms of data are acceptible. This has bad
performance implications for clients that want to change
the user interface based on the acceptable content types.
>Personally, I like putting them in the form if only so that you could
>mail someone a form rather than always deliver it to them via http...
This proposal is happy in that respect.
>For example, if this were a fax service, it could Accept: text/*,
>application/postscript, image/* (but not, say, audio/*); if it were a
>answering-machine application, it might accept only audio/*.
To express these examples (using choice 2 above), you might use:
<FORM ACTION="http://faxserverhost/faxinput" METHOD="POST"
ENCTYPE="text/*, application/postscript, image/*">
Please submit your fax data.
<INPUT TYPE=SUBMIT>
</FORM>
<FORM ACTION="http://ansmachhost/audioinput" METHOD="POST"
ENCTYPE="audio/*">
Please submit your message.
<INPUT TYPE=SUBMIT>
</FORM>
The client would, of course, have to recognize the ENCTYPE="..."
and modify the user interface accordingly.
Dan