What farsighted tag designers we have! That's great we can just use
ENCTYPE.
> From: wmperry@indiana.edu (William M. Perry)
>
> How should multipart/www-form be defined?
> Content-types for each input area?
Here's an example along that line:
--foo
lastname
Weber
--foo
firstname
Jay
--foo--
The overhead for this kind of encoding for n text fields is
2 + (n+1)*(separator-size+3) # for separator lines
+ n # leading newlines
+ n # for post-fieldname newlines
+ 3 # miscellaneous bytes
so even though it sounds like overkill this is fairly low-overhead as
long as separators are short.
Note that I've put field names as the first line of the text/plain data;
instead we could use the content-id header, e.g.
--foo
Content-id: lastname
Weber
--foo
Content-id: firstname
Jay
--foo
so it adds n*12 bytes of overhead but works much better with more interesting
types than text/plain. (However, the MIME spec says that this are bogus
content-ids, which are supposed to me globally unique; I think that is silly
but I lost that battle some time ago.)
So do people think this overhead is too much, for simple text values?
Jay