- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 17 Jun 2014 17:53:57 -0500
- 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