Samit and Odi, Here's my take for what is is worth. I looked at the problem a while ago and concluded that trying to recover some of the cookies from a malformed Set-Cookie was too much of a trouble with very little practical gain. First off, if a Set-Cookie is malformed at some point, that is cannot be parsed in an unambiguous manner, it is just not reasonable to carry on parsing beyond that point, because there's a good chance to get the rest of the cookies wrong. It is more prudent in my opinion to reject the header altogether. This said, one must differentiate malformed Set-Cookie headers from invalid cookies. One should not reject the entire Set-Cookie if only some of its cookies are invalid (that is, they are well formed, but contain invalid attribute values). The existing cookie specs already operate in this manner.
Oleg On Sat, 2005-08-13 at 08:13 +0000, Samit Jain wrote: > Hi, > > Currently HttpClient rejects the Set-Cookie header entirely if there > is a problem in parsing one of the cookies in the header. I doubt if > it is the right behavior for old or new specification. I think if > there is a problem in parsing a cookie, only that cookie should be > rejected. Any suggestions on this? I am going to implement it this way > for RFC 2965. > > -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]
