[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] initCookie
Rich Thompson wrote: > > Yes, the current set should always be being pruned due to expiry and > filtered based on domain/path. I think the interesting question is when > neither of these change the cookie set and yet an InvalidCookie fault is > returned. The spec says the Consumer must invoke initCookie(), > presumably passing the valid set of cookies, and then should reinvoke > the operation. The key is allowing the initCookie() response to update > the set of current cookies (as can any other call). Since the spec does not specify anything about what kind of cookies are returned, I don't see any problem in consumer returning all valid cookies (set during previous interactions with the producer) for the initCookie operation after a fault. May be I'm missing Andre's question. Subbu > > Rich Thompson > > > *Subbu Allamaraju <subbu@bea.com>* > > 06/24/2003 08:52 AM > > > To: wsrp@lists.oasis-open.org > cc: > Subject: Re: [wsrp] initCookie > > > > > Rich Thompson wrote: > > > > Wouldn't be the most sensible if the initCookie() invocation carried all > > the currently known cookies, but that only those returned on the > > response were carried forward to future invocations? > > In the spirit of RFC2109, IMO, don't you think that the correct approach > would be to return just valid cookies (unexpired, matching domain/path, > scheme etc.)? This may be hard to do, but sending stale/invalid cookies > could be problematic for a number of applications (I'm not referring to > app servers coping with invalid cookies). > > So, my understanding is that, folloing an InvalidCookie fault, the > consumer may send any valid cookies (if there are any, including the set > that just caused the fault) for that producer. > > Subbu > > > > > > > Rich Thompson > > > > > > *Andre Kramer <andre.kramer@eu.citrix.com>* > > > > 06/24/2003 06:30 AM > > > > > > To: "'David Ward'" <david.ward@oracle.com>, Andre Kramer > > <andre.kramer@eu.citrix.com> > > cc: WSRP <wsrp@lists.oasis-open.org> > > Subject: RE: [wsrp] initCookie > > > > > > > > > > I agree JSESSIONID has no special significance. While (a) seems more > > strict, I'm fine with (b), but wanted to flush out any problems app > > servers may have with expired cookies. > > > > regards, > > Andre > > -----Original Message-----* > > From:* David Ward [mailto:david.ward@oracle.com]* > > Sent:* 24 June 2003 11:15* > > To:* Andre Kramer* > > Cc:* WSRP* > > Subject:* Re: [wsrp] initCookie > > > > > > > > Andre Kramer wrote: > > > > One question I have, now that we have multiple cookies, is which > > cookie(s) are invalidated by the InvalidCookie fault? > > > > Or to put it another way: Should the initCookie(), following an > > InvalidCookie fault, forward (a) no cookies (b) all currently stored > > cookies or (c) only cookie(s) set by last initCookie() response. > > > > (b) sounds the most sensible to me - you are following cookie semantics > > and can leave it to the Producer to decide what to do with each > > (potentially expired) cookie. I can't believe that app servers will have > > problems with expired cookies being sent. > > > > I don't like the overhead of tracking (c), and (b) may give some app > > servers problems if some of the cookies are really dead. I suppose it is > > up to the consumer to return anything it likes, but are people ok with > > (a) after the JSESSIONID cookie expires? > > > > regards, > > > > Isn't JSESSIONID Java servlet specific? I don't think you should start > > giving significance to certain cookies in the protocol if at all > possible. > > > > > > Andre > > > > > > -- > > > > ------------------------------------------------------------------------ > > *David Ward* > > Principal Software Engineer > > Oracle Portal > > Oracle European Development Centre > > 520 Oracle Parkway > > Thames Valley Park > > Reading > > Berkshire RG6 1RA > > UK > > *Email:* > > _david.ward@oracle.com_ <mailto:david.ward@oracle.com> > > *Tel:* > > +44 118 924 5079 > > *Fax:* > > +44 118 924 5005 > > > > > > > > > > > > > > You may leave a Technical Committee at any time by visiting > http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]