Bugs item #3404495, was opened at 2011-09-05 17:04
Message generated for change (Comment added) made by sitewatch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3404495&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: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Brooks (sitewatch)
Assigned to: Daniel Stenberg (bagder)
Summary: COOKIELIST producing invalid cookie.

Initial Comment:
To recreate this bug:

1)A web application sets a cookie using:
set-cookie: lang=en;

2)A programmer tries to modify this value using using setopt(), the only difference is the PATH part of the cookie. (the paths overlap such as / and /form/ but the variable name is identical)
'localhost\tFALSE\t/\tFALSE\t0\tlang\tgr'

The malformed HTTP request:
Cookie: lang=en; PHPSESSID=jnkgarlbkqmg0i9bruds97kof3; lang=gr;

This cookie value CAN NEVER HAPPEN IN A BROWSER. But more importantly why would a programmer want this? How is this behavior useful? As a user of your software i just want to modify this cookie value, but the end result is that whatever value i set is ignored because all web application platforms just pick the first cookie value. This is clearly broken.

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

>Comment By: Michael Brooks (sitewatch)
Date: 2011-09-05 18:00

Message:
So yes, I am extracting the cookie with getinfo looping though the list
until i find the cookie variable i want and then modifying this cookie
value string and then using setopt to modify it. If this value doesn't
exist in getinfo then I create a new cookie with the root path and set it
for the entire domain (Yeah I have hopes and dreams).

In this condition that this is the first page fetch against this php file
then its reset and my the setopt() value is ignored (again).

So what I'm hearing is that every web application programming langue is
wrong and that you library is the only true implementation of HTTP. This
interface is a total and complete train wreak that is not only time
inefficient O(N), its usage is by no means obvious, and to top it off its
incomparable with absolutely everything.

IMHO this is how it should have been from the beginning:
setopt(COOKIELIST,"lang\nen")
Who gives a fuck about the rest?

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-09-05 17:44

Message:
Sorry, but I don't have/run any PHP here so I cannot easily "just throw it
into" actually.

The cookie you receive from the server is under the path "/form/" while
the cookie you set with COOKIELIST is set for the path "/". They will be
treated as two different cookies and if your site would set them so, they
would be treated differently by all browsers as well. As the cookie RFC
clearly details. Where is the section that says you cannot send two cookies
using the same name?

The HTTP request is not malformed due to this. It isn't what you want,
sure, but it isn't malformed.

You probably want to set your replacement cookie for the same path as you
set the original cookie. You could also extract the exact cookie from
libcurl first with curl_easy_getinfo() or what the PHP equivalence is, as
then you'd know exactly how the cookie looks and it would be much easier to
replace the contents.

I still don't see a bug here.

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

Comment By: Michael Brooks (sitewatch)
Date: 2011-09-05 17:35

Message:
Sorry, i don't mean to be inflammatory i am just frustrated. I don't have
a url this is all localhost. But you can use this code just throw it into
/form/index.php:

<?php
setcookie("lang", "en");
print($_COOKIE['lang']);
?>

Now, try modifying this cookie value with this string:
'localhost\tFALSE\t/\tFALSE\t0\tlang\tgr'

With curl fire off a get request against the page, $_COOKIE['lang'] will
remain unchanged because PHP is looking at the first cookie value. You can
see the HTTP request header is malformed by using wireshark.

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-09-05 17:28

Message:
First, thanks for providing feedback to help us improve things.

Sure, you want a feature: to easily replace a particular cookie.

The COOKIELIST interface is not the most convenient for this, as you need
to know details about the existing cookie in order to replace it properly.
This does however not say that you've found a bug in the existing interface
unless you can tell us how to repeat such a bug. I've not seen this yet.

Discussions for how to do things better and/or provide a better interface
should be held on the curl-library mailing list and not the bug tracker.

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

Comment By: Michael Brooks (sitewatch)
Date: 2011-09-05 17:19

Message:
In step 1 the file is in /form/index.php and its being set for /form/

But at the end of the day i know i have a cookie with the variable name
"lang" (who cares about the path and flags?) And i just want to set it to
a different value, this should be easy and it should never duplicate the
value.

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-09-05 17:14

Message:
Please help us repeat this instead of getting hostile.

First, what's the URL of the site that sets the cookie in step (1) ?

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

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