Re: Toward Closure on HTML

weber@eit.COM (Jay C. Weber)
Date: Wed, 6 Apr 1994 01:10:12 --100
Message-id: <9404052308.AA22981@eit.COM>
Reply-To: weber@eit.COM
Precedence: bulk
From: weber@eit.COM (Jay C. Weber)
To: Multiple recipients of list <>
Subject: Re: Toward Closure on HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1631

> From: (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

> From: (William M. Perry)
> How should multipart/www-form be defined?
> Content-types for each input area?

Here's an example along that line:




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.

Content-id: lastname

Content-id: firstname


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?