php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #67736 setcookie() not updating existing cookies
Submitted: 2014-08-01 14:02 UTC Modified: 2014-08-01 17:10 UTC
Votes:12
Avg. Score:4.6 ± 0.8
Reproduced:9 of 11 (81.8%)
Same Version:7 (77.8%)
Same OS:4 (44.4%)
From: brad at bradb dot net Assigned:
Status: Verified Package: *General Issues
PHP Version: 5.6.0 OS: Linux (Ubuntu)
Private report: No CVE-ID: None
View Developer Edit
 [2014-08-01 14:02 UTC] brad at bradb dot net 
Description:
------------
Multiple calls to setcookie() with the same name are not resulting in the cookie header being updated, but instead appended. So the headers are being returned with multiple cookies of the same name. As there seems to be no standard for which browsers select in this instance, it creates headaches! 

Also reinstalled 5.5.9 and seeing the same issue, again via the Ubuntu package.

It seems to occur with both setcookie() and setrawcookie(). A simple test will show the issue:

Here's the output of the test script.



Test script:
---------------
<?php

setcookie("test", "abc");
setcookie("test", "def");


Expected result:
----------------
HTTP/1.1 200 OK
Date: Fri, 01 Aug 2014 13:46:05 GMT
Server: Apache/2.4.10 (Ubuntu)
X-Powered-By: PHP/5.6.0RC2
Set-Cookie: test=def
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT, HEAD
Access-Control-Allow-Headers: Origin,Content-Type,Accept,Authorization
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8


Actual result:
--------------
HTTP/1.1 200 OK
Date: Fri, 01 Aug 2014 13:46:05 GMT
Server: Apache/2.4.10 (Ubuntu)
X-Powered-By: PHP/5.6.0RC2
Set-Cookie: test=abc
Set-Cookie: test=def
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT, HEAD
Access-Control-Allow-Headers: Origin,Content-Type,Accept,Authorization
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Patches

Fixes-setcookie-to-only-send-one-Set-Cookie-header-per-header-name (last revision 2014-08-31 17:13 UTC by florian at margaine dot com)

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-01 17:10 UTC] tyrael@php.net
-Status: Open +Status: Verified -PHP Version: 5.6.0RC3 +PHP Version: 5.6.0
 [2014-08-01 17:10 UTC] tyrael@php.net 
I think we should fix this.
rfc6265 (latest rfc defining http cookies) states that 
"Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name."
 [2014-09-01 00:19 UTC] Danack at basereality dot com 
(X-posting from PR)

The PHP code does not have a bug. The RFC does not forbid sending multiple cookies with the same name:

"Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. (See Section 5.2 for how user agents handle this case.)"

Although it is definitely not recommended, the RFC does not say MUST NOT.

Even if it was forbidden by the RFC, it is not PHP's job to enforce conformance to RFCs. That is up to the programmer using PHP to not send improper data.

The idea of having setcookie magically modifying the cookie header that is sent is not good. It would be adding more magic behaviour to PHP to cover up the fact that the programmer who is calling setcookie() has a bug in their code.

Adding a warning is enough. It tells people that they are doing something that is probably unwise, but is technically allowed. Doing anything more is not only the wrong thing to do anyway, but introduces a backwards compatibility break for no good reason.

If someone is unaware they are calling setcookie() twice with the same name, the error will alert them and allow them to fix their code.

If someone is deliberately calling setcookie() twice with the same name (e.g. for a legacy application that knows how to handle multiple cookies with the same name) then they will need to continue using the current behaviour.

Changing the behaviour just because it would be a bit 'better' is not a good idea. There needs to be a clear reason for changing the behaviour, and I don't think there is one here.
 [2014-09-08 13:12 UTC] craig at craigfrancis dot co dot uk 
There might be a case with sessions... e.g. if you called session_start() more than once.

While this is not normal, in a high security application you might do a session_start() and a session_regenerate_id(true) when the user logs in... then because of bug 61470, you will need to follow up with a session_write_close() and session_start() as well (important if the login process takes a while, and you need the session file to also act as a lock file)... in this case the "set-cookie" header is sent 3 times.
 [2014-11-10 10:52 UTC] aharvey@php.net 
Related To: Bug #68390
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 17:01:32 2024 UTC