Re: HTTP router point-of-view concerns

On Fri, Jul 12, 2013 at 1:58 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <092D65A8-8CB7-419D-B6A4-77CAE40A0026@gmail.com>, Sam Pullara writes
>>How sure are we that the entire idea of header compression isn't a bad
>>idea?

Me three.

> I'm entirely convinced it is a bad idea.
>
> The main gain that can be had from it, is compressing cookies and
> that issue should be solved by moving the cookies onto the server,
> indexed by a client provided session-id.

As for [encrypted] session state cookies, there is a trade-off: state
on the server vs. not.

Some state kept by the application on the server side can be cached,
using the client to hold the [encrypted] sub-state cookies and re-send
as necessary (e.g., if the server pushes the client's state out of its
cache).  Obviously this doesn't apply to long-term state (e.g., files
stored on a cloud), just session metadata, nor does it apply to
frequently-changing session state: that just consumes bandwidth --
much more than it would consume memory to just keep around.  But much
session state needs to be able to be pushed out of the server's cache
(e.g., not shopping carts in some apps, but yes in others).

The right balance, IMO, is for the server to assign as small a session
ID as it can (it can be smaller if a "connection" can be used as part
of a lookup index, else it has to be bigger).  Traditionally HTTP/1.x
services haven't really been able to associate state with
"connections", and I find it odd that we'd try to do it in HTTP/2.0.

Nico
--

Received on Thursday, 18 July 2013 00:05:42 UTC