We noticed the odd, if not particularly dangerous behavior of mod_session. The relevant configuration is thus: <Location /> Session On SessionCookieName ti2f path=/ # This is the file containing users login data SessionHeader -TI-Replace-Session SessionCryptoPassphrase ... SessionCryptoCipher aes256 SessionEnv on </Location> The response-headers, sent to a cookie-less request look like this: 200 OK Cache-Control: no-cache Connection: close Date: Thu, 18 Jul 2013 17:12:19 GMT Server: Apache/2.4.4 Content-Type: text/html Client-Date: Thu, 18 Jul 2013 17:12:19 GMT Client-Peer: 10.89.8.68:14443 Client-Response-Num: 1 Set-Cookie: ti2f=;Max-Age=0;path=/ Set-Cookie: ti2f=;Max-Age=0;path=/ Note, the identical Set-Cookie header repeated twice. With empty session string and Max-Age of 0...
Can you clarify which parts are a problem? The duplication needs to be avoided obviously, however setting the cookie to the empty string and setting the max-age to zero is the intended behaviour to delete any previous cookie that may have lingered. HTTP is stateless, and therefore no assumptions are made about previous state of the cookie.
I would say, if there was no cookie presented in the request, then it can be assumed, there is nothing lingering, can it not?
Even more, perhaps... Even if there was a session-cookie already in the browser, if the server-side processing (CGI, script, whatever) did not attempt to modify the session, then there should not be an attempt to reset the cookie. Absence of the session-overwriting header should not be treated the same as presence of an empty header, in my humble opinion.
Created attachment 30633 [details] Only save a session, if marked dirty Reading the session_output_filter(), it appears, that the ap_session_save() is invoked unconditionally -- regardless of whether the session was dirtied or not. Indeed, in the following test: % HEAD -H 'Cookie: fooCookie=O+eAXvYAEeKrG12oGlPfTANDHqG59FO/1krx29xnST4C+Tb+gEU7OCmh7edH87xptVCL9sQyyHEujTp4LAWVWxJmHwLmCVZfdDE+A9vZV0oQma95C4A+YgSGPhuRoceK' 'http://example.com/foo/ we always see a new Set-Cookie header in the response -- even though nothing on the server side changes the data in our setup. Indeed, the newly-set cookie always decrypts to the same string as what we've already supplied -- defeating the purpose of the "dirty" flag completely, it seems. This patch attempts to fix things... The result "works" for our limited scenario where we set the cookie ourselves -- from a PHP script and only use mod_session to decrypt and parse it so it can then be used by mod_auth_form. But, it seems to be correct in all cases -- ap_session_set will set the dirty flag and so will the processing of the SessionHeader now. There is no need to rewrite the session in any other case, is there?
I can confirm this behaviour, including the steady renewal of of the session key for: Apache 2.4.6 and mod_session_db. My config: ... DBDriver sqlite3 DBDParams "/apache/db/db.db" DBDPrepareSQL "delete from session where key = %s" deletesession DBDPrepareSQL "update session set value = %s, expiry = %lld where key = %s" updatesession DBDPrepareSQL "insert into session (value, expiry, key) values (%s, %lld, %s)" insertsession DBDPrepareSQL "select value from session where key = %s and (expiry = 0 or expiry > %lld)" selectsession DBDPrepareSQL "delete from session where expiry != 0 and expiry < %lld" cleansession <VirtualHost *:80> ServerName vfolin.pnet.ch RewriteEngine On ... <Location /secured> <RequireAll> Require valid-user </RequireAll> AuthFormProvider file AuthType form AuthName "Reserved Area" Session On # This is the login page ErrorDocument 401 /login-inline.html # This is the file containing users login data AuthUserFile conf/passwd SessionDBDCookieName session path=/ SessionHeader X-Replace-Session </Location>
Cannot verify the comments about empty cookie, but can verify that 2.4.10 inserts duplicate cache and cookie headers
I confirm this is happening, I'm having the same issue. < HTTP/1.1 302 Found < Server: nginx < Date: Sun, 11 Oct 2015 19:16:59 GMT < Content-Type: text/html; charset=iso-8859-1 < Content-Length: 211 < Connection: close < Set-Cookie: session=;Max-Age=0;path=/ < Location: /login.html < Cache-Control: no-cache < Set-Cookie: session=;Max-Age=0;path=/ < Age: 0 Two Set-Cookie headers. Anf this is causing auth_form not working, This bug report is from 2013 and it is still happening!
Qlready tried the patch attached to this page, and my httpd segfaults, had to revert. httpd-2.4.16
I'm seeing the same duplicate Set-Cookie header behavior with mod_session on apache 2.4.38-3 (debian unstable) today. Can the fix for this 6-year-old issue get applied? or if it's wrong, can someone at least explain why it's wrong and what would need to be done to fix it?
2024 now, still an issue... set-cookie is sent twice on every single request Version 2.4.55