Range Requests vs Content Codings

Trying to summarize the problem, and trying a solution:

Consider a text/plain resource http://example.org/test of 1000000 octets 
length (representation A), supporting content coding "gzip", yielding 
100000 octets (representation B).

Upon GET, clients can select which one to use using "Accept-Encoding". 
For instance

   GET /test HTTP/1.1
   Host: example.org
   Accept-Encoding: gzip

is likely to return the representation B, while

   GET /test HTTP/1.1
   Host: example.org
   Accept-Encoding: identity

will return representation A.

A specified range will always apply to the representation. Thus, a 
client can't easily ask for a specific range of representation A *and* 
have the server apply Content-Coding gzip.

(Compression could also be achieved by using Transfer Codings, but these 
are not implemented in practice)

One way to combine Content Codings and range requests would be to create 
a new range unit, "bbcc" (bytes-before-content-coding). In which case 
the the requested range would be applied to the non-content-coded 
representation, and the content-coding would be applied to the byte range.

Such as:

   GET /test HTTP/1.1
   Host: example.org
   Accept-Encoding: gzip
   Range: bbcc=900000-

This would retrieve the octets starting at position 900000, and apply 
content-coding gzip to the resulting octet sequence.

Note that to combine range responses using these byte range units, a 
recipient needs to understand the range unit (simple concatenation isn't 
going to work).

This also requires that both user agent and origin server understand the 
new range unit, but that appears to be easier to deploy than T-E (which 
requires all intermediaries to play along).

Thoughts?

Best regards, Julian

Received on Tuesday, 17 June 2014 10:27:00 UTC