Closed Bug 16256 Opened 25 years ago Closed 25 years ago

[DOGFOOD]large cookie makes headers part of content

Categories

(Core :: Networking: Cookies, defect, P3)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: jud)

References

Details

(Whiteboard: [PDT+] fix in hand, waiting for review) 

DESCRIPTION:  The presence of a large cookie makes the HTTP headers show as part
of the content.

STEPS TO REPRODUCE:
 * Load http://bugzilla.mozilla.org/query.cgi
 * Select all 6 Status possibilities (NEW...CLOSED)
 * Enter "dbaron" in the second "Email" box (for reporter)
 * hit submit  (query should return almost 400 bugs :-)

ACTUAL RESULTS:
 * top of results shows:
Content-Type: text/htmlSetCookie:
BUGLIST=... ... ...

EXPECTED RESULTS:
 * should only see the page

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-10-12-08-M11

WORKS CORRECTLY ON:
 * NN 4.61
Assignee: gagan → valeski
Uh oh... cookie has newlines!
Assignee: valeski → neeti
neeti's our cookie queen.
Assignee: neeti → morse
Component: Necko → Cookies
I cannot get to reproduce this bug yet, because my build from yesterday crashes
when it loads the http://bugzilla.mozilla.org/query.cgi page. Steve, could you
take a look at this.

Thanks,
Neeti
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
This works for me with a build that was pulled on 10-25 which was after this bug
was reported.  So could you (dbaron) please try this again and let me know if
you are still seeing the problem.  I'll mark it works-for-me in the interim but
please feel free to reopen it if my assessement was wrong.

I should mention that although this is a very large cookie in the http traffic,
it is never getting set.  Reason for that is discusses in bug 16968.  But that
is a tangential issue, not really relevant to the bug being reported here.
Status: RESOLVED → REOPENED
Reopening.  I'm still seeing this on 1999-10-27-08-M11 Linux apprunner.  In
fact, I see it on the smaller query that's just the bugs I filed that are still
open.  (Well, it got a little larger...)
You say you are seeing it on linux.  Can you try it on win32 and let me know if
that has the problem as well?
Status: REOPENED → ASSIGNED
Target Milestone: M11
Resolution: WORKSFORME → ---
Still waiting for a reply as to whether this is a linux-only bug or if the
reporter observes it on all platforms.

Also, paulmac, could you try this out and let me know if you observe it on
either the linux or win32 platform.  I am unable to reproduce this on a win32
platform.
I see this on a Nov. 1 build on Linux. I have a canned query that I migrated
over from 4.x that comes up with about 150 bugs and I see the entire list at the
top of the bug list.

I see the exact same thing when I try the query on win98.
to clarify, I see the entire header at the top of the page, as dbaron describes
Why do I see different things than dbaron and paulmac?  I just tried it again
using a build of Nov 1 and I can't even get the query to succeed.  In fact, any
bugzilla query that I do results in the following crash shown below.  I'm going
to try pulling a fresh tree from this morning and trying again.

nsFormFrame::ProcessAsURLEncoded(nsIFormProcessor * 0x00000000, int 0, nsString
& {...}, nsIFormControlFrame * 0x029bc1a4) line 780 + 22 bytes
nsFormFrame::OnSubmit(nsFormFrame * const 0x023e7b2c, nsIPresContext *
0x026a5c90, nsIFrame * 0x029bc170) line 544 + 30 bytes
nsHTMLButtonControlFrame::MouseClicked(nsIPresContext * 0x026a5c90) line 294
nsGfxButtonControlFrame::HandleEvent(nsGfxButtonControlFrame * const 0x029bc170,
nsIPresContext & {...}, nsGUIEvent * 0x0012f7bc, nsEventStatus &
nsEventStatus_eIgnore) line 223
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x026f8120, nsIPresContext & {...}, nsMouseEvent * 0x0012fbfc, nsEventStatus &
nsEventStatus_eIgnore) line 996 + 30 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x026f8120,
nsIPresContext & {...}, nsGUIEvent * 0x0012fbfc, nsIFrame * 0x029bc170,
nsEventStatus & nsEventStatus_eIgnore, nsIView * 0x026f5970) line 467 + 24 bytes
PresShell::HandleEvent(PresShell * const 0x026d0154, nsIView * 0x026f5970,
nsGUIEvent * 0x0012fbfc, nsEventStatus & nsEventStatus_eIgnore) line 2211 + 43
bytes
nsView::HandleEvent(nsView * const 0x026f5970, nsGUIEvent * 0x0012fbfc, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 834
nsView::HandleEvent(nsView * const 0x026f7cc0, nsGUIEvent * 0x0012fbfc, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsView::HandleEvent(nsView * const 0x026f2d00, nsGUIEvent * 0x0012fbfc, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsView::HandleEvent(nsView * const 0x026d0790, nsGUIEvent * 0x0012fbfc, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsViewManager::DispatchEvent(nsViewManager * const 0x026d0c90, nsGUIEvent *
0x0012fbfc, nsEventStatus & nsEventStatus_eIgnore) line 1739
HandleEvent(nsGUIEvent * 0x0012fbfc) line 63
nsWindow::DispatchEvent(nsWindow * const 0x026f50f4, nsGUIEvent * 0x0012fbfc,
nsEventStatus & nsEventStatus_eIgnore) line 401 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fbfc) line 422
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3418 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3636
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 32571609, long *
0x0012fe0c) line 2628 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x0044090e, unsigned int 514, unsigned int 0, long
32571609) line 579 + 27 bytes
USER32! 77e71268()
Steve, I crash also when submitted a query, but I cheated and used a
canned, bookmarked query that I had migrated over from my 4.x profile. bug 17431
deals with the crash.

So one way to get around the bug would be to bookmark a long query in 4.x, then
run mozilla -installer and migrate your profile over, then select that bookmark
in apprunner.
Ah, the truth comes out.  Is there a bug filed on this or should I file one?
Oops, sorry.  I just reread your comment and, indeed, you said there is a bug
filed on the crash.
Summary: large cookie makes headers part of content → [DOGFOOD]large cookie makes headers part of content
With paulmac's work-around for bug 17431 I'm able to reproduce this problem.
Sort of!  Twice it worked fine.  But about eight other times I got the described
symptoms.  There is something intermittent about this behavior.
Yep, definitely is timing related.  If I run under traceplus (to capture the
http traffic), this works fine every time.
gagan. a newline in the cookie value (illegal) would indeed cause this. did you
witness this? I am unable to reproduce.
Whiteboard: [PDT+]
Putting on PDT+ radar.
I finally got some more output.  I discovered that when it fails the SetHeader
routine for set-cookie is not getting called whereas it is getting called when
it succeeds.  I have been able to capture http traffic in the good case.
However it never fails when capturing traffic so I can't see what the traffic
looks like in the bad case.

We need to be able to instrument the browser at the point that it receives the
http traffic but I haven't been able to find that.  Judson, do you know where
that code is?
Blocks: 17907
Assignee: morse → valeski
Status: ASSIGNED → NEW
OK, I got the instumentation working and here is what I learned.  It definitely
is a timing problem.  Depending on how fast the input buffer gets filled up, the
read statement (in nsMultiPartConv) might get the entire multipart response in
one read statement or it might get split into two reads.  And if it gets split,
that's when we have a problem.  In that latter case the set-cookie header (which
is in the second read) is not being recognized.

This bug is definitely in Jud's area now so I'm reassigning it back to him (by
mutual consent).
Hmmm... I thought I saw a newline somewhere. I may be wrong. Anyhow... this is
definitely an exceptional situation where a header expands beyond the scope of a
block of OnDataAvailable. I guess we may have to fix the parsing logic to
accomodate this. Jud you ok with fixing this, or do you want me to take this
over?
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] fix in hand, waiting for review
I rewrote the multimixed-replace parser to handle broken data (headers being
spliced up, boundries being spliced up, etc). This rewrite should take care of
this problem. I need a code reviewer for this. It's very intricate code (many
return paths and nested loops). If someone wants to feel my pain, I'll go
through every line of logic. Perhaps a better alternative is to just code review
for crappy code and then I'll be responsible for making sure it works.
Target Milestone: M11 → M12
*** Bug 18182 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
fix checked in 11/10/99 4:35pm pac time
Status: RESOLVED → VERIFIED
Marking verified based on Linux mozilla 1999-11-13-08-M12. On the second of what
turned out to be about ten attempts to repeat the STEPS TO REPRODUCE above, I
saw some weird things (page within page, offset by about 200px, looking like
duplication within the content model - not a painting error) and then got a
crash, but I have been unable to reproduce the strange results. If I ever see
them again I'll file a bug.
No longer blocks: 17907
You need to log in before you can comment on or make changes to this bug.