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

Re: current HTTP/2 spec prevents gzip of response to "Range" request

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Wed, 26 Mar 2014 14:23:31 -0500
Message-ID: <CACuKZqGxXq_sxYwvMxjCj3UY9+xrbBaG_GhkZx2KAK2HSAOhYg@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: HTTP Working Group <ietf-http-wg@w3.org>, C.Brunhuber@iaea.org
On Wed, Mar 26, 2014 at 12:11 PM,  <K.Morgan@iaea.org> wrote:
> On Wednesday,26 March 2014 17:22, Zhong Yu wrote:
>> If a response looks like this
>>     HTTP/1.1 206 Partial Content
>>     Content-Type: multipart/byteranges,
>>     Content-Encoding: gzip
>> What does it mean exactly? Per "normal" interpretation, "gzip" is applied on the multipart.
>> This interpretation seems plausible for a reader of RFC2616. And it would be quite
>> understandable if an implementation decompress the response body first, then interpret
>> it as a multipart.
>> The new bis draft makes it clearer that "gzip" is applied on the representation and
>> "multipart" is applied on the payload, therefore the above interpretation is wrong.
>> If a response is 206 and the Content-Type is multipart/byteranges, the "normal"
>> interpretation does not apply. Because "Content-Type: multipart/byteranges" is abused
>> for this special case, the multipart/byteranges mime type must never be used in any
>> other situations.
> This is interesting.  What about for just a single range?
> Can you please provide a reference to the "new bis draft"?


> 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 Wednesday, 26 March 2014 19:23:59 UTC

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