cookies file being truncated

VERIFIED INVALID

Status

()

Core
Networking: Cookies
P3
normal
VERIFIED INVALID
19 years ago
19 years ago

People

(Reporter: Paul MacQuiddy, Assigned: Stephen P. Morse)

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 1

19 years ago
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".
(Reporter)

Comment 2

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Assignee)

Updated

19 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 3

19 years ago
Yes, indeed this new file shows the faulty behavior.  Reopening the bug report.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: WORKSFORME → INVALID
(Assignee)

Comment 4

19 years ago
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.
(Assignee)

Comment 5

19 years ago
Oops, my error.  The two bug reports I meant to cite above are 342331 and 342724
(Reporter)

Comment 6

19 years ago
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.
(Assignee)

Comment 7

19 years ago
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.
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

19 years ago
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.
You need to log in before you can comment on or make changes to this bug.