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

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Nov 2007 15:46:17 +1100

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
> [email-masked]
>
>

--
Mark Nottingham     http://www.mnot.net/