Re: [http-state] http-state Digest, Vol 10, Issue 8

[eric bianchetti <[e-mail]>]

I believe, but I might be utterly wrong, the old specifications (sorry I do not recal the RFC #) was : 

1) the Domain MUST have 2 dots.
2) if Domain is not explicitly given (Domain = .domain.com) then the server that initiate the request will be the implicit domain; AND Path will not be taken in account.

My opinion, for what it is worth, being we should keep the same behavior for backward compatibility.

Eric



----- Original Message ----
From: "[e-mail]" <[e-mail]>
To: [e-mail]
Sent: Thu, February 4, 2010 3:00:08 AM
Subject: http-state Digest, Vol 10, Issue 8

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/http-state

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send http-state mailing list submissions to
    mailto:[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/http-state
or, via email, send a message with subject or body 'help' to
    mailto:[e-mail]

You can reach the person managing the list at
    mailto:[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of http-state digest..."


Today's Topics:

  1. Re: Ticket 6: host-only cookies (Mark Pauley)


----------------------------------------------------------------------

Message: 1
Date: Wed, 3 Feb 2010 11:40:26 -0800
From: Mark Pauley <[e-mail]>
Subject: Re: [http-state] Ticket 6: host-only cookies
To: Adam Barth <[e-mail]>
Cc: http-state <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

CFNetwork used to treat domain attributes starting without a dot literally, but I think we've gone back to prepending the dot due to compatibility issues.


On Feb 2, 2010, at 11:35 AM, Adam Barth wrote:

> On Tue, Feb 2, 2010 at 11:14 AM, Dave Kristol
> <[e-mail]> wrote:
>> Adam Barth wrote:
>>> Do you mean that
>>> 
>>> Set-Cookie: foo=bar; Domain=example.com
>>> 
>>> and
>>> 
>>> Set-Cookie: foo=bar; Domain=.example.com
>>> 
>>> are treated differently by user agents?  That might be true according
>>> to 2109 (I'd have to check), but I don't think that's how user agents
>>> work in practice.  They appear to ignore the leading dot.  If you have
>>> a test case that show a difference, I'd be very interested in seeing
>>> it.
>> 
>> That is what I meant, and I do not have a test case.  That is what 2109
>> said, and I believe (though it's been many years now... ugh!) I adopted that
>> from Netscape's spec.  Generally speaking, the idea was that, in the absence
>> of Domain=, the cookie should be returned only to the server that sent it.
> 
> I believe this is the line of code in Firefox that causes the leading
> dot in the domain attribute to be ignored.
> 
> http://mxr.mozilla.org/mozilla-central/source/netwerk/cookie/src/nsCookieService.cpp#2159
> 
> There's a similar line of code in Chrome in the GetCookieDomainKey
> function in this file:
> 
> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/cookie_monster.cc?view=markup
> 
> Here's the comment:
> 
>  // Get the normalized domain specified in cookie line.
>  // Note: The RFC says we can reject a cookie if the domain
>  // attribute does not start with a dot. IE/FF/Safari however, allow a cookie
>  // of the form domain=my.domain.com, treating it the same as
>  // domain=.my.domain.com -- for compatibility we do the same here.  Firefox
>  // also treats domain=.....my.domain.com like domain=.my.domain.com, but
>  // neither IE nor Safari do this, and we don't either.
> 
> Note that Firefox now acts like IE/Chrome/Safari in regards to
> Domain=.....my.domain.com
> 
> Adam
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state



------------------------------

_______________________________________________
http-state mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/http-state


End of http-state Digest, Vol 10, Issue 8
*****************************************