hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: svn commit: r708225
Date Tue, 28 Oct 2008 14:36:13 GMT
On Mon, 2008-10-27 at 23:10 +0000, sebb wrote:
> On 27/10/2008, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Mon, 2008-10-27 at 20:13 +0000, sebb wrote:
> >  > On 27/10/2008, olegk@apache.org <olegk@apache.org> wrote:
> >  > > Author: olegk
> >  > >  Date: Mon Oct 27 09:08:27 2008
> >  > >  New Revision: 708225
> >  > >
> >  > >  URL: http://svn.apache.org/viewvc?rev=708225&view=rev
> >  > >  Log:
> >  > >  Fixed broken #parse(HeaderElement[], CookieOrigin) method in the RFC2965Spec
cookie spec
> >  > >
> >  >
> >  > <snip/>
> >  >
> >
> >  >
> >  > This does not look right - the header is using Set-Cookie, not Set-Cookie2
> >  >
> >
> >  Sebastian
> >
> >  I have not yet gotten around to fixing the Best-Match policy. When
> >  RFC2965 is used standalone, however, it think it should treat Set-Cookie
> >  and Set-Cookie2 consistently, but I am open to alternative ideas
> >
> 
> But the test is in the BestMatchSpec test class...
> 
> It should be checking that Set-Cookie does not create a SetCookie2 and
> that the default host is "localhost". At present it just confirms the
> incorrect behaviour.
> 

I just committed a fix for the bug


> I'd suggest fixing the test, and commenting it out until Best-Match is fixed.
> At least then it would clear what the eventual intention is.
> 
> Also, I don't think that RFC2965 used alone should treat Set-Cookie
> headers as if they were Set-Cookie2. Seems to me it should either
> reject such headers entirely,

RFC2965 implementation rejects old style Set-Cookie header if there is a
corresponding Set-Cookie2 header for the same cookie. However, according
to my understanding of the spec one should not discard Set-Cookie
headers indiscriminately.

>  or process them according to the RFC2019
> spec.
> 

The trouble is that there is no mentioning of RFC2109 compatibility in
RFC2965. The spec implies that Set-Cookie headers should be handled as
Netscape compatible. As we already discovered this can mean different
things to different people. I would really prefer to not pollute
RFC2965Spec with Netscape specific checks. I believe composite
CookieSpec implementations such as BestMatchSpec is a better solution to
the cookie compatibility problem.

What kind of solution would you be comfortable with?

Oleg

> >  Oleg
> >
> >
> >  > S///
> >  >
> >  > ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >  > For additional commands, e-mail: dev-help@hc.apache.org
> >  >
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >  For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 


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


Mime
View raw message