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

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Wed, 23 December 2015 09:42 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5371ACE15 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 23 Dec 2015 01:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJixfcFwyHOU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 23 Dec 2015 01:42:36 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081FA1ACE13 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 23 Dec 2015 01:42:35 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aBftX-0007f6-3B for ietf-http-wg-dist@listhub.w3.org; Wed, 23 Dec 2015 09:39:43 +0000
Resent-Message-Id: <E1aBftX-0007f6-3B@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aBftQ-0007eB-L8 for ietf-http-wg@listhub.w3.org; Wed, 23 Dec 2015 09:39:36 +0000
Received: from raoul.w3.org ([128.30.52.128]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aBftA-0003zr-OJ for ietf-http-wg@w3.org; Wed, 23 Dec 2015 09:39:35 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.39]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aBftA-0004pe-2l for ietf-http-wg@w3.org; Wed, 23 Dec 2015 09:39:20 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: text/plain; charset="us-ascii"
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Wed, 23 Dec 2015 07:39:07 +0000
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Content-Transfer-Encoding: 7bit
Resent-Date: Wed, 23 Dec 2015 10:39:17 +0100
Message-Id: <E1aBe0k-00010L-VL@maggie.w3.org>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
Resent-To: ietf-http-wg@w3.org
To: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.3112)
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, AWL=-2.256, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: maggie.w3.org 1aBftA-0003zr-OJ 7ef31423ad53aca7508076b2296d6179
X-Original-To: ietf-http-wg@w3.org
Subject: State | Re: Calls for Adoption -- Cookie-Related Specifications
Archived-At: <http://www.w3.org/mid/E1aBe0k-00010L-VL@maggie.w3.org>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30823
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

[ 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