Oleg, I agree with your argument. If a header is malformed then we definitely want to stop processing it, e.g., set-cookie: name=ds;sdsd;dsdsd=094034k;''"";dasd;ds=fsdflsjfslfjlfs0449894 .....
However, the current code does not make any difference between malformed cookies and cookies that are well-formed but there is a problem in parsing an attribute. It throws a MalformedCookieException in all cases. A header is malformed in the following cases: 1. cookie name/value is null or "" 2. cookie attribute name does not match any known attribute. Although the RFC does not talk about this, there might be other cases when a header should be considered malformed and rejected entirely, such as, if a cookie attribute value is too long or occurs too many times. Otherwise, if there is a problem in parsing a cookie attribute value, we continue processing other cookies. Another thing I had in mind is accepting old-style cookies. As per RFC 2965, an old-style cookie should be parsed and formatted according to old rules (section 9.1). I am pretty sure the validation and matching for these cookies should also take place as per old rules. Samit On 8/13/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
