Haxx ad

curl's project page on


cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[ curl-Bugs-3349227 ] secure attribute in cookie does not work with equals sign

From: <>
Date: Sun, 03 Jul 2011 14:29:41 -0500

Bugs item #3349227, was opened at 2011-07-01 20:05
Message generated for change (Comment added) made by gnombat
You can respond by visiting:

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: libcurl
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gnombat (gnombat)
Assigned to: Daniel Stenberg (bagder)
Summary: secure attribute in cookie does not work with equals sign

Initial Comment:
If an HTTPS server marks a cookie as secure with the "Secure" attribute, and it uses an equals sign, curl does not recognize the cookie as secure. This is best illustrated with an example: suppose the server returns the following 2 headers:

Set-Cookie: secure_without_equals=1; secure
Set-Cookie: secure_with_equals=1; secure=

Then suppose the server is accessed with curl:

curl --cookie-jar cookies-curl.txt https://SERVER

The resulting cookie jar is as follows:
... FALSE / TRUE 0 secure_without_equals 1
... FALSE / FALSE 0 secure_with_equals 1

With most other browsers and HTTP clients, both cookies are treated as secure. For example, with wget:

wget --save-cookies=cookies-wget.txt --keep-session-cookies -q -O- https://SERVER
... FALSE / TRUE 0 secure_with_equals 1
... FALSE / TRUE 0 secure_without_equals 1

This appears to be a problem in real-world applications; e.g., Microsoft servers sometimes return a Set-Cookie header with "secure=" in it.

$ curl -V
curl 7.21.7 (i686-pc-linux-gnu) libcurl/7.21.7 OpenSSL/0.9.8k zlib/ libidn/1.15
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM SSL libz


Comment By: gnombat (gnombat)
Date: 2011-07-03 14:29

Regarding the RFC:

The grammar in section 4.1.1 seems to allow only "Secure" (without

However, section 5.2 seems to allow equals with a "possibly empty"
attribute value?

   The user agent MUST use an algorithm equivalent to the following
   algorithm to parse the unparsed-attributes:


   4. If the cookie-av string contains a %x3D ("=") character:

          The (possibly empty) attribute-name string consists of the
          characters up to, but not including, the first %x3D ("=")
          character, and the (possibly empty) attribute-value string
          consists of the characters after the first %x3D ("=")


Comment By: gnombat (gnombat)
Date: 2011-07-03 14:13

How is this for a "live" example? :)

You will need an actual Microsoft "Live ID" (or whatever they are calling
it these days). Enter a valid ID and password and then submit. The actual
request leads to about half a dozen redirections, but only the initial POST
is the interesting one. It sets a cookie named WLSSC, which is apparently
intended to be secure.

As far as browsers go, I tested Firefox, IE, Opera, Chrome, and Safari,
and they all seem to treat "secure=" as equivalent to "secure".


Comment By: Daniel Stenberg (bagder)
Date: 2011-07-03 12:24

Wonderfully non-compliant with the rather new RFC6265. Can you please give
me an example of an actual live and public web page that uses such a cookie

Do most browsers handle this?


You can respond by visiting:
Received on 2011-07-03

These mail archives are generated by hypermail.

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

File upload with ASP.NET