RE: Making Implicit C-E work.

Hi Roberto, see my responses in-line below...



On Saturday,03 May 2014 00:31, grmocg@gmail.com<mailto:grmocg@gmail.com> wrote:

> On Thu, May 1, 2014 at 2:57 PM, <K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>> wrote:

>> You said you are concerned especially about HTTP/1.X servers.  But your proposal can't help because the

>> 1.X servers won't know about the implicit gzip and certainly won't know to add the "uncompressed-*" headers.

>

> This is assuming that those parts aren't delegated to the loadbalancer, which I see often.



Earlier in this thread you said you have no control over the clients and servers.  Just to be clear, that means you have enough control over the loadbalancer to add the "uncompressed-*" headers??



If you have control over the loadbalancer, I assume you would have enough control to add h2 t-e. Furthermore, _if_ per-segment t-e was used, the c-e gzip entity could be used directly for the t-e gzip entity (with the uncompressed etag, etc. headers of course).  In other words, c-e gzip is-byte-for-byte identical to the per-segment t-e representation. Like I said in the other thread, per-segment and per-frame transfer coding both have their pros and cons – I’m still undecided – but this is a pro in favor of per-segment t-e.





>> In the opposite direction, if the server is HTTP/2 and the client is HTTP/1.X, the body will have to be

>> decompressed anyway so you only benefit for the hops that are HTTP/2.  Is that really that beneficial?

>

> huh?

> Browser <-h1-> Virus Scanning Software <-h1.> Corporate Proxy <-h1->  Reverse Proxy/Loadbalancer <-h2-> Reverse Proxy/Loadbalancer(2) <-h1-> Servers



In this example, the response is only compressed from the server back to the last h2 hop (Reverse Proxy/Loadbalancer) and then has to be decompressed, and will be decompressed all the way back to the browser.



I'm just asking if it's really that beneficial to have the entity compressed for a couple of hops, and then decompressed at the h2->h1 gateway - which adds cpu load to the gateway.





> Additionally, with c-e, remember that for static resources, the compression cost is incurred only once, not once for every request.



This would also be true for *per-segment* t-e. Another pro in favor of per-segment t-e.





>> What are _HTTP/2_ clients supposed to do to that really want an uncompressed (identity) entity?

>>

>> Accept-Encoding: identity

>> Implicit-Accept-Encoding: pretty please don't use gzip

>

> They're supposed to support  being able to un-gzip.



In the case of a Range request it doesn't work to get a range of a gzip entity instead of the range of the identity entity you asked for.

In other words... range(gzip(content)) != range(identity(content))



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.