[ZCM] [ZC] 1003/ 5 Comment "Overlong HTTP headers handled badly"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1003 Update (Comment) "Overlong HTTP headers handled badly"
 Status Rejected, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/1003

==============================================================
= Comment - Entry #5 by leper on May 1, 2004 4:04 pm

I'd leave it open, its a real bug.  Zope should speak HTTP, and it doesn't, it just gives up and closes the connection, thats bad, it should tell the client there was a fatal and permanent error, to prevent broken clients from retrying the request over and over.  Furthermore its not just the query string, its all headers combined, so 8k is easier to reach than you might think.

________________________________________
= Reject - Entry #4 by mcdonc on Apr 29, 2004 6:19 pm

 Status: Pending => Rejected

Rejecting, here's the rationale:

<mcdonc> slinkP: errr... if I follow Jamie's suggestion, he thinks there's no bug for 1003, right?
<mcdonc> i dont think it's a bug either.  if someone sends an 8000-character query string, it can only be a mistake or a DOS attempt, replying to them with a 500 just consumes more bandwidth and time.

Jamie, if you have a good argument to the contrary, please let me know and I will reopen.
________________________________________
= Comment - Entry #3 by leper on Dec 2, 2003 4:24 am

Upon further investigation this issue is actually more interesting than I initially thought.  The fix for 606 was rather naive, at the time I thought Brian had added a per-header 8KB limit like Apache's LimitRequestFieldsize, but thats not what he did.  The limit is 8K of data *total* prior to the CRLF CRLF sequence that delimits a request's headers and its body (if it has one).  That limit, while seemingly small, seems to be working OK for most folks or I'd imagine we'd be hearing a lot more complaints.  It also debunks my theory that ZServer stored unlimited headers in memory until it hit an rlimit, paradoxically making ZServer marginally safer than I'd initially given it credit for.  Go figure.  Nevertheless Andreas is right in that the handling of this error isn't very friendly.
________________________________________
= Comment - Entry #2 by leper on Aug 1, 2003 6:31 pm

Why is this critical?

I agree its a silly situation, but the simple truth is ZServer does
not offer an internet-quality HTTP service.  Requests handled by
ZServer must be sanitized by a proxy server first, for safety.  If
you ask me, its critical the lack of documentation about this be
addressed before 2.7 is released.

________________________________________
= Request - Entry #1 by ajung on Aug 1, 2003 6:46 am

Sending a GET request with a very long query string (several thousands characters) raises:


2003-08-01T12:41:33 ERROR(200) ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 127.0.0.1:40888 at 0x94d9d5c channel#: 33 requests:> (exceptions.ValueError:HTTP headers invalid (too long) [/develop/sandboxes/bpe2-head/ZServer/medusa/asyncore.py|poll|94] [/develop/sandboxes/bpe2-head/ZServer/medusa/asyncore.py|handle_read_event|395] [/develop/sandboxes/bpe2-head/ZServer/medusa/asynchat.py|handle_read|142] [/develop/sandboxes/bpe2-head/ZServer/HTTPServer.py|collect_incoming_data|351])

Instead of replying with a proper HTTP return code (500 at least), Zope just closes the connection.



==============================================================