RE: Making Implicit C-E work.

In many different e-mails grmocg@gmail.com wrote:
>

> I have a real honest-to-goodness pragmatic deployment problem (myriad pre-existing servers/clients

> whose deployment I do not and cannot control) here that I cannot wish away ...

>

> Many of my customers will not be writing custom servers, and as such to be deployable,

> we need solutions that will work with what is out there. ...
>

> My problem is dealing with the rest of the world, which is mostly HTTP/1.X and is unlikely to rapidly change.

> In other words, I'm concerned mainly with HTTP/1.X clients and especially servers. ...



I  honestly want to understand your problem, but I don't.  It might be really helpful if you could write down the hypothetical network connections between client and server (including as many potential intermediaries as you know about) and denote either HTTP/1.x or HTTP/2 for every hop.



I've been sitting here trying to understand how implicit C-E gzip helps based on what you've already said and I still don't get it.



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.



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?



Between an HTTP/2 client and an HTTP/2 server, we can already do something about it without breaking things i.e. some sort of transfer coding.





> The same bytes can't be sent in both [C-E and T-E], unless the we're willing to suffer vastly increased DoS surface area and memory usage [for T-E] ...

I don't buy the "vastly increased DoS surface area" argument. The receivers already have this "DoS surface area" for decompressing C-E gzip entities.  If the receiver of a stream has a gzip decompression context for decompressing a C-E gzip entity OR a T-E gzip message, they still just have one context.  If a receiver has N outstanding streams it has N outstanding gzip contexts, even if they're all C-E gzip.  Sure stupid servers could do both C-E and T-E, but it's near impossible to design a protocol that prevents implementors from doing every stupid thing imaginable.

So, yes the same bytes could be sent in both cases (C-E or T-E) and it's actually probably the right way to do T-E (as opposed to the frame-by-frame).




> I cannot reliably deploy a T-e based compression solution.
> T-e based compression costs too much CPU, especially as compared with c-e where one simply
> compresses any static entity once and decompresses (which is cheap) as necessary at the gateway.

You're comparing apples and oranges. Dynamic gzip has the same cpu cost whether it's called C-E or T-E. For static entities, as I pointed out above, you can pre-compress once and send the same bytes as either C-E or T-E.

> T-e based compression isn't as performant in terms of compression/deflation ratios.

LOL. I assume you could only possibly be talking about frame-by-frame T-E. Ironically, in another thread you said the performance difference for frame-by-frame is negligible (and we sent out data to back that up).

> Many deployed clients/servers wouldn't correctly support it.

I know of no clients/servers that *incorrectly* support T-E.  I assume you just mean wouldn't support it at all?

> T-e would require that any gateway acting as a loadbalancer/reverse proxy would either need to know which
> resources it could compress, or forces us to not use compression. Knowing what resources to compress either
> requires an oracle, or requires content authors to change how they author content (*really* not likely to happen),



How do they solve the same problem with C-E?  The server decides, right?  Same thing for T-E.





> [With implicit C-E gzip] [a]n HTTP/1 client still receives an uncompressed entity if it didn't request it compressed.

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





In addition to everything above, I noticed that you still haven't responded to concerns that Matthew & Julian brought up. It would be good for you to update your proposal to address these concerns...



- Matthew wrote: "[What about] last-modified? And, possibly, other fields from Vary? There's more entity-specific metadata than just ETag."



- Matthew also wrote: "Cache-Control:no-transform explicitly forbids the proxy from altering the representation. It's not allowed to decompress it."



- And elsewhere Julian brought up the issue of entity-specific metadata in the body itself. He used the example of WebDav. Do you expect intermediaries to parse through bodies and patch up that metadata too?





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.

Received on Thursday, 1 May 2014 21:58:27 UTC