Re: Toward Closure on HTML

Jay C. Weber ([email protected])
Tue, 5 Apr 94 16:08:12 PDT

> From: [email protected] (Lou Montulli)
>
> > anchors, really; so the only alternative I see is something like
> > a FORM method=POSTMP.
> >
> There is already a way to define the encoding type. There is an
> attribute to the FORM tag called ENCTYPE that is supposed to
> specify the post content type. Right now the only valid option
> is "application/x-www-form-urlencoded" but we can easily add> mime/multipart.

What farsighted tag designers we have! That's great we can just use
ENCTYPE.

> From: [email protected] (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