Re: Any objections to "Accept-encoding: gzip, *;q=0"?

I realize that some people were opposed to the introduction of qvalues
on Accept-Encoding.  However, during today's editorial-group discussion
of the CONTENT-ENCODING issue, we realized that the syntax for the
various Accept-* request headers in RFC2068 is almost, but not quite,
uniform, and we reached a tentative agreement that it might be a good
idea to have all of the Accept-* request headers (Accept-Range is a
response header) have similar syntaxes.

Anyway, here are the BNFs in question, from RFC2068:

    14.1 Accept

          Accept         = "Accept" ":"
                           #( media-range [ accept-params ] )

          media-range    = ( "*/*"
                           | ( type "/" "*" )
                           | ( type "/" subtype )
                           ) *( ";" parameter )

          accept-params  = ";" "q" "=" qvalue *( accept-extension )

          accept-extension = ";" token [ "=" ( token | quoted-string ) ]

    14.2 Accept-Charset

          Accept-Charset = "Accept-Charset" ":"
                    1#( charset [ ";" "q" "=" qvalue ] )

    14.3 Accept-Encoding

          Accept-Encoding  = "Accept-Encoding" ":"
                                    #( content-coding )

    14.4 Accept-Language

          Accept-Language = "Accept-Language" ":"
                            1#( language-range [ ";" "q" "=" qvalue ] )

          language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

The CHARSET-WILDCARD issue, already declared "closed", changes the BNF
for 14.2 (Accept-Charset) to include "*", based on
    ftp://ds.internic.net/internet-drafts/draft-holtman-http-wildcards-00.txt
so that the BNF there is now:

          Accept-Charset = "Accept-Charset" ":"
                    1#( charset [ ";" "q" "=" qvalue ] )

Henrik's proposed solution for CONTENT-ENCODING, at
	http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0038.html
would modify the BNF for 14.3 (Accept-Encoding) to be

       Accept-Encoding  = "Accept-Encoding" ":" 
                                 #( codings )
        codings          = ( content-codings | "*" )

As you can see, there are only two non-uniformities remanining
among these four sections:
	(1) The Accept header allows extension parameters, not
	just qvalues.
	(2) The Accept-Encoding header does not allow qvalues.

I'll also note that RFC1945, while not defining qvalues, does say:

    D.2.3 Accept-Encoding
    
       The Accept-Encoding request-header field is similar to Accept, but
       restricts the content-coding values which are acceptable in the
       response.

I.e., there seems to have been an intent that Accept-Encoding
be similar in form to Accept, and (perhaps) that the omission
of a qvalue here was simply an oversight.  (Note that RFC1945
explicitly allows "*/*" in the Accept header, so it implicitly
allows "*" in the Accept-Encoding header, and so I think we
need to include "*" in the Accept-Encoding header simply for
compatibility with RFC1945.)

As I said in my previous message, introducing qvalues for
Accept-Encoding won't work "if any existing servers or proxies would
choke on a qvalue in an Accept-Encoding header."
But (so far) nobody has asserted than this is an actual problem.

-Jeff

Received on Tuesday, 22 July 1997 16:43:56 UTC