Re: [wsrp] initCookie

[Subbu Allamaraju <subbu@bea.com>]

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
> 
>