Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Subject: RE: HttpMethodBase::ParseResponseHeaders [Patch]
From: Oleg Kalnichevski <o.kalnichevski@dplanet.ch>
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
In-Reply-To: <718DA1709308D311A6750008C70954E301DD2C13@SCAL10>
References: <718DA1709308D311A6750008C70954E301DD2C13@SCAL10>
Content-Type: text/plain
Organization: 
Message-Id: <1045179772.2220.155.camel@kczrh-okt22.corp.bearingpoint.com>
Mime-Version: 1.0
Date: 14 Feb 2003 00:42:52 +0100
Content-Transfer-Encoding: 7bit

James
I concede you have presented a very convincing case. Besides, you are
right about current implementation not meeting my own interpretation of
the RFC.  

Many thanks for tracking the bug down

Kind regards

Oleg


On Thu, 2003-02-13 at 23:28, Couball, James wrote:
> I would disagree with your interpretation.  RFC2109 states:
> 
> =============================
> 4.3.2  Rejecting Cookies
> 
> To prevent possible security or privacy violations, a user agent rejects a
> cookie (shall not store its information) if any of the following is true: 
> 
> 
>    * The value for the Path attribute is not a prefix of the request-
>      URI.
> 
>    * The value for the Domain attribute contains no embedded dots or
>      does not start with a dot.
> 
>    * The value for the request-host does not domain-match the Domain
>      attribute.
> 
>    * The request-host is a FQDN (not IP address) and has the form HD,
>      where D is the value of the Domain attribute, and H is a string
>      that contains one or more dots.
> 
> =============================
> 
> This says "rejects a cookie" not all the cookies in the header.  I concede
> that the part you quoted can be interpreted the way you did, but I don't
> give it as much weight because it is an 'Examples' section.  If you ask me,
> these examples are inconsistent with the rest of the spec.
> 
> Note that the current implementation follows neither what you nor I are
> proposing.  Instead, it is in the middle.  When there is a validation error,
> some cookies get discarded and some don't.
> 
> In any case, RFC's are nice, but people who write servers tend to specialize
> their cookies to what is accepted by the user agent.  Both IE and
> Netscape/Mozilla have the capability to accept some cookies in the header
> and not others.
> 
> In fact, my application is a screen (html) scraper that depends on being
> logged in.  The site I am scraping (which is very popular -- has many users
> who use the site without cookie problems) does this exact thing where it
> sends two cookies in one set-cookie header: the first for a different domain
> (evil marketing practice) and the second one that contains a session state
> key. 
> 
> I have appended the unidiff of my changes.
> 
> Sincerely,
> James.