Closed Bug 24033 Opened 26 years ago Closed 25 years ago

'Set-cookie:' HTTP header is somehow pushed into the content model.

Categories

(Core :: DOM: HTML Parser, defect, P1)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: 3jrgm, Assigned: jud)

References

(
URL
)

Details

(Whiteboard: [PDT+] w/b minus on 03/03)

Attachments

(11 files)

screenshot; note 'Set-cookie: BUGLIST' at top of page
88.12 KB, image/jpeg
Details
screenshot; this one shows 'Set-cookie:' and the top banner repeating again (in fact the entire page is restarting at this point)
100.90 KB, image/jpeg
Details
Screen shot that displays a fine loading :)
104.81 KB, image/jpeg
Details
interruption after a completed cell, at left edge
32.78 KB, image/png
Details
interruption after a completed cell, scrolled a bit to the right
25.38 KB, image/png
Details
interruption in the middle of a cell
32.22 KB, image/png
Details
interruption after a completed row
27.56 KB, image/png
Details
possible fix, please try this patch out.
1.47 KB, patch
Details | Diff | Splinter Review
TCP trace of relevant HTTP connection
318.41 KB, application/octet-stream
Details
proposed fix
1.49 KB, patch
Details | Diff | Splinter Review
fix
5.88 KB, patch
Details | Diff | Splinter Review
This bug is a spin off from bug 21013. That bug has morphed quite a bit. This is really the same bug that was originally reported, and it seemed a good idea to open this one NEW. (But see that bug for the history if necessary). Overview Description: 'Set-cookie:' HTTP header is somehow pushed into the content model. Steps to Reproduce: 1) Use this URL ... http://bugzilla.mozilla.org/buglist.cgi?chfield=%5BBug+creation%5D&chfieldfrom= Dec+5+1999&chfieldto=Dec+11+1999 ... which is all bugs created between Dec 5 and Dec 11 1999 a) it will result in the same bug list everytime it is called. b) it will return (6 * 648) = 3888 bytes for the cookie value (Bugzilla will not send more than 4000), which is the practical maximum for the size of a cookie 'in the wild' (I believe). 2) This will crash about 50% of the time for me; Otherwise, the page loads completely normally. (Note: I am on dialup (28.8K) which may be a factor). If it doesn't crash the first time, then set focus in the URL bar and hit ENTER to reload. It should crash eventually. Expected Results: URL should load (note that it is 'multipart/x-mixed-replace') Actual Results: The first part "Please stand by" displays, and then as the second part comes in the 'Set-cookie:' header will be displayed at the top of the screen. After that: o Sometimes it crashes immediately, othertimes on 'out-of-memory'; o Sometimes the crash is in GKHTML.DLL, othertimes in XPCOM.DLL; o the layout can vary for different crashes (but content is repeated multiple times on the page. I think the key point is that an HTTP header is displayed on the canvas -- how did it get into the content model? :-] (After that, all bets are off on what the rest of Layout will do..) Additional Builds and Platforms Tested On: (win95 2000011108 and 200011408). Additional Information: This seems timing dependent, and may also depend on having a slow link (e.g., modem) harishd: I'm not sure which of the HTTP channel (necko), Parser or something in the content sink goes wrong, but if you can get the 'Set-cookie:' header to display at the top of the page, you should be able to see what's wrong.
OS: Windows 95 → All
I occasionally see this same thing on Linux builds, including a cvs build from today. Every time it happens, it's on the bug list page where there is a large list of bugs. It doesn't happen on the URL posted though. It also doesn't happen every time I go to a bug listing that caused the problem previously. Changing platform to "All" because this isn't a Windows only problem.
Priority: P3 → P1
Target Milestone: M14
I was neither able to see the crash nor the "Set-cookie" message!!! janc??
Unable to reproduce. Marking bug WORKSFORME.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
I am able to reproduce this every time on a CVS build today by doing a bugzilla query for RESOLVED DUPLICATE bugs. to reproduce: go to the bugzilla query page and select RESOLVED for status and DUPLICATE for resolution submit the query
Status: RESOLVED → REOPENED
Terry, will you take a look at this bug? It seems to occur only on bugzilla and has something to do with cookies and I'm told that you had said something about bugzilla pushing the browser cookie limit. Perhaps you have some input?
Resolution: WORKSFORME → ---
pretty certain terry doesn't read his netscape mail too often :-)
(mumble mumble got to get rid of that terry@netscape.com address mumble mumble) Sacreligious though it may be, I don't use mozilla-the-browser at all, and am not available to help in directly debugging any bugs in it. All that Bugzilla is doing here is setting a really big cookie string. I'm not sure what more help I can offer.
dan@ss-i.com : out of curiosity, what type of network connection are you using? I have 28K dialup, and I can reproduce this easily. As far as I know, this has not been seen by anyone at netscape, but people elsewhere do see it (see bug #21013, bug #22334, and (I believe) bug #22039).
Clearing resolution [ Not able to reproduce it though!! ]. Moving to M15..will get to it if any time is left in M14.
Status: REOPENED → ASSIGNED
Target Milestone: M14 → M15
I can't reproduce this bug either. I can't emulate the slow 28.8 connection, maybe that does have something to do with it... ?
The line I'm using when I get this problem is a dedicated 56K line shared between 9 people in our office. I think that maybe the slow connection might have something to do with it. I'm going to download windows versions of the browser soon and see if the problem also exists on the windows platform in our office. Will let you know..
I don't think connection speed has anything to do with this. I'm at work with a really fast internet connection (I download mozilla from mozilla.org at 170kB/s) and i've seen it occasionally. I can't remember off hand the most recent build number that I've seen it with... I've seen that second screenshot 1/15/00 11:11 many times.
I meant to include my OS though: WinNT.
*** Bug 23375 has been marked as a duplicate of this bug. ***
*** Bug 21013 has been marked as a duplicate of this bug. ***
Adding valeski's followup comment from bug #21013 to this bug report: ------- Additional Comments From valeski@netscape.com 2000-02-13 10:28 -- note that I can't repro the problem and I am outside the firewall (though I am on a T1 connection).
*** Bug 21013 has been marked as a duplicate of this bug. ***
Not able to reproduce.... Marking the bug LATER..until I've a reproducable test case.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → LATER
Was able to reproduce on a Win98, 49333 connection, cvs build from today (2/23/2000). Also crashes the browser fairly regularly too. No firewall.
As a data point, I just saw this on Linux mozilla 2000-02-24-15-M14 loading a bugzilla query of every bug I ever filed (including fixed ones). The page was many times the length it should have been. At various points in the page, it started over at the beginning of the content, I think including the Set-Cookie header but no other headers. (I was going to provide a more detailed list, but I managed to send the browser into an infinite loop before I was able to write them down.) I think LATER is a bad status for this bug. (Somehow it seems to me more like a networking problem than a parser problem, although perhaps not, since this time (for the first time for me), the table layout was generally not too messed up ,which makes me think that perhaps the changes to table incremental reflow could have changed where the content gets inserted. It could have just been a coincidence, though.)
I just reproduced this a second time in a row on my saved query ("All David Report Bugs"), which is a query for all bugs of any status (NEW...CLOSED) reported by me, sorted by bug#. What I see on the screen is: * the beginning of the page, up to the quip "Eddie would go", without the HR below it * the Set-Cookie header, followed by the page up to bug 1040 (with the complete table row for that bug) * the page (no header!) up to the text "The borders are" within the entry for bug 1052 * the Set-Cookie header, followed by the page (the header, the beginning of the page, up to "Bug List" but before the date, is in the table cell with "The borders are") up to bug 1238, which ends after the platform "Wind" * the beginning of the page again (without header), lined up exactly as it was the previous time within the table cell for Platform, up to bug 1596, which ends after "Crash is caused by the lo" in the status whiteboard * Set-Cookie, followed by the text up to bug 1985 * the page *starting with the date*, up to bug 2038, which ends after "peterl@netscape.com" * starting on a new line, the page without the header, moving back to the correct position after the Date, up to bug 2442, which ends after the platform (Wind) * beginning in the Status-Whiteboard entry of the previous cell, the page, without header, up to bug 2949, * beginning in the first cell of the row after bug 2949, the page, without the Set-Cookie, up to... This goes on forever (my scrollbar is only a 10th of the way down so far). However, the following observations make me think this is a bug related to processing chunks of network data multiple times, rather than processing chunks of parsed data multiple times: * The Set-Cookie header appears when the interruption and beginning of the new page happened within text, but often does not appear when the interruption happened at the end of a cell (that is, probably *within* a tag). * a larger chunk of the page was cut out when the interruption occurred right after the end of the row. (Note: Mozilla tends to throw out invalid content within tables, i.e., raw text within TR, rather agressively. Or at least it used to...)
If you'd like any more information, I'm going to lunch now, with the process showing the mess still running, and I'll check my email when I get back from lunch. (I may even give you a bit more time.)
Thanx for all that effor David. I did not say that this bug does not exist. All I said was that I couldn't reproduce it. How can I measure a state if I'm not a part of it.....may be in quantum mechanic..uh? ;-)
I've just reproduced this three times in a row on the bugzilla query: * [Status] NEW...CLOSED * [Reported by] dbaron@fas.harvard.edu * [Sort by] Bug number on Linux mozilla 2000-02-24-15-M14 (release build). You might want to try it on that query, on Linux. Could this have something to do with the implementation of the multipart/alternative MIME type (is that what it's called?)? That's a somewhat obscure feature, and I believe it's used by the Bugzilla query page results. Has anyone seen this bug anywhere other than the Bugzilla query page results?? If not, I'd have to say that it's a likely possibility for the culprit (which would mean this isn't a Parser bug).
I'm reopening this bug and marking it dogfood and beta1, because I can't load this bugzilla query page, so I need to go use 4.x to do it. I just tried three more times, and it happens *every time*.
Status: RESOLVED → REOPENED
Keywords: beta1, dogfood
Resolution: LATER → ---
Looks like Schroedinger's bug. dbaron: could you note the type of network connection you are using, and whether this is a debug build or opt build (in the hope of narrowing down how harishd can reproduce). I agree that this bug lies either in networking or at the handoff from networking to parser (and I don't recall why I started this off with parser). [But out of curiosity, does the parser get the raw HTTP stream (incl. headers) or is it supposed to be handed the *ML content only].
I was just working on the debug/opt issue. I can reproduce it in the opt build (described above) and my debug build (from early this week) while in the debugger. (Well, I'm still waiting to *see* the output, since it takes a few minutes for the reflow, but I'm pretty sure it's the bug, since I've been waiting about five minutes and it's still working on loading the page.) I'm on a pretty fast ethernet connection, (it takes about 20 seconds to download release bits from ftp.mozilla.org), although there's probably a bit of latency. There was a separate bug, bug 16256, on the 'Set-Cookie' header showing up, that was fixed a while back. It was a bug in the multipart/mixed code. In fact, could this bug be a bug in the fix for that bug??? valeski, any thoughts????
I confirm that I do see this bug in a debug build while running in the debugger. (It just finished reflow a minute or two ago.)
I applied the patch, rebuilt in netwerk, and it doesn't seem to help. At least, I've been waiting 60 seconds for the reflow to finish. (It took fifteen minutes or so last time, but I think without the bug it would finish in 10 or 15 seconds at most.)
Valeski, is this a known networking bug?
the layout timing is not a known networking bug, it is completely unrelated to this bug. From this point forward no-one mention layout timing in this report. If the timing is a problem, file a new bug.
dbaron. Are you able to packet sniff? If so, we could nail this bug easily. headers can only bleed into the content area if they're not recognized as headers when parsing the multi-mixed data. A tcp level dump of a broken query would be great. assuming ownership of this.
Assignee: harishd → valeski
Status: REOPENED → NEW
I don't know. How would I packet sniff (on Linux)? I'm willing to help.
I'm not on linux at the moment, but see if you have 'snoop' or 'tcpdump' on the system.
Putting on PDT+ for beta, removing dogfood, janc or gerardok, can you reproduce with latest build? If reproducible, please giev us a estimated fix date in the Status Whiteboard.
Keywords: dogfood
Whiteboard: [PDT+]
per mail from valeski: "I may have accidentally beta1'd this. this is a non-reproducible edge case, can it be pulled from PDT+?" Done...changing to PDT-
Whiteboard: [PDT+] → [PDT-]
For the record, I marked it beta1, because I can reproduce it 100% of the time, and it prevents me from doing large Bugzilla queries in Mozilla.
i can't repro this. can someone who can, produce a tcp trace?
Clearing PDT- until QA has a chance to reproduce. Will have to revisit this.
Whiteboard: [PDT-] → [NEED INFO]
*** Bug 26529 has been marked as a duplicate of this bug. ***
OK. I have some data that should be useful. Gagan said by email (and on mozilla-netlib) to use ethereal. However, I took a tcp dump using tcpdump (so that I wouldn't go into promiscuous mode, which ethereal seems to do), and then modified it using ethereal to include only the data for the relevant connection. I'm going to attach it in the tcpdump format, which can be read very nicely by ethereal, but which is, I think, essentially just the raw TCP data, and may be more useful in that format.
hmm. when I download that file (showattatchment.cgi) I get a bunch of http/html stuff.
What is it you want to see? It is mostly HTTP/HTML stuff, but the packet headers are in there too. (If you try to view it as a text file in Netscape, a lot of the header stuff gets cut off because of the control characters involved.) If you open it in ethereal, you'll see all sorts of info. What information do you want?
sorry. I'm tired. This is probably exactly what I need. I'll take a closer look soon.
Putting on PDT+ for beta1. Will set to PDT- on 03/03 if not fixed or regresses after fix.
Whiteboard: [NEED INFO] → [PDT+] w/b minus on 03/03
Attached patch proposed fix — — Splinter Review
I could never get ethereal installed and making sense of it's output in a text editor was a little tricky, but I think I nailed this. Please apply the attached patch and let me know.
Status: NEW → ASSIGNED
QA Contact: janc → tever
I applied the patch, rebuilt in netwerk, and it didn't help. What problems are you having installing ethereal? It's quite easy with the RPM (one needs to get one other RPM
btw jud, I can reproduce this in house on my Linux 2/27 build.
I still can't repro this anywhere (linux or nt). please send more etheral output for runs that display the set-cookie header in the body content.
holy @#$@! I just repro'd this on linux.
yeah but ... can you do it again. I have seen this twice now but haven't figured out how to do it consistently
ok this thing is dead in the water now. try this patch.
Attached patch fix — — Splinter Review
Works beautifully. :-) (Or, the page loads in about 20 seconds, but that's not your problem anymore...)
just checked in fix
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
dbaron, is there any possibility you could check tomorrow's (3/3) commercial build and mark this verified if it still looks good? Thanks for the help.
I could. Feel free to remind me if I don't...
I'm no longer seeing this in Linux mozilla 2000-03-03-09-M15. I'm therefore marking it as VERIFIED since it seems I was the only person who could reproduce it 100% of the time. However, if anyone sees this happen again (on a multipart-mixed page, such as bugzilla query results), ever, please reopen the bug.
Status: RESOLVED → VERIFIED
Yes, it seems fixed in the Linux build 2000030509 to me too. (I could reproduce this bug 100% of the time too).
Seems fixed in 2000030516 nightly WinNT 4 SP6a on PII. I was getting this quite frequently on bugzilla queries with long result sets (see bug 21013 which was marked as a dup of this) - not getting it any more. Anyone to verify this on Win98 and Win2K ?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: