On 28/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > On Mon, 2008-10-27 at 23:10 +0000, sebb wrote: > > On 27/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > On Mon, 2008-10-27 at 20:13 +0000, sebb wrote: > > > > On 27/10/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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/> > > > >obv > > > > > > > > > > > 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.
By reject, I meant it should throw an Exception or at least log an error. > > > 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. Indeed. > What kind of solution would you be comfortable with? > Any solution so long as RFC2965 does not treat Set-Cookie as if it were a Set-Cookie2. That seems wrong to me, because of the different domain rules. It can throw an exception or treat the cookie as Netscape and/or RFC2109. I think throwing an exception is better, as otherwise there is effectively no difference between RFC2965 and BestMatchSpec. Question is: if someone chooses to use a specific spec rather than BestMatch - what are they expecting to happen? If you choose RFC2109 and a Set-Cookie2 header arrives, what happens? I think the code needs to be consistent in how it handles cookies that are compliant with a different spec. from the one selected; seems to me throwing an exception may be the most useful. > > Oleg > > > > > Oleg > > > > > > > > > > S/// > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
