hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samit Jain <jain.sa...@gmail.com>
Subject Re: rejecting cookie header
Date Sat, 13 Aug 2005 21:08:50 GMT
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


Mime
View raw message