- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 9 Apr 2014 10:47:53 +1000
- To: Matthew Kerwin <matthew@kerwin.net.au>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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