cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[ curl-Bugs-3404348 ] COOKIELIST interface producing RFC violation.

From: SourceForge.net <noreply_at_sourceforge.net>
Date: Tue, 06 Sep 2011 22:11:43 +0200

Bugs item #3404348, was opened at 2011-09-05 18:48
Message generated for change (Settings changed) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3404348&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: http
Group: bad behaviour
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Michael Brooks (sitewatch)
Assigned to: Daniel Stenberg (bagder)
Summary: COOKIELIST interface producing RFC violation.

Initial Comment:
It is possible for libcurl to transmit duplicate cookie variable names in a request. No web browser will behave this way and its a rfc 2109 violation. This bug is due to the fact that curl's list of cookies can be set via 2 interfaces. If curl encounters a "Set-Cookie" http header or if curl's cookies are set via the setpot() function.

Curl's detection of a duplicate cookie is based on the combined value of the path/domain/flags set in the cookie. However this approach is flawed, because it is possible to set two cookie values of the same name that are then transmitted in a single HTTP request. An RFC complaint server will interprete the first cookie set, ignoring the duplicate cookie value. (As a result the server will invariably ignore the value that is being set with the setopt COOKIELIST interface.)

when libcurl is determining the "Cookie:" HTTP header for a request and additional check should be made to look for two cookie values of the same name and only choose to set one. From the programmers perspective the setopt() should always supersede any other state, thus giving the user of the library full control. This should happen so long as the setopt()'ed cookie has a valid domain and path for this request, even if this domain/path differs from the one set via a "Set-Cookie:" HTTP header.

The following temporary fix mitigates the issue, however it is a dirty dirty hack:

  def removeDupeCookies(self):
    cook={}
    cookies=self.c.getinfo(pycurl.INFO_COOKIELIST)
    rebuild=False
    for c in cookies:
      ce=c.split("\t")
      if ce[-2] not in cook:
        cook[ce[-2]]=c
      else:
        rebuild=True
    if rebuild:
      self.c.setopt(pycurl.COOKIELIST,"ALL")
      for k in cook:
        self.c.setopt(pycurl.COOKIELIST,cook[k])

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-09-05 19:45

Message:
First, the cookie RFC we should follow is RFC6265
(http://tools.ietf.org/rfc/rfc6265.txt) RFC2109 has never been followed by
clients or browsers.

Second, sure browsers can send duplicate variable names. If there are
cookies from multiple paths/domains that match, they can (and will) be sent
in the same request.

This taken together, your bug report doesn't make a lot of sense to me.
You have not pointed out a bug here that I agree is a bug.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3404348&group_id=976
Received on 2011-09-06

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET