OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] initCookie



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

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]