User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 We have migrate our java servers recently. Before, the servers use a session's cookie named sessionidG1P1, whose value is a string of 23 characteres (for example A14TEFIABPA2QCTQOQNY5NQ). Now, we use the session's cookie named JSESSIONID, whose value is a string of 27 characters (for example 00002IAR32W5AIU2TTYOLFXQIPY), but the server add an application's id, used by dispatching softawre. The session's cookie is : 00002IAR32W5AIU2TTYOLFXQIPY:u2viriuj, u2viriuj is the application's id. There is no problem whith Mozilla 1.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826). Reproducible: Always Steps to Reproduce: Ask for me at email@example.com, because a password is needed. Actual Results: Our application can't get the session's cookie, so we send the client to an error page
Can you please attach a cookie log for this. That would show us immediately what the problem is. See nsCookies.cpp for instructions on generating a cookie log.
Hello Mr Morse, I have made some tests and have detected the problem. It is not the ":" charactere ! Sorry for my mistake ... Before the tests, i have set the following variables : NSPR_LOG_FILE=/home/seb/mozilla_x.log NSPR_LOG_MODULES=cookie:4 The results are in files mozilla_1.log and mozilla_2.log. The first file, mozilla_1.log is made with the path of the session's cookie JSESSIONID at /g1. When we use the application, a software dispatcher forward the client to a new path, for example /g1_e, so Mozilla 1.2b don't send the cookie JSESSIONID (older version of Mozilla don't make this), and we have an error page. The sesond file, mozilla_2.log is made with the path of the session's cookie JSESSIONID at /, and now, Mozilla 1.2b work as same as older versions. Best regards.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
Problem was a faulty path test that we used to make which was letting this error from the website slip through. Basically we were testing for a correct path by matching only the beginning of the path name, so that path g1 would match with path g1_e. That was obviously a flawed test and was corrected in bug 166218.
You need to log in before you can comment on or make changes to this bug.