W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: Session tracking

From: Brian Behlendorf <brian@organic.com>
Date: Thu, 20 Apr 1995 11:52:56 -0700 (PDT)
To: Larry Masinter <masinter@parc.xerox.com>
Cc: Multiple recipients of list <www-talk@www10.w3.org>
Message-Id: <Pine.3.89.9504201130.m492-0100000@eat.organic.com>
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/
Received on Thursday, 20 April 1995 14:53:08 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC