This happened to me twice (while using WebKit trunk). I had to delete my Bugzilla cookies before I could see any pages on bugzilla.mozilla.org again.
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.
Apache/2.2.3 (Red Hat) Server at bugzilla.mozilla.org Port 80
(According to bug 471971, the gigantic BUGLIST cookie has a different effect in Firefox.)
Doesn't that sound like a bug in WebKit or a problem in the web server? I would expect there to be limits on these sorts of things...
In any case, the problem is most likely limited to bmo, which does things differently with the buglist cookie than upstream does. Can you reproduce this on http://landfill.bugzilla.org/bugzilla-tip/ ?
Also, reducing severity, because although I understand it's really bad when it happens, you're the only person I've ever heard report this and one would think that if it was a common problem (say, in stable versions of common browsers) that we would hear about this quite frequently. But if it does become common or we do show that it's some actual standards violation in Bugzilla, I'd be happy to raise the severity again.
How is WebKit supposed to know what limit the Apache instance on bmo has?
(In reply to comment #4)
> How is WebKit supposed to know what limit the Apache instance on bmo has?
No, I wouldn't expect that. I just figured that if Apache was instantiating some limit, that it was standard to some degree. Anyhow, it's possible that bmo is doing something bad with the cookie, as I said. I was just wondering if there was some standard on the subject.
I have experienced this problem frequently (about once a week) for the past few months on our local Bugzilla installation. This has crossed different stable versions of Bugzilla, specifically 3.0.6 and 3.2.2. I and my colleagues usually use Firefox 3, so this is the only browser in which we have seen this bug. The fact we're getting this bug in Firefox implies it's not a specefic WebKit issue.
The Bugzilla server is running Apache 2.0.59 in Fedora 8. I recently upgraded our Bugzilla/Testopia installation from BZ 3.0.6 and Testopia 2.1 to BZ 3.2.2 and Testopia 2.2. The "Bad Request" cookie bug remains with us.
Btw this can probably be used as a denial-of-service attack against Bugzilla users.
Hmm, I suppose it could be. I suppose we'll mark it security-sensitive until we understand what's causing it.
(In reply to comment #7)
> Btw this can probably be used as a denial-of-service attack against Bugzilla
How could this be a DoS? A user cannot have such gigantic cookies without some explicit action.
A malicious web page can make you load a long bug list using a hyperlink or frame.
I thought this was what that "this bug list is too big for Bugzilla's little mind" warning was supposed to prevent. Are we triggering that too high, and need to cut it shorter?
Jesse often has queries that include/exclude long lists of bugs from previous queries. Is it possible that a bug list from such a query bypasses the "little mind" cut off?
So, Apache has an 8K limit on inbound headers, so that's almost certainly the problem--when combined with a very large URL, the cookie the browser sends is exceeding Apache's limit.
Essentially, that makes this a dupe of bug 513989, in a way, although if Bugzilla then refuses *all* requests, that would still make this a security issue. If it just refuses further large buglist queries, that would simply make this a dupe of bug 513989.
Jesse: Does it refuse show_bug.cgi calls and index.cgi calls also, or just buglist.cgi calls?
I think this happened for other bmo URLs too.
*** Bug 561348 has been marked as a duplicate of this bug. ***
Bug 561348 has steps to reproduce and has identified the root cause. Go timeless!
Created attachment 512066 [details] [diff] [review]
patch for 4.x, v1
Replace colons by dashes, which are not escaped (I first thought about commas, but they are escaped too). I still split the BUGLIST cookie on colons to not break existing cookies.
Comment on attachment 512066 [details] [diff] [review]
patch for 4.x, v1
Looks good to me. Perhaps add a comment above the split(), on checkin.
I think that we should backport this to 3.6, but I don't think it needs a security advisory; we don't usually treat DoSes of this level as confidential.
(In reply to comment #18)
> I think that we should backport this to 3.6, but I don't think it needs a
> security advisory; we don't usually treat DoSes of this level as confidential.
But we could still commit it to 3.4 as a security improvement, isn't it?
> But we could still commit it to 3.4 as a security improvement, isn't it?
Yeah, I suppose we could, that makes sense.
Removing the sec flag, per comment 18. I'm going to commit it now.
Created attachment 512256 [details] [diff] [review]
patch for 4.x, v1.1
I forgot to fix one place.
Created attachment 512260 [details] [diff] [review]
patch for 3.6, v1
Backport for 3.x
The patch for 3.6 doesn't apply to the 3.4 branch at all. I don't want to take the risk to break something on an old branch because I omitted to fix one place by accident, so I'm retargetting this bug to 3.6.
Committing to: bzr+ssh://firstname.lastname@example.org/bugzilla/trunk/
Committed revision 7716.
Committing to: bzr+ssh://email@example.com/bugzilla/4.0/
Committed revision 7554.
Committing to: bzr+ssh://firstname.lastname@example.org/bugzilla/3.6/
Committed revision 7238.
*** Bug 365587 has been marked as a duplicate of this bug. ***
*** Bug 290977 has been marked as a duplicate of this bug. ***