https://issues.apache.org/bugzilla/show_bug.cgi?id=55278
--- Comment #4 from Mikhail T. <[email protected]> --- Created attachment 30633 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30633&action=edit 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? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
