I think its preferable to stick to the accepted conventions for gzipped
file naming, the gzip documentation (gzip.info) says:
`gzip' reduces the size of the named files using Lempel-Ziv coding
(LZ77). Whenever possible, each file is replaced by one with the
extension `.gz', while keeping the same ownership modes, access and
modification times. (The default extension is `-gz' for VMS, `z' for
MSDOS, OS/2 FAT and Atari.)
.
.
.
If the new file name is too long for its file system, `gzip'
truncates it. `gzip' attempts to truncate only the parts of the
file name longer than 3 characters. (A part is delimited by dots.)
If the name consists of small parts only, the longest parts are
truncated. For example, if file names are limited to 14 characters,
gzip.msdos.exe is compressed to gzi.msd.exe.gz. Names are not
truncated on systems which do not have a limit on file name length.
Also, you shouldn't have to worry about compatibility with most of the
other compression schemes. From the same document:
`gunzip' can currently decompress files created by `gzip', `zip',
[Unix] `compress' or `pack'.
Also, Gillespie Brandon James wrote:
> I don't think there's a need for a separate content-type - web servers
> will deliver the content with the HTTP headers:
>
> Content-type: world/vrml
> Content-encoding: gzip
I don't think this works for gzipped files. The document you get back
is binary and does not have an ASCII header with the Content-Type
flags. Why don't we support it the same way other browsers do? Both
Mosaic and Netscape will automatically decompress (gunzip) any files it
finds with a .gz or .z files they encounter.
Len Wanger -- LRW@SDSC.EDU
Project Sequoia 2000
San Diego Supercomputer Center