It looks like apprunner is having trouble reading all of my cookies file, and then truncates it once it writes to disk. It looks like my cookies file has some end of line problems, but 4.5 can handle it. The before and after files are available at http://slip/projects/dogbert/test/install My 4.5 file is named cookies45.txt and the apprunner file is named cookies5.txt To reproduce: 1. Copy cookies45.txt file into apprunner directory and rename cookies.txt 2. Launch and goto scopus/bugsplat You get an error in authentication (it can't read who I am, though 4.5 can) 3. Login again (paulmac,paulmac). 4. Shut down, and look at cookies.txt It has shrunk down to 2 kb and just a handful of cookies. I copied my 45 cookies file (14kb) into my apprunner working directory

You are right about your cookie file having some end-of-line problems. Every line is terminated with two instead of one line-feed. But that shouldn't cause any problems. I did exactly what you described. I downloaded your cookies45.txt file, renamed it to cookies.txt, and put it in my apprunner directory. Then I fired up the browser and went to scopus. No problems were reported. I then went to the scopus query page and got there. Obviously I was already logged in. And the assigned-to field on the query page was pre-filled with paulmac indicating that I was indeed logged in as you. Furthermore, when I closed the browser the cookies file was indeed updated (the timestamp changed) and the double line-feed problem was gone. But there was no other alteration in the initial and final cookies file -- certainly no truncation. Hmmm -- what are we doing that different? Until someone can determine that, I have to close this bug out as "works-for-me".

hmmm, the same thing happened to me when I followed my own directions. Can you try one more time, only this time grab the file "cookies.txt"? This file seems to show the faulty behaviour.

Yes, indeed this new file shows the faulty behavior. Reopening the bug report.

OK, I now understand what is going on here. Bottom line is that the bug report is invalid. I'll explain why below. First a word on the symptom. It's not exactly as paulmac described. Basically you have to run two sessions of the browser, and visit a site that set's a cookie in each session. If you start the first session with paulmac's cookie.txt file, then after the second session the file gets truncated. In other words, you need to have the browser read, save, read, and save the cookie file twice in order to see the truncation. Seems like a strange behavior so let me explain what is happening. The cookies.txt file that we started with is indeed corrupt -- each line is terminated with lf-lf (i.e., a pair of line feeds). The 5.0 browser always writes out its cookies.txt file to be terminated with cr-lf (under windows that is). So a 5.0 session that reads this lf-lf file will process it just fine and will eventually write it out as a cr-lf file. The truncation occurs when it reads in a cr-lf file and then writes it out again. That is why the problem occurs on the termination of the second browser run. OK, that explains why the second run it needed. But I still haven't explained why the truncation is occurring on paulmac's file -- certainly not all cookies.txt files cause truncation. So let me explain some more. There is a far worse corruption in paulmac's file besides. Several of his cookies have been run together into one big cookie appearing to be from a site called "ity.com" (I'm sure that even that hostname has been corrupted). In fact, so many cookies have been strung together that the resulting big cookie exceeds the max cookie length of 4096. The browser can never write out such a big cookie so this is indeed a bad file. When the browser reads in a file with a cookie exceeding 4096 characters, it simply stops reading the file so it is ignoring all cookies following the big one. That explains the truncation. The browser behaved just fine and didn't even crash considering the disastrous input that it was given. Now this corrupted cookie file is inded interesting for another reason. There was recently a security alert about a site receiving all cookies from a particular user (not just the cookies for that site). Our theory was that the user had a corrupted cookie file with several cookies strung together on one line. But we were never able to get the site to send us the user's file to confirm this. Indeed it looks like paulmac may have just discovered an instance of such a corruption. See bugsplat (i.e., version 4.5) bug report 342724 and 342724.

Oops, my error. The two bug reports I meant to cite above are 342331 and 342724

Okay, I guess my biggest issue here is that despite the horrendous corruption, my 4.5 browser has no problem with it. Is that worth anything? :-) I guess ideally I would want the bad (>4096 character) cookie stripped out and the rest kept. It seems like 4.5 just basically ignores the invalid cookie.

The difference in behavior between 4.5 and 5.0 is the way they terminate lines. As I mentioned, the truncation happens only when the input file has lines terminated by cr-lf. And that is how 5.0 writes out its files. But 4.5 writes out its files terminated with cr-cr-lf (indeed a strange thing to do). And when a file with such a termination is read back in (by either browser), there is no truncation. What you are now asking for (strip out bad cookie and keep the rest) is not that easy to implement (because of the layer at which the error is detected). Furthermore, it is not that useful -- the file is bad so it would be just as reasonable for us to ignore all the cookies (i.e., even the ones preceding the big one). From my point of view, any behavior that doesn't result in a crash is reasonable in this case so why not take the one that requires the least amount of additional work -- i.e., leave it the way it is.

Okay, I will keep my eyes and ears open for people who lose their cookies (or some of them) when upgrading from 4.x to 5.0. If this is a major issue, then perhaps something will have to be done.