State | Re: Calls for Adoption -- Cookie-Related Specifications

[ Off Topic ]

> But I won't miss the chance to point out, that the reason these are
> problems that needs fix^H^H^Hbanda^H^H^H^H^Hkludges in the first
> place is that cookies are simply the wrong way to keep state.
> 
> State should be kept server-side where it belongs, indexed by a
> client chosen nonce acting as session-identifier.

State probably can be moved to server-side (or actually to server
end of HTTP/2 connection) with HTTP/2 extension. Let's call
it "remote cookie store" (or "server cookie store"). 

I notice that this however does not solve cookie problems.

That "remote cookie store" may be following:

1) Set-Cookie: headers are still passed to client
  and "remote cookie store" does NOT interpret that.
2) This "remote cookie store" is negotiated with
  SETTINGS frame.
3) Server end of HTTP/2 connection includes
  several cookie stores. These are identified
  by number/index. This number is per HTTP/2 connection.
3) Cookies are added and removed from server cookie
  store with new frame type sent via stream 0
  by HTTP/2 client.
4) If HEADERS frame includes number/index of
  server cookie store, then HTTP/2 server
  end adds Cookie: -header to request before
  it passes request upstream (to applications
  for example).

This requires support from both end of HTTP/2
connection, but does not require support from
web applications.

It may be useful when HTTP/2 connection is
persistent. ( When multiple request sent,
Cookie: -header is effectively replaced by 
number/index of server cookie store given
on HEADERS frame. )

Yes, state is still duplicated on client end.

This is off topic because this is orthogonal
with cookie parsing and cookie syntax.

( Well cookie syntax affects to new frame 
 type sent via stream 0 by
 HTTP/2 client. And server cookie store
 of course must follow Cookie: -syntax
 and algorithm about what cookies to add
 Cookie: -header. )

I'm not sure is that kind extension
enough usefull.

/ Kari Hurtta

Received on Wednesday, 23 December 2015 09:39:36 UTC