Hi Samit, > 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.
Good Reading. I've been over the same section two or three times before and didn't notice this. > I think we should change the HttpMethodBase implementation as per the > spec and ignore Set-Cookie header only for the same cookie. Agreed. > 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. So do I. RFC 2109, section 4.3.3 specifies this kind of comparison. So does RFC 2965, section 3.3.3. > 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? If you can do that, great! I thought the order was specified only in RFC 2965. I guess I must improve my (spec) reading skills :-) > 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. Cookie expiration is a separate functionality and, in my opinion, should be kept separate. There may be more issues than one might think, starting with the question whether the system time is the accurate source of time information. cheers and thanks, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
