Re: [http-state] I-D Action:draft-ietf-httpstate-cookie-20.txt
"Paul E. Jones" <paulej@packetizer.com> Thu, 06 January 2011 15:56 UTC
Return-Path: <paulej@packetizer.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 3A08C3A6E2B for <http-state@core3.amsl.com>; Thu, 6 Jan 2011 07:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6]
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 3K5Uhxptb58l for <http-state@core3.amsl.com>; Thu, 6 Jan 2011 07:56:11 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 910B33A6E1A for <http-state@ietf.org>; Thu, 6 Jan 2011 07:56:10 -0800 (PST)
Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id p06Fw9Vn015514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jan 2011 10:58:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1294329495; bh=96DwfddGe0Uthvnyki5qC3kNcHbRctqR8WRFoXh3Cws=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TyMMkN4uQnvOevZ89xVh2rCWJ4DXIegaIKhvNdZd8Z8u4lRxzcsiy2eDG6oNewvx1 6n97EpdAp3lFkPUAQ8qH5QIkT0F7poswVOY6eRrK/XkyHjwNmS39SGvKYqKfXWmi01 4Y1JGgglhxdKr8dH88G4Sxy8RkWraejytrO/YYyI=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'Adam Barth' <ietf@adambarth.com>
References: <20101219190001.812.87795.idtracker@localhost>
In-Reply-To: <20101219190001.812.87795.idtracker@localhost>
Date: Thu, 06 Jan 2011 10:57:59 -0500
Message-ID: <072301cbadba$829adaa0$87d08fe0$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKbH5XLhNoFTCnbrQLedk+kxu/zxJIlLF/g
Content-Language: en-us
Cc: http-state@ietf.org
Subject: Re: [http-state] I-D Action:draft-ietf-httpstate-cookie-20.txt
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, 06 Jan 2011 15:56:12 -0000
Adam, In the RFC 2109, the "domain" attribute is optional. Specifically, it says: Domain=domain Optional. The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot. It also defined a default: Domain Defaults to the request-host. (Note that there is no dot at the beginning of request-host.) I found this in the -20 draft: 4.1.2.3: If the server omits the Domain attribute, the user agent will return the cookie only to the origin server. WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name. For example, if example.com returns a Set- Cookie header without a Domain attribute, these user agents will erroneously send the cookie to www.example.com as well. If I received a cookie without a domain from test.example.com, I would assume the cookie's domain is "test.example.com". The wording above confuses me a little, as I would bind the cookie to the host I accessed. The first sentence in the WARNING seems like what I should do, but the example presented is not the origin server or the "current host name". I agree that it would be an error for a browser to assume a larger domain scope than just the single host being accessed. But, I would think that absence of or an empty string for "Domain" would be bound only to the server being accessed. I believe that is the intent, as stated in other sections, but the warning text seems to suggest otherwise when I read it. In Section 5.2.3, this text appears: If the attribute-value is empty, the behavior is undefined. However, user agent SHOULD ignore the cookie-av entirely. Why would the behavior be undefined? Why would these not be treated identically? Set-Cookie: mycookie=myvalue; path=/ Set-Cookie: mycookie=myvalue; path=/; domain= Why isn't an empty string a valid value? I ask, because we assign an empty value internally. In 5.3, paragraph 4, we have: 4. If the cookie-attribute-list contains an attribute with an attribute-name of "Domain": Let the domain-attribute be the attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Domain". Otherwise: Let the domain-attribute be the empty string. So, this does suggest "domain=" would be the same as absence of the domain parameter, no? Paragraph 6 then explains that in such cases, the domain is assigned to "the canonicalized request-host", which is consistent. So, any reason why the Domain a/v syntax isn't this? domain-value = <subdomain> | "" Paul > -----Original Message----- > From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Sunday, December 19, 2010 2:00 PM > To: i-d-announce@ietf.org > Cc: http-state@ietf.org > Subject: [http-state] I-D Action:draft-ietf-httpstate-cookie-20.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the HTTP State Management Mechanism Working > Group of the IETF. > > > Title : HTTP State Management Mechanism > Author(s) : A. Barth > Filename : draft-ietf-httpstate-cookie-20.txt > Pages : 44 > Date : 2010-12-19 > > This document defines the HTTP Cookie and Set-Cookie header fields. > These header fields can be used by HTTP servers to store state (called > cookies) at HTTP user agents, letting the servers maintain a stateful > session over the mostly stateless HTTP protocol. Although cookies have > many historical infelicities that degrade their security and privacy, > the Cookie and Set-Cookie header fields are widely used on the > Internet.Editorial Note (To be removed by RFC Editor) > > If you have suggestions for improving this document, please send email > to <mailto:http-state@ietf.org>. Suggestions with test cases are > especially appreciated. Further Working Group information is available > from <https://tools.ietf.org/wg/httpstate/>. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-httpstate-cookie-20.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft.
- [http-state] I-D Action:draft-ietf-httpstate-cook… Internet-Drafts
- Re: [http-state] I-D Action:draft-ietf-httpstate-… Paul E. Jones