W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

i25 - Accept-Encoding BNF [was: Erratum in RFC 2616]

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 13 Nov 2007 15:46:17 +1100
Message-Id: <4A79E817-D188-48C3-943C-F3DA0DDAC900@mnot.net>
Cc: Brian Kell <abodeman@yahoo.com>
To: HTTP Working Group <ietf-http-wg@w3.org>

This hasn't been discussed on-list (beyond Alex agreeing that it's an  
issue), but was talked about pre-WG in Prague, where those present  
agreed with the proposal Brian makes below.

Any other thoughts? The other alternative would be to disallow empty  
Accept-Encoding headers, but IMO that's more intrusive.

Cheers,


On 02/06/2005, at 11:44 PM, Brian Kell wrote:

>
> In section 14.3, the definition of Accept-Encoding is given as  
> follows:
>
>       Accept-Encoding  = "Accept-Encoding" ":"
>                          1#( codings [ ";" "q" "=" qvalue ] )
>
> This definition implies that there must be at least one non-null  
> codings. However, just below this definition, one of the examples  
> given has an empty Accept-Encoding field-value:
>
>       Accept-Encoding: compress, gzip
>       Accept-Encoding:
>       Accept-Encoding: *
>       Accept-Encoding: compress;q=0.5, gzip;q=1.0
>       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
>
> Furthermore, the fourth rule for testing whether a content-coding  
> is acceptable mentions the possibility that the field-value may be  
> empty.
>
> It seems, then, that the definition for Accept-Encoding should be  
> revised:
>
>       Accept-Encoding  = "Accept-Encoding" ":"
>                          #( codings [ ";" "q" "=" qvalue ] )
>
> Brian Kell
> abodeman@yahoo.com
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 13 November 2007 04:49:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:23 GMT