8

I am debugging an issue with a Magento system.

The problem is a duplicated Set-Cookie header, like this:

Set-Cookie: flimmit_session=search-0c30086b812519b006aa27ef4f37f15b-24; path=/; domain=.flimmit.com; httponly
Set-Cookie: flimmit_session=search-0c30086b812519b006aa27ef4f37f15b-24; path=/; domain=.flimmit.com; httponly

The cookie is set using php's setcookie command. My question is whether the incorrect use of this function can result in a duplicate Set-Cookie header, or whether I have to look somewhere else for the error...

The Surrican
  • 29,118
  • 24
  • 122
  • 168
  • Even if this function is used incorrectly, a doubled cookie header *shouldn't* cause any problems; the second will simply overwrite the first. – deceze Sep 13 '11 at 13:36

1 Answers1

9

Yes, calling setcookie() twice with the same data will result in 2 identical Set-Cookie: headers. I have just tried it, and it does.

It shouldn't cause a problem though, the cookie will always have the value defined by the last setcookie() call...

DaveRandom
  • 87,921
  • 11
  • 154
  • 174
  • so by http standard headers may be defined multiple times and the lat occouring value is used? – The Surrican Sep 13 '11 at 13:46
  • 4
    @Joe Read the last paragraph of [RFC2616 Section 4.2](http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2). There is nothing that says specifically that duplicated values will be overwritten by the later value, that is simply how browsers handle it (just been playing with it and it's definitely how IE8, FF3, Chrome and Safari all handle it). As a general rule this is true of anything like this - if you set the same GET or POST parameter twice, the later value will be used by both PHP and ASP, at least. – DaveRandom Sep 13 '11 at 13:50
  • @DaveRandom Have you tried to delete a pre-existing cookie and create it again with a new value, in this order, but in the same response? I say that there is no 100% sure way to define what will happen. – Ashnur Nov 06 '11 at 12:57
  • @Ashnur Indeed, there is no 100% sure way to determine how any client will handle any response where the same cookie is set twice with two different values (after all, deleting a cookie is still setting a cookie, just setting it with a null value and an expiry time in the past). Any half-way sane client will do what you would "expect" - the later values override the earlier ones - but since no standard defines how this eventuality should be handled, it is open to interpretation and any given behavior should not be relied upon... – DaveRandom Nov 06 '11 at 17:53
  • 1
    @DaveRandom I think that the real problem is that we can not be sure which values are the latter ones. – Ashnur Nov 07 '11 at 10:22
  • 1
    @Ashnur I take your point. I was referring to the "later" one in the context of "the one that appears later in the response" because of the way any sane HTTP message parser would behave, but it cannot be assumed that a second call to `setcookie()` will result in the second `Set-Cookie:` header appearing "later" in the headers, neither can it be assumed that the receiver of the message is sane. All of these are yet more reasons why cookies should not be relied on for anything important, ever. Also an example of how insufficient standards breed ambiguity, and ambiguity breeds confusion. – DaveRandom Nov 07 '11 at 11:52
  • @DaveRandom I just hesitate to ask on php internals why this behavior is still possible (it mess with AsyncHttpClient), and the I re-read the section " The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded." headers with the same name order is significant, if browsers interpret only the last one is due to the fact the value is not formatted as a list and thus could not be continued on the second value – Benoit Feb 12 '13 at 10:31
  • Very much contest the "it shouldn't cause a problem" point, [RFC 6265](http://tools.ietf.org/html/rfc6265#section-4.1.1) says "Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name" and I've been hit hard by misbehaved proxies and clients before. – Brad Koch Jul 26 '14 at 01:17
  • Note: We had a problem whilst using Java HttpClient to talk to a php webapp. We could not authenticate correctly. Turns out the cookie manager was using the first Set-Cookie: header and ignoring anything after the first. No solution found yet, will attempt to stop the server sending this twice... – Liam Mitchell Oct 12 '15 at 02:08
  • 1
    1 in 10 requests in Internet Explorer 11, the last Set-cookie does not take precedence, but some random other. The solution is to register for before send headers callback, header("Set-Cookie", true /*replace*/) for the first good cookie, then send all other good cookies (in case cookie name is the same, but data differs). Do not send the bad cookies. – oxygen Jan 22 '16 at 11:03
  • 1
    I just tested sending the same cookie with different values and the same parameters. The browser chooses one of the same cookies at random. This is a big problem. You should only send one cookie with the same name. – machineaddict Jun 03 '16 at 08:10
  • Does unseeting the cookie with setcookie( 'name', null) before setting it help? – Jakob Alexander Eichler Oct 04 '19 at 13:48