#337 Load of Cookies with same name on same request wrong


If you have a HTTP request that does a Set-Cookie for a Cookie with the same name multiple times then it is impossible to retrieve these different values using the:
LOAD RESPONSE_INFO HEADER ON <conid> INTO <cookievar>, WITH "Set-Cookie,<cookiename>"
syntax - you will always just get the value from the first occurrence of the Set-Cookie. This behavior is especially bad because the latest instance in the HTTP headers should override the earlier ones according to the original Netscape spec and the way all tested browsers work.

The only current workaround is to not use the ',WITH "Set-Cookie,<cookiename>"' clause and therefore load all the HTTP headers into a variable that you can parse yourself.

You might also want to talk to your Web application authors about the reasoning for setting the same Cookie multiple times - occasionally it makes sense, mostly it doesn't.

Code should definitely be changed so latest instance is picked up rather than first, but a full solution would require expanding the ',WITH "Set-Cookie,<cookiename>"' clause syntax so that you can further specify which Set Cookie header you are interested in bearing in mind order, path, etc.


  • Daniel Sutcliffe

    • summary: Load of Cookies with same name on same connection wrong --> Load of Cookies with same name on same request wrong
    • status: open --> open-accepted
  • steve2k

    steve2k - 2007-08-14

    Logged In: YES
    Originator: NO

    I came across this problem and did some research a couple of months ago.

    RFC 2109 says
    "If a user agent receives a Set-Cookie response header whose NAME is
    the same as a pre-existing cookie, and whose Domain and Path
    attribute values exactly (string) match those of a pre-existing
    cookie, the new cookie supersedes the old."

    So it sounds like your first solution would be in line with the RFC.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks