HTTP/1.0 + MIME headers

George Phillips <>
Date: 15 Jul 93  1:03 -0700
From: George Phillips <>
To: <>
Message-id: <5975*>
Subject: HTTP/1.0 + MIME headers
Status: RO
Having just hacked at my server to better support HTTP/1.0, this discussion
couldn't come at a better time (I haven't installed the new version yet;
so no bug reports :-).

Chung Huynh said:
>Also, I prefer the BSDI's return of
>"Content-type: archive/xxx" and "Content-encoding: yyy" for an
>archive encoded file (eg: .tar.Z) rather than the "application/octect-stream".

Is "Content-encoding" a standard MIME field?  No matter, either way
I think that "Content-encoding" is a good way to say if something is

Tony Sanders said:
>I currently ignore the Accept field though I do plan to use it for format
>negotiation in the near future.  However, my feeling is that if a client
>doesn't understand the returned type it should offer to dump it to a file
>and I prefer to include the actual content-type instead of just tagging
>it application/octet-stream so the user might have a clue as to what to
>do with it.

I think offering to dump unknown content types is good browser behaviour.
It appears that an older version of RFC1341 would have made
"application/octet-stream" a reasonable response since it had some
properties for giving the user clues about the data: "type" for
the content, "name" for a suggested file name to save as and "conversions"
for information on what fiddling was done with the data (encrypting,
compressing, etc.).  But they've dropped that suggesting that
"Content-Disposition:" replace name.  I guess "Content-encoding:"
can nicely replace "conversions", but I dunno what to do with "type".
I'd suggest that we just put the real type in "Content-type" and
use "Content-Description" to describe the document and its format.

Keith Moore said:
>> $ext{'shar'}  = $ext{'SHAR'}  = 'archive/shar';
>> $ext{'tar'}   = $ext{'TAR'}   = 'archive/tar';
>New top-level types are harder to register.  There are also security
>concerns that need to be addressed.

Such a shame -- "archive" seems like a logical and useful top level type.
On the bright side, there's a golden opportunity here to define an
official shar format that can be unpacked with "sh" _and_ be undone
with a simple C program (or a short but bewildering perl script :-).

Except for "text/html" (or "application/html"), we should really be
using "x-" forms until there are official types registered, right?
So sending back a compressed tar file might look like:

Content-type: x-archive/x-tar
Content-encoding: x-compress
Content-transfer-encoding: binary
Content-disposition: files.tar.Z
Content-description: compressed tar archive of some useful files


			-- George