hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: rejecting cookie header
Date Sun, 14 Aug 2005 18:26:00 GMT
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 <olegk@apache.org> 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: httpclient-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> > >
> > >
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message