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

From: Kari Hurtta <[email-masked]>
Date: Wed, 23 Dec 2015 07:39:07 +0000

[ 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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 23 Dec 2015 23:10:19 +0000

--------

>I notice that this however does not solve cookie problems.

It's really very simple:  Clients shouldn't even know cookies exist.

Clients should send a session-ID to the server.

The session-ID should be marked either anonymous
or persistent.

If it is anonymous, the client is never going to
reuse it after this session ends, so the server
need not bother store anything permanently.

If it is persistent, the client wil reuse the
same session identifier in the future, and
the server can use it as index into server
side state storage facilities.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 27 Dec 2015 10:46:20 +0000

( Previous message was sent accidentally. I'm sorry. )

Poul-Henning Kamp <[email-masked]>: (Thu Dec 24 01:10:19 2015)
> It's really very simple:  Clients shouldn't even know cookies exist.

I wrote

| 1) Set-Cookie: headers are still passed to client
|   and "remote cookie store" does NOT interpret that.

so that "ask me every time" browser cookie setting
still works.

> Clients should send a session-ID to the server.

I wrote

| 3) Server end of HTTP/2 connection includes
|  several cookie stores. These are identified
|  by number/index. This number is per HTTP/2 connection.

| 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).

Effectively pair (TCP connection, cookie store
index) works here as session-ID.

( May need indication on SETTINGS frame so that
cookie store index is sent when there is no cookies. 
Some complications on here. ) 

> need not bother store anything permanently.

How long session-ID is is valid if it is anonymous.
What it time of life for it ?

If it is just for ONE http -request, it does not
make sense for server to store stat at all. It is
useless.

> side state storage facilities.

If anonoumous session-ID is not reused for several requests,
it is useless. So what is difference?

What tells to server that session-ID is no longer used
and it does not make sense to save stat for longer.

On that (TCP connection, cookie store index) -pair
that state destruction event is close of TCP 
connection (HTTP/2).

Perhaps also destruction event is some frame on 
stream 0:

| 3) Cookies are added and removed from server cookie
|   store with new frame type sent via stream 0
|  by HTTP/2 client.

( I see that I have some error on numbering. ☹ )

Yes, on that what I wrote, there is no anything permanent
on server end of HTTP/2 connection (so that state's time of 
lifeis longer that  HTTP/2 connection. 

Adding that may require that nonce (on new frame type) on 
stream 0 when HTTP/2 client asks establishment of new server 
side cookie store. Lot of complications.

/ Kari Hurtta