W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

RE: new cookie draft

From: Yaron Goland <yarong@microsoft.com>
Date: Sun, 23 Mar 1997 18:11:58 -0800
Message-Id: <11352BDEEB92CF119F3F00805F14F485026B725A@RED-44-MSG.dns.microsoft.com>
To: "'David W. Morris'" <dwm@xpasc.com>
Cc: http working group <http-wg@cuckoo.hpl.hp.com>
Good argument. So, it sounds like we have this one sewn up.
	Yaron

> -----Original Message-----
> From:	David W. Morris [SMTP:dwm@xpasc.com]
> Sent:	Sunday, March 23, 1997 1:22 PM
> To:	Yaron Goland
> Cc:	http working group
> Subject:	RE: new cookie draft
> 
> 
> 
> On Sun, 23 Mar 1997, Yaron Goland wrote:
> 
> > Do we want to tight B up so that you always have to specify a port
> > number? I would be suspicious of a cookie which doesn't know its own
> > port and so has to ask the client to record it. Still, I like the
> > proposal.
> 
> The client always has the port available. I think there will be quite
> a
> few cases where the CGI program fabricating the cookie doesn't know
> the
> server's port and possibly can't get it easily. So I think PORT w/o a
> specific number has value.
> 
> Dave
> 
> > 
> > > -----Original Message-----
> > > From:	David W. Morris [SMTP:dwm@xpasc.com]
> > > Sent:	Sunday, March 23, 1997 11:07 AM
> > > To:	Yaron Goland
> > > Cc:	http working group
> > > Subject:	RE: new cookie draft
> > > 
> > > 
> > > 
> > > On Sat, 22 Mar 1997, Yaron Goland wrote:
> > > 
> > > > Actually I suggested the exact opposite. If PORT is NULL then
> the
> > > cookie
> > > > may be sent on any port. It is only if a port is specified that
> > > there is
> > > > a restriction.
> > > 
> > > I think perhaps my syntax wasn't clear.  My intent was that three
> > > cases
> > > exist:
> > > 
> > >  a)   PORT attribute not specified, the attribute is NULL
> > > 
> > >       There are no restrictions
> > > 
> > >  b)   PORT attribute specified but with no value, the value NULL
> > >  
> > >       Only the source PORT may receive the cookie
> > > 
> > >  c)   PORT attribute with a value in which case the value is a
> comma
> > >       delimited list of valid ports.  (e.g, PORT="80,443")
> > > 
> > >       Only the listed ports may receive the cookie
> > > 
> > > I think (a) and (b) are your proposal and I added (c) to allow
> more
> > > precise control.
> > > 
> > > Dave
> > > 
> > > > 	Yaron
> > > > 
> > > > > -----Original Message-----
> > > > > From:	David W. Morris [SMTP:dwm@xpasc.com]
> > > > > Sent:	Friday, March 21, 1997 10:21 PM
> > > > > To:	http working group
> > > > > Subject:	RE: new cookie draft
> > > > > 
> > > > > 
> > > > > 
> > > > > On Fri, 21 Mar 1997, M. Hedlund wrote:
> > > > > 
> > > > > > On Fri, 21 Mar 1997, Yaron Goland wrote:
> > > > > > > We can
> > > > > > > define an attribute "PORT", with no argument. If it is
> > > included in
> > > > > a
> > > > > > > cookie then the cookie may only be returned on the port it
> was
> > > > > received
> > > > > > > on, this requirement applies to all domains. 
> > > > > > 
> > > > > > That sounds right.  
> > > > > 
> > > > > An alternative ... a PORT attribute whose value is a comman
> > > delimited
> > > > > list
> > > > > of ports on which the cookie may be returned. If the PORT
> > > attribute is
> > > > > omitted, any port is valid.  If the value of the PORT
> attribute is
> > > > > NULL,
> > > > > then as Yaron suggested, it may only be sent to the port it
> was
> > > > > received
> > > > > from. This allows it to be very tight while not excluding a
> value
> > > like
> > > > >  
> > > > >                 port="80,443"
> > > > > 
> > > > > which would allow sharing beteen the default HTTP and HTTPS
> ports.
> > > > > 
> > > > > Note: While I am proposing a mechanism to resolve an issue, I
> > > don't
> > > > > share
> > > > > the concern so I will be happy with any solution which allows
> > > sharing
> > > > > between ports.
> > > > > 
> > > > > Dave Morris
> > > > 
> > 
Received on Sunday, 23 March 1997 18:12:54 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:33 EDT