[http-state] rough notes

Peter Saint-Andre <stpeter@stpeter.im> Wed, 24 March 2010 02:22 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 7A8893A67CC for <http-state@core3.amsl.com>; Tue, 23 Mar 2010 19:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.644
X-Spam-Status: No, score=0.644 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id KpQb9OQVjR3p for <http-state@core3.amsl.com>; Tue, 23 Mar 2010 19:22:37 -0700 (PDT)
Received: from stpeter.im (stpeter.im []) by core3.amsl.com (Postfix) with ESMTP id 6633D3A6B47 for <http-state@ietf.org>; Tue, 23 Mar 2010 19:22:06 -0700 (PDT)
Received: from dhcp-wireless-open-abg-29-126.meeting.ietf.org (dhcp-wireless-open-abg-29-126.meeting.ietf.org []) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1512940D3A for <http-state@ietf.org>; Tue, 23 Mar 2010 20:22:24 -0600 (MDT)
Message-ID: <4BA9775D.1080200@stpeter.im>
Date: Tue, 23 Mar 2010 19:22:21 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: Discuss HTTP State Management Mechanism <http-state@ietf.org>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040208090407070606060500"
Subject: [http-state] rough notes
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2010 02:22:38 -0000

From http://etherpad.com/na1WtVANL4 ...



IEF 77

AB = Adam Barth
YP = Yngve Pettersen
MP = Mark Pauley
JR = Julian Reschke
DW = Dan Witte
RF = Roy Fielding
SC = Scott Cantor

1. Agenda bash & Blue sheets

No bashing

2. Review closed tickets (Adam Barth)

[issue and discussion missed here]

Issue #4 -- comma in set-cookie

MP: would love to be able to get rid of this

Issue #6 -- host-only cookies

IE team has expressed that they would prefer to move

Issue #2 -- semicolon in quotes

RFC 2109 allows this
didn't exist then, invented in the spec

JR: was this in the original spec?
AB: what is the original spec?
JR: Netscape document
AB: doesn't count as a spec

AB: FF has changed behavior to treat quote as any other character

Issue #9 -- editorial issue

Issue #8 -- just another test

Issue #3 -- registry controlled domains

e.g., setting cookie for "co.uk" (registry controlled)
AB: giant list of registry-controlled domains
AB: what do in the spec?
- include a huge list?
- reference publicsuffix.org ?
- some kind of heuristic?

(IE has own list, other browsers use Mozilla's list publicsuffix.org)

YP: related to "Cookie Monster" bug

Note: end of closed tickets, the scribe missed some tickets at the
beginning, will need to listen to audio...

Issue #10 -- handling i18n domains in domain attributes

DW -- we compare everything to punycode
AB: avoid putting non-unicode characters on the HTTP wire

- basic comparison issue
- step 1: know if they are valid

Issue #7 - better date parsing
DW: do we want to put text in to use 64-bit field?
AB: no text about what representable time is

RF: no chance that many devices have 64-bit date parsing - require
64-bit date parsing only when possible, allow older machines not to

YP: I did a poll, most of my colleagues have 32-bit platforms
YP: most smaller platforms have a fairly low cookie limit (e.g., 300 per
YP: not a major issue, cookies will be deleted for lack of space

MP: if browser asked to set cookie date too far in the future, clip it
to date closer in

Issue #12 - The path-match algorithm doesn't match IE or Firefox exactly
- discussion on UAs are willing to change (DW: yes)

Issue #1 -- Remove  nameless cookies?

Supported in IE, FF, and Chrome. Not in Safari.

AB: why not support it?
RF: only ever seen in JavaScript and used within that page
RF: my tendency is to say this is not legal syntax and I see no reason
to support it
AB: my sense is we want user agents to process it but say that servers
should never send it
YP: prefer to say that there is always one char in the name
JR: sounds like there is no interop on the wire here
JR: I would say don't do this
AB: we seem to require this out of document.cookie
DW: it makes me sad that we support this because of one website
DW: I'd support getting rid of this if more than one browser changes
behavior (so we don't have a special case)
DW: we should at least require equals sign
AB: I'm hearing that everyone hates this
JH: in other words, not putting this in the spec
AB: send patches to delete this in open-source browsers

Issue #5 -- Cookie ordering

AB: there are some subtle issues here
AB: could have two cookies with same name sent to server at same time
AB: browsers resolve this by accepting the first cookie
YP: perhaps spec should say that no order beyond path length
YP: either (1) be very strict or (2) servers cannot rely on ordering
MP: sort on (1) length of domain (2) length of path -- but I think
creation date doesn't matter

JH: any other major issues?

JR: any dependencies on httpbis?

AB: draft currently refers to existing spec, not bis

YP: IIRC the spec mentions recent syntax like obsolete whitespace

JR: probably safe to copy that because we're not planning to change it
JR: that way you can do the same as httpbis but not reference it

YP: we discussed what is in section 4, I suggest putting syntax as start
of section 5
YP: suggesting that we add max-age to server part of protocol
AB: max-age is not implemented in all browsers

YP: suggests having two complete syntax grammars for each of the client
and server sections of the spec

DW: asks if there's thought that IE would impl max-age
AB: don't know but one can hope

LucyLynch: would be good if priv sections get bolstered, would be a good
thing, came from Priv confab in DC and "profiling" is a hot topic

YP: <something about some RFC about priv  -- RFC2964>

MP: the test suite is quite a value-add for interop (!)

JR: perhaps test suite should be an appendix of the spec

ab: can be done (!)

JH: is there anything more to discuss from the floor?


JH: if we can address open issues then we can get this ready for WGLC

JH: do people want to address specs for doing future things for cookies?

YP: I have two or three relevant specs
1. $origin (where given cookie came from)
2. fix to address cookie monster bug
3. sub-tld / public suffix draft

- did we talk about cookie limits?
- important to us
- can have deleterious effect on web traffic
- sending many kb of cookies with each request
- some devices can't handle large cookies
- even set limit on total size of cookie headers

YP: upper limit of 4k, don't send cookie header longer than 5k

AB: spec does suggest limits

MP: perhaps something about compression of cookie headers, or some kind
of consideration

YP: servers are doing this to themselves
YP: but might be causing extra cost to users who pay by the byte

RF: was there resolution to issue about disclaimer text?
RF: I think there are many ways to use cookies that don't violate
architecture or introduce security concerns

AB: security considerations used to warn against using cookies, but we
removed that -- however we do talk about security issues

YP: should there be a definition of third-party cookies?
AB: many different definitions, could do in separate document, but I
would recommend against specifying this
JH: is the general notion of third-party cookies described in the
security considerations?
AB: good to add to privacy considerations
MP: interaction here between httpstate and browser behavior
MP: tradeoff between ability to add useful content from a third party in
a page and desire not to have your activities tracked by a third party
DW: I think it's out of scope
SC: third-party cookies can help you do session logout and clear state