Samit, Makes sense to me. Go for it if there's still some capacity left. However, I do think you should stop hacking on non-essential features and concentrate on stablising the exiting code. There's only a couple of weeks left before the deadline.
Oleg On Sat, 2005-08-13 at 21:08 +0000, Samit Jain wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
