219448 - Mozilla stops loading page when http header length exceeds 10240 bytes

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Hugo]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a; MultiZilla v1.5.0.0f) Gecko/20030725
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827

Mozilla handles cookies correctly; it refuses to store cookie with a length
greater than 4096 bytes.

If you, however, send a cookie with a length of 10227 bytes, Mozilla stops
loading the page.

Reproducible: Always

Steps to Reproduce:
1. Create a script (PHP) which sends the following set-cookie header:
"Set-Cookie: Value=<insert 10221 A's here>", and let the script output the HTML
"This is reached in normal situation"

2. Mozilla will load the page, not set the cookie, and display the text 'This is
reached in normal situation'.

3. Now send following header from the script:
"Set-Cookie: Value=<insert 10222 A's here>", and let the script output the HTML 

4. Page is not loaded at all.

Actual Results:  
Mozilla didn't load the page, and if you hit 'Reload' it even reloads the page
previously entered in the URL-bar.

Expected Results:  
Silently drop the cookie, as it's not conform cookie-spec, but *do* continue to
load the page.

Comment 1

[[e-mail]]

probably something in netwerk... maybe a header buffer length limit? darin?

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

if you include "set-cookie:" in the count, it is 10240 bytes, which is a more
logical number :)

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Hugo]

[I received an email from the autoresolver system.]

I discovered the described problem still exists in Firefox 1.5beta1.

See http://homebaze.net/security/mozilla/headerbug.php for demonstration of the bug.

Comment 5

[alanjstr]

I click the link, the throber throbs and then stops.  What specifically should
be happening?  It would help if your testcase 1) had source provided and 2)
actually did something to indicate the failure.

Comment 6

[Hugo]

(In reply to comment #5)
> I click the link, the throber throbs and then stops.  What specifically should
> be happening?  It would help if your testcase 1) had source provided 

It would help if, prior to your response, you would read this bug's initial
posting. The link is a proof of concept which does *exactly* as described in my
initial post (which you obviously haven't read, I assume?).

Additionally, you could've used 'curl' to figure out what's causing Mozilla to
stop loading the page to see what it's getting as input.

> and 2)
> actually did something to indicate the failure.

Excuse me, but what part of 'If nothing happens, your browser has the bug.'
don't you understand on that demo-page?

In the initial bug report I have already stated that the page *stops loading*.

Comment 7

[Darin Fisher]

-> default owner

Comment 8

[[e-mail]]

confirmed in current trunk. biesi, do you have any idea where the problem could be? sounds like we're hitting some kind of header length limit, possibly in necko.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpTransaction.cpp#692

Necko limits headers to 10 KB (10228 + the length of "Set-Cookie: " is exactly 10240).

Comment 10

[[e-mail]]

per comment 9, -> networking and changing summary.

Comment 11

[Patrick McManus [:mcmanus]]

there is going to be a limit no matter what. Ours doesn't seem to be a general problem