[7983] in www-talk@info.cern.ch
Re: Session tracking
daemon@ATHENA.MIT.EDU (Brian Behlendorf)
Thu Apr 20 18:59:26 1995
Date: Thu, 20 Apr 1995 18:40:01 +0500
Errors-To: procmaster@www19.w3.org
Reply-To: brian@organic.com
From: Brian Behlendorf <brian@organic.com>
To: Multiple recipients of list <www-talk@www10.w3.org>
On Thu, 20 Apr 1995, Larry Masinter wrote:
> > o The "domain" attribute, if present, specifies a server domain in the
> > form of a TCP/IP domain name. Note that the domain acts as a tail end
> > mask. All hosts within the specified domain will recieve the cookie
> > on subsequent requests. Only hosts within the specified domain can
> > set a cookie for a domain and domains must have at least two (2)
> > periods in them to prevent domains of the form: ".com" and ".edu".
> > ".mcom.com" is an example of a valid domain.
>
> This doesn't work outside of the US. For example, companies in the UK
> tend to have domain names that end in .co.uk. I don't know if you can
> tell merely by syntax what the actual domain of authority is for a DNS
> name.
>
> Is this a necessary feature? If it isn't reliable and can be abused,
> it would be best to avoid it.
I see a use for it - where a company has web servers on a.company.com,
b.company.com and c.company.com and wants to track sessions amongst all
them. However, the ".co.uk" example does blow that out of the water, and
the simpler model (one where the client has a persistant session-ID)
allows for this anyways. What if "domain" were "other-hosts" where an
access to a.company.com resulted in a response that specified
b.company.com and c.company.com as other places the session-ID should be
used at? Or a regular expression, like "*.bt.co.uk"?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
