HTTP ACCEPT field and MIME types

Jay Weber ([email protected])
Tue, 01 Jun 1993 12:59:32 -0800

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