On Wed, Aug 10, 2005 at 03:02:18AM +0000, Samit Jain wrote: > Hi all, > > Just a few questions ... > > 1. If we receive a Set-Cookie and Set-Cookie2 headers in the same > response, then should we ignore the Set-Cookie header entirely? This > is the current behavior of HttpMethodBase which processes response > headers. However the spec says - > User agents that receive in the same response both a Set-Cookie and > Set-Cookie2 > response header ''for the same cookie'' MUST discard the Set-Cookie > information and > use only the Set-Cookie2 information. > I think we should change the HttpMethodBase implementation as per the > spec and ignore Set-Cookie header only for the same cookie. Also, the > spec doesn't clarify what "same cookie" means. Does it mean cookie > names match, or does it mean cookie names, paths and domains must > match? I go with the latter.
+1 from me. > > 2. The current implementation does not handle cookie matching > specificity -- "more specific cookies (as per path attribute) should > appear first in request header". Although I am implementing this > feature for RFC 2965, I was thinking of including this in other cookie > spec implementations too since older specs (rfc 2109, not sure abt > others) also mention this. What do you think? > I think it does (or does attempt to do so): http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/cookie/CookieSpecBase.html#555 Improvements are welcome, though > 3. A very small optimization - When we can HttpState for matching > cookies, we can get rid of expired cookies from HttpState object. This > is not really required since there will be very few cookies expiring > in a single session. I agree with Roland. I also lean towards keeping cookie matching and eviction of expired cookies from the HttpState as separate concerns Oleg > > Please give ur suggestions. > > thanks, > Samit > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
