>Number: 2370 >Category: mod_usertrack >Synopsis: Duplicate cookies with same name, different domain >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sat Jun 6 20:50:01 PDT 1998 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.3.0 >Environment: gcc 2.8.1, SunOS 4.1.3_U1 >Description: I changed mod_cookie in 1.2.x to write "visit=" instead of "Apache=" to conform with other visit cookies being written by other servers and provide improved log analysis across platforms. So before compiling 1.3.0, I made the same change: #define COOKIE_NAME "visit=" However, it appears that mod_usertrack doesn't provide a domain= value in the Set-Cookie header where 1.2.x did (this is by inference) as after testing 1.3.0, I find I have two visit= cookies. One is set to domain=glenns.org and another to domain=www.glenns.org.
However, the code at spot_cookie should get a Cookie header from my browser for glenns.org *and* for www.glenns.org. That is, the previously set "visit=" cookie should have been sent by the browser, and Apache should have recoginzed it and not written a new one. Am I encountering a browser bug about when the Cookie header is sent? This is a funny one to test as I'd have to keep stopping and starting servers and I'm in enough of a production environment to not be able to do that. Or has behavior changed between 1.2 and 1.3 and it's a problem? >How-To-Repeat: Currently, http://www.glenns.org uses Apache 1.2.x to set cookies for www.glenns.org. >Fix: If spot_cookie is broken (which it doesn look like it is), that should be debugged. If it's browser behavior, it should be documented. Also, it would be great if you could specify domain= value via a configuration directive or at least via a variable in mod_usertrack. >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
