Re: Submitted new I-D: Cache Digests for HTTP/2

I would like to join from this point to understand and ask the list 
since I couldn't follow and understand what was proposed and implemented 
exactly and I wanted to make sure I understand right.

On 22/01/2016 19:47, Richard Bradbury wrote:
> Hello. The general thrust of this I-D seems like a useful optimisation
> of HTTP/2 server push. It is wasteful to push a representation to a
> client when the client already has a fresh copy cached. But the reverse
> is equally true, I think...

In some relation to the above quote I would like to ask:
What is basically more important the client or the server resources?

 From what I understood the basic proposal was to add into every request 
the cache digest am I right? Is it still that way?

Else then some privacy issues about sending the client cache-digest and 
TLS as being considered secure, there are other issues with it, for 
example mobile clients or metered WAN and LAN connections.
If the client sends some KB(which can be more then couple cookies) on 
each request it means that for 20 requests the usage will be 10KB*20 <> 
200KB which can become an issue for some but not all clients.
Maybe for youtube that sends files\objects ranging from 3MB to 500MB++ 
it's not always an issue but sites that sends\pushes X*3MB images for 
the homepage to a mobile app is kind of an issue. If I'm not wrong this 
is one of the reasons that mod_pagespeed was designed, to somehow solve 
wrongly consumed bandwidth.

 From my point of view and understanding a cache-digest will probably 
require some per client "cache-digest dictionary" which can cause some 
issues to systems\servers with lots of clients\connections. The other 
side would be the ongoing re-validation and maintenance of this 
dictionaries.
It opens both the clients and the servers to some vulnerabilities. Also 
what would be the scope of the cache-digest, per connection? per 
request? per some client session id?

And to polish out some aspects, what would happen if the server(which in 
many cases doesn't care about couple KB on the wire) will send a push 
offer for 20 objects and will be declined for each and every one of them 
with some kind of 304 by the client?
- It will not require to open a new connection to the client and will 
use the same open connection.
- It will not create a situation which the client 
resources(non-symmetric DSL clients) are being exhausted(imagine an 
office with 100+ PCs and 2 DSL 15MBit\1Mbit connection..)
- It will simplify the server SW implementation and will prevent the 
need to store and look-up the client "cahce-digest dictionary" each and 
every time.

And also if the html page contains the list of urls for objects that the 
client\browser can validate by itself someway, why do the client needs 
to be pushed some objects\content?(this is yet to be fully understood to me)
I am looking for couple scenarios which will justify and clear out the 
need for such an implementation. Where is it needed else then 
advertisements?
My basic understanding is that a cache-digest doesn't help for 
interactive applications or chats or real-time applications since the 
content there is always new or updated compared to the client. And 
compared to these a static files site will maybe require the client to 
send once the cache-digest but not on each and every request.

I am almost convinced that:
- Implementing a special request for an "update" request to a specific 
set\batch of files\objects will be much more efficient for both the 
client and the server then sending the cache-digest even once in a header.
- Using some kind of push\offer 20 objects and being declined by the 
client would be much better then publishing the list of existing objects 
by the client.
- For a client that doesn't care to send the header for 20 objects it 
would be pointless to not send if-modified-X requests for each and every 
one of these objects as an entity.
- There are some security risks in the client sending a cache-digest in 
a specific scope which I would like to read about.

Thanks,
Eliezer

Received on Wednesday, 27 January 2016 02:46:01 UTC