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

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

Poul-Henning Kamp <phk@phk.freebsd.dk>: (Thu Dec 24 01:10:19 2015)
> --------
> In message <E1aBe0k-00010L-VL@maggie.w3.org>, Kari Hurtta writes:
> 
>> I notice that this however does not solve cookie problems.
> 
> 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. ) 

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

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.

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

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.

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

/ Kari Hurtta

Received on Sunday, 27 December 2015 20:03:06 UTC