HTTP ACCEPT field and MIME types

• Mail folder: WWW Talk Apr-Jun 1993 Archives
• Next message: Marc Andreessen: "Mosaic 1.1 prerelease 2 available for testing"
• Previous message: Bill Janssen: "Re: Re STRONG, B, I, and U"

Message-id: <9306011953.AA05939@eitech.com>
X-Sender: weber@eitech
Date: Tue, 01 Jun 1993 12:59:32 -0800
To: www-talk@nxoc01.cern.ch
From: weber@eitech.com (Jay Weber)
Subject: HTTP ACCEPT field and MIME types
X-Mailer: <PC Eudora Version 1.1a5>

I was looking through a draft HTTP 2.0 spec (may be as old as 7-Dec-92)
and noticed a potential problem with the ACCEPT request field.  One puts
a comma-separated list of MIME types as the field value.  The problem is
that MIME types can involve parameters, and some parameters may be
crucial to a client's acceptance of the type.  For example, an old
example from the MIME spec is:

                 Content-Type:  application/octet-stream;
                      name=foo.tar.Z; type=tar;
                      conversions="x-encrypt,x-compress"

This example is extreme, since application/octet-stream is usually a
no-brainer for clients, but the presence of these parameters makes it
pretty UNIX specific.  You can image other examples, such as a "lossiness"
parameter on image/jpeg, that would impact portability of the type.

Anyway, if we include parameters in MIME typing, then a comma-separated
syntax doesn't work too well.  An easy fix would be to allow multiple
ACCEPT fields in the header, with one MIME type per field.  I don't see
an HTTP stance on multiple fields, and this treatment of multiple
fields would be consistent with RFC 822 (the To: field, for example).
How about it (Tim)?

In general, HTTP 2.0 is pretty cool.  Is an RFC coming soon (or here)?

Jay Weber
EIT