Re: LANG: Binary Format Final?

Brian Behlendorf ([email protected])
Sun, 12 Mar 1995 17:23:04 -0800 (PST)


On Sun, 12 Mar 1995, Len Wanger wrote:
> Also, Gillespie Brandon James wrote:
(actually, I 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.

HTTP browsers rely on file name extensions only when they don't have that
information in the HTTP headers - for example I could make a link to
http://host/file.mpeg.gz and if I sent the HTTP header "Content-type:
text/html", it'll render it as HTML without trying to gunzip it. If a
web browser accesses an FTP site, then it does file extension guessing
because it doesn't have that information, so that's the only situation in
which defining a content type for compressed VRML is conceivably
necessary.

The HTTP headers aren't a part of the file that comes back, they appear
before the beginning of the data and only make sense in the context of the
transaction - if your browser wants to save http://foo/world.wrl.gz as
world.wrz locally that's fine. If the issue is one of putting compressed
.wrl files as .wrz on a web server running on an operating system which only
allows 8.3 filenames, then the server is told "all .wrz files are compressed
world/vrml" and you're fine.

So again, a separate MIME type isn't needed.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
[email protected] [email protected] http://www.hotwired.com/Staff/brian/