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
compressed.
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
generallyunreadablebinarydata...
-- George