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

Collector: Zope Bugs, Features, and Patches ... zope-coders-admin at zope.org
Tue Nov 2 06:13:35 EST 2004


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

==============================================================
= Comment - Entry #8 by flemmingbjerke on Nov 2, 2004 6:13 am

"<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."

In case you make database frontends with zope - mysql for instance - you can easily need to send an 8000-character string. 

Flemming
________________________________________
= Refuse - Entry #7 by chrisw on May 6, 2004 7:54 am

 Status: Pending => Wontfix

Lets see if Ken's new "won't fix" state works...

Zope SHOULD do this, but since everyone SHOULD front it with a proxy like Apache or Squid in production, I doub this will ever get fixed....
________________________________________
= Resubmit - Entry #6 by mcdonc on May 5, 2004 10:10 pm

 Status: Rejected => Pending

Resubmitting as per Jamie.  Personally I wouldn't fix it, but I respect the reasoning behind keeping it open.
________________________________________
= 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.



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



More information about the Zope-Collector-Monitor mailing list