- From: David W. Morris <dwm@xpasc.com>
- Date: Sun, 23 Mar 1997 13:22:08 -0800 (PST)
- To: Yaron Goland <yarong@microsoft.com>
- Cc: http working group <http-wg@cuckoo.hpl.hp.com>
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 13:27:12 UTC