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: Sat, 22 Mar 1997 00:34:23 -0800
Message-Id: <11352BDEEB92CF119F3F00805F14F485026B723F@RED-44-MSG.dns.microsoft.com>
To: "'David W. Morris'" <dwm@xpasc.com>, http working group <http-wg@cuckoo.hpl.hp.com>
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.
	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 Saturday, 22 March 1997 00:36:08 EST

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