Re: [http-state] I-D Action:draft-ietf-httpstate-cookie-20.txt

["Paul E. Jones" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> On Behalf Of [e-mail]
> Sent: Sunday, December 19, 2010 2:00 PM
> To: [e-mail]
> Cc: [e-mail]
> 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:[e-mail]>.  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.