Bug 46125 - Setting large cookies in the request causes Tomcat to abort the connection
Summary: Setting large cookies in the request causes Tomcat to abort the connection
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.18
Hardware: Macintosh Mac OS X 10.4
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-29 17:44 UTC by Matt Bishop
Modified: 2008-12-27 11:31 UTC (History)
0 users


Attachments
An HTML file that demonstrates the bug. (461 bytes, text/plain)
2008-10-29 17:46 UTC, Matt Bishop 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Bishop 2008-10-29 17:44:01 UTC 
It is possible to store too many cookies, or cookies that are too large for the header to properly carry. That's not good web programming, but still, it is quite common when one is using a JS framework.

If such a set of cookies is constructed and sent to Tomcat as part of a request, Tomcat panics and simply aborts the connection. This leads to a blank screen with no source code on the client's browser. Or, it leads to a cryptic error, like Safari's infamous "CFErrorDomainCFNetwork error 302" that drives many a newsgroup to tears trying to figure out what is going wrong with the server.

Expected: return a '400 Bad Request error' like apache does. That would help the user know what is wrong with the request and help find a better resolution to the condition.

I am attaching an HTML file that demonstrates this bug. Please run it in Tomcat and Apache as a comparison. I believe Apache handles the situation correctly.
Comment 1 Matt Bishop 2008-10-29 17:46:02 UTC 
Created attachment 22792 [details]
An HTML file that demonstrates the bug.
Comment 2 Matt Bishop 2008-10-30 10:42:30 UTC 
The safari error is actually kCFErrorDomainCFNetwork error 302.
Comment 3 Mark Thomas 2008-11-01 17:38:01 UTC 
This has been fixed in trunk and proposed for 6.0.x.

Note that no content is returned but the return code is 400. There will also be a log message if debug logging is enabled.
Comment 4 Mark Thomas 2008-12-27 11:31:05 UTC 
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.