Re: [http-state] 'HTTP State Management Mechanism' to Proposed Standard
=JeffH <Jeff.Hodges@KingsMountain.com> Thu, 03 March 2011 22:10 UTC
Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2FB3A68C8 for <http-state@core3.amsl.com>; Thu, 3 Mar 2011 14:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.298
X-Spam-Level:
X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUEQUXD4DXW2 for <http-state@core3.amsl.com>; Thu, 3 Mar 2011 14:10:14 -0800 (PST)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id AED2628C0DF for <http-state@ietf.org>; Thu, 3 Mar 2011 14:10:14 -0800 (PST)
Received: (qmail 24866 invoked by uid 0); 3 Mar 2011 22:11:22 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 3 Mar 2011 22:11:22 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=3qP66GP+ghZVH6aGScIx+nKFc48B+g32hJcSLY/fw7+/qc2EUewWGnRWkgUjIoT7vweLD0KJ3xrPRha4Y8qEV873LGR9SkKmBhl6060oD9AH+aYFRQ5CYXpZFpglc46m;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.181]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1PvGjy-0000lX-0Q; Thu, 03 Mar 2011 15:11:22 -0700
Message-ID: <4D701209.9090008@KingsMountain.com>
Date: Thu, 03 Mar 2011 14:11:21 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: IETF HTTP State WG <http-state@ietf.org>, Internet Architecture Board <iab@iab.org>, www-tag@w3.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Cc: httpstate chair <httpstate-chairs@tools.ietf.org>
Subject: Re: [http-state] 'HTTP State Management Mechanism' to Proposed Standard
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: Thu, 03 Mar 2011 22:10:25 -0000
Mea culpa :( I relied on my obviously faulty memory this morning in my haste rather than going back (only 2+ yrs ;) and reviewing mailing list archives, and so didn't recall that Bil was instrumental in the creation of this effort. Many thanks to Bil for instigating this effort. Here's something he wrote wrt the history of this recent edition of the http-state working group.. "A bit of history on this effort, it was well known within the IETF community that the supposed "official" cookie specification (RFC2965) was out-of-sync with how browsers were actually using cookies -- the browser vendors never implemented RFC2965 (except Opera). Anyone wanting to consume or send cookie headers had to reverse engineer how the browsers were actually doing it as there wasn't (until now) a specification an implementer could use for reference. This lead to a variety of divergence on edge-cases for cookies within the implementations. In late 2008, Jim Manico and I connected to create a specification for HTTPOnly -- we saw the security issues arising from how the browser vendors were implementing HTTPOnly in varying ways[1] due to a lack of a specification and formed an ad-hoc working group to tackle the issue[2]. When I approached the IETF about forming a charter for an official working group, I was told that I was <quote> "wasting my time" because cookies itself did not have a proper specification, so it didn't make sense to work on a spec for HTTPOnly. Soon after, we pursued reopening the IETF httpstate Working Group to tackle the entire cookie spec, not just HTTPOnly. Eventually Adam Barth would become editor and Jeff Hodges our chair. This cleans up a well-known mess and gives us a good starting point from which to improve httpstate and add improved security features. And no, it's not lost on me that HTTPOnly still has considerable divergence on behavior. Perhaps now I can finally form my HTTPOnly working group. (Bil Corry)" HTH, =JeffH
- Re: [http-state] 'HTTP State Management Mechanism… =JeffH
- Re: [http-state] 'HTTP State Management Mechanism… Peter Saint-Andre
- Re: [http-state] 'HTTP State Management Mechanism… Lucy Lynch
- Re: [http-state] 'HTTP State Management Mechanism… Adam Barth
- Re: [http-state] 'HTTP State Management Mechanism… =JeffH
- Re: [http-state] 'HTTP State Management Mechanism… Larry Masinter
- Re: [http-state] 'HTTP State Management Mechanism… Adam Barth