- From: Yaron Goland <yarong@microsoft.com>
- Date: Sun, 23 Mar 1997 18:11:58 -0800
- 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 UTC