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

Re: #445: Transfer-codings

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 9 Apr 2014 10:47:53 +1000
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <A46B956E-5FC2-4F5D-844E-785C16EAF42F@mnot.net>
To: Matthew Kerwin <matthew@kerwin.net.au>

On 4 Apr 2014, at 4:52 pm, Matthew Kerwin <matthew@kerwin.net.au> wrote:

>> Also, how should a recipient handle a stream that has DATA frames with different values for encoding?
> 
> By decoding each as it arrives, the same way it would handle a stream with the same encoding every frame. Two gzip'd frames don't add together to make one big gzip file.

One of the useful attributes of HTTP transfer-codings is that intermediaries who want to avoid re-compressing a stream's payload can do so when both sides support compression, by simply passing it through.

I.e., if we have:

[ client ] ----( hop A: HTTP/2 )----> [ proxy ] ----( hop B: HTTP/1.1 )----> [ origin ]

... and all parties support compression, the proxy really doesn't want to have to re-compress messages because we decided to make compression frame-by-frame in HTTP/2, whereas it's message-by-message in HTTP/1.1.

Isn't it much more likely that intermediaries will actually implement this if they can do that form of pass-through?

Cheers,

--
Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 9 April 2014 00:48:17 UTC

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