[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    Re: svn commit: r708225
From:       sebb <sebbaz () gmail ! com>
Date:       2008-10-29 12:52:38
Message-ID: 25aac9fc0810290552j47fb563dl1e38baff1950fd98 () mail ! gmail ! com
[Download RAW message or body]

On 29/10/2008, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Wed, 2008-10-29 at 00:28 +0000, sebb wrote:
>
>  > 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.
>  >
>
>
> All right. I changed the RFC2965 to reject Set-Cookie headers as
>  unrecognized. When RFC2965 is used as a standalone cookie policy
>  HttpClient will log a warning message for all cookies the spec fails to
>  recognize.
>
>
>  > 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?
>
>
> Browser compatible and Netscape specs will ignore Set-Cookie2 headers.
>  RFC2109 will reject them as unrecognized.
>

Thanks, that's all good.

>  Oleg
>
>
>  >  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: 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
>  > >
>  > >
>  >
>  > ---------------------------------------------------------------------
>  > 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

[prev in list] [next in list] [prev in thread] [next in thread]