Re: h2#404 requiring gzip and/or deflate

> On Mar 31, 2014, at 22:59, "dwm@xpasc.com" <dwm@xpasc.com> wrote:
>> 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. ...

This wording is practically identical to the wording in rfc 2616. The same thing could happen in HTTP/1.1 if you only sent "identity;q=0" or "*;q=0". The error handling for the null case is mentioned in rfc 2616 section 14.3 right after rule number four. I was under the impression that the rules from http/1.1 still applied unless explicitly stated otherwise. Otherwise you basically have to copy the whole thing.

> 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.
>

This is essentially option #2 I proposed earlier.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Monday, 31 March 2014 21:20:46 UTC