- From: David Morris <dwm@xpasc.com>
- Date: Mon, 31 Mar 2014 13:56:41 -0700 (PDT)
- To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
In the future, please use some form quoting ... this would have been impossible to parse if I didn't recall the earlier message. Reply below ... On Mon, 31 Mar 2014, K.Morgan@iaea.org wrote: > I suggest the following based on the exact wording from rfc 2616 14.3 > rule #4 ... > > The "identity" and "gzip" content-codings are always acceptable, unless > specifically refused because the Accept-Encoding field includes > "identity;q=0", or "gzip;q=0" respectively, or because the field > includes "*;q=0" and does not explicitly include the "identity" or > "gzip" content-codings respectively. If the Accept-Encoding field-value > is empty, then only the "identity" or "gzip" encodings are acceptable. This wording introduces the possiblity of no valid Content-Encoding without specification of the error handling. If we are to allow suppression of the gzip choice, we can't end up with the null case. Perhaps along the lines of ... The "identity" and "gzip" content-codings are always implied as acceptable when the Accept-Encoding header is omitted or empty valued. If the Accept-Encoding field is included it will specify encodings acceptable to the client.
Received on Monday, 31 March 2014 20:57:10 UTC