W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #445: Transfer-codings

From: Martin Nilsson <nilsson@opera.com>
Date: Fri, 04 Apr 2014 15:57:09 +0200
To: ietf-http-wg@w3.org
Message-ID: <op.xdso1jo2iw9drz@riaa>
On Fri, 04 Apr 2014 07:09:08 +0200, Mark Nottingham <mnot@mnot.net> wrote:

> My personal .02 -
> Given that HTTP/1 hasn't seen much use of transfer-codings, and over the  
> years we've had them, there have only been three defined (discounting  
> chunked), spending 16 bits on this in ever data frame doesn't seem  
> justified.
> I'd much rather just have a flag that indicates 'gzip', and a  
> corresponding setting; that doesn't require any frame format changes at  
> all. If another encoding becomes necessary, it can get into a subsequent  
> version (since we've repeatedly decided to favour faster versioning over  
> broad extensibility in the non-semantic layer).

Or you can have a per data frame flag as you propose, but define the  
actual compression algorithm applied in SETTINGS.

    SETTINGS_COMPRESSION_ALGORITHM (5):  Declares the compression
       algorithm used for all data frames with the COMPRESSION frame
       flag set. The value is a 4 octets identifer where the following
       identifiers are defined.

       "gzip"  The content is encoded according to GZIP [RFC1952], with
               one compression context per stream.

       If an unknown compression algorithm identifier is encountered
       the connection must be closed with UNKNOWN_COMPRESSION error.

I'm not sure it's needed though.

/Martin Nilsson

Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Friday, 4 April 2014 13:57:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC