- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 13 Nov 2007 15:46:17 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Brian Kell <abodeman@yahoo.com>
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 UTC