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

Re: Range Requests vs Content Codings

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Tue, 17 Jun 2014 17:53:57 -0500
Message-ID: <CACuKZqFeAtz7ck7pLzLPsmk+HXWUbEEso5GMNHVs+sZZfD=YqQ@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jun 17, 2014 at 5:24 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> On 18 June 2014 02:56, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> On 2014-06-17 15:15, Matthew Kerwin wrote:
>>>
>>>
>>> To my mind, this also opens up the idea of a 'bacc' range unit (bytes
>>> after content-coding), as an explicit signal that the client only
>>> wants the range if it's from the content-coded representation. AFAIU
>>> currently it's a bit ambiguous what to do when a request has both A-E
>>> and Range headers. Of course, 'bacc' requires there to be exactly one
>>
>>
>> The ambiguity is caused by the client sending a request that selects
>> multiple representations. That's easy to avoid...
>>
>
> Oh, yeah, because "identity;q=0" is allowed. Apologies for posting late at
> night.

Do servers ever honor that? For example, send this request

  GET /logos/doodles/2014/world-cup-2014-14-russia-vs-korea-5756435967246336.2-hp.gif
HTTP/1.1
  HOST: www.google.com
  Accept-Encoding: gzip, identity;q=0


and the server happily responds with 200, without Content-Encoding.

Zhong Yu




>
>
>>
>>
>>> coding in the Accept-Encoding header, but it could be useful for
>>> resuming a content-coded download. The same caching issues as with
>>> 'bbcc' still apply, though.
>>
>>
>> Best regards, Julian
>>
>
>
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
Received on Tuesday, 17 June 2014 22:54:24 UTC

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