From: Matthew Kerwin Date: 2016-02-05T23:49:06+10:00 Subject: [ruby-core:73713] Re: [Ruby trunk Bug#12055] `NET::HTTPResponse` is not deflating responses with custom `Content-Range` header --===============0065881210== Content-Type: multipart/alternative; boundary=001a1134e69067ea81052b061d89 --001a1134e69067ea81052b061d89 Content-Type: text/plain; charset=UTF-8 On 05/02/2016 11:06 PM, wrote: > > Issue #12055 has been reported by Glauber Campinho. > > The RFC 7233, section 4.2 describes the the possibility of using a custom `Content-Range` header and not only for bytes [[ https://tools.ietf.org/html/rfc7233#section-4.2]]. Although, the `NET::HTTPResponse` considers that `Content-Range` present on the response during the inflating is in `bytes` unit. > > This issue is caused by this line [[ https://github.com/ruby/ruby/blob/trunk/lib/net/http/response.rb#L252]]. In the patch I changed it to check if the `Content-Range` unit is `bytes` and there is a test to reproduce the error. > I don't see a problem with the existing code. No matter what range unit is used, if the response body is not the complete resource representation, it should not be inflated, because it's not the complete gzip/etc. stream. If your example 'item' unit is applicable to a content-type that allows its 'items' to be individually compressed, that compression is a property of the content-type itself, not a content-encoding of the resource as a whole. Conversely, it's hard to reason about a range of 'items' inside a gzip-encoded resource -- how do I transmit just the third line of foo.csv.gz, for example? If you want to transport individual chunks compressed, even though the content-type doesn't necessarily support compressed chunks, you should look at transfer encoding. Incidentally, Content-Range does not apply to 200 Ok responses, you should use 206 Partial Content. --001a1134e69067ea81052b061d89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 05/02/2016 11:06 PM, <ggcampi= nho@gmail.com> wrote:
>
> Issue #12055 has been reported by Glauber Campinho.
>
> The RFC 7233, section 4.2 describes the the possibility of using a cus= tom `Content-Range` header and not only for bytes [[https://tools.ietf.org/html/rfc7233#s= ection-4.2]]. Although, the `NET::HTTPResponse` considers that `Content= -Range` present on the response during the inflating is in `bytes` unit. >
> This issue is caused by this line [[https://github.com/ruby/ru= by/blob/trunk/lib/net/http/response.rb#L252]]. In the patch I changed i= t to check if the `Content-Range` unit is `bytes` and there is a test to re= produce the error.
>

I don't see a problem with the existing code. No matter = what range unit is used, if the response body is not the complete resource = representation, it should not be inflated, because it's not the complet= e gzip/etc. stream.

If your example 'item' unit is applicable to a conte= nt-type that allows its 'items' to be individually compressed, that= compression is a property of the content-type itself, not a content-encodi= ng of the resource as a whole.

Conversely, it's hard to reason about a range of 'it= ems' inside a gzip-encoded resource -- how do I transmit just the third= line of foo.csv.gz, for example?

If you want to transport individual chunks compressed, even = though the content-type doesn't necessarily support compressed chunks, = you should look at transfer encoding.

Incidentally, Content-Range does not apply to 200 Ok respons= es, you should use 206 Partial Content.

--001a1134e69067ea81052b061d89-- --===============0065881210== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Unsubscribe: --===============0065881210==--