IOError: Anfrage Daten lesen Fehler

Question

Ich scheine einen IOError bekommen: Anfrage Daten lesen Fehler ziemlich viel, wenn ich einen Ajax-Upload mache. Zum Beispiel hochgeladen von mindestens 5 Datei es Fehler auf mindestens 3.

Andere Leute scheinen das gleiche Problem gehabt zu haben. Z.B.

• Django upload failing on request data read error
• Django file upload failing occasionally

Einige andere Beobachtungen:

• Es ist definitiv nicht meine Internet-Verbindung oder ein Browser-Problem. Scheint auf allen Browsern chrome/FF/Opera zu passieren.

• Ich bin mit django 1.1.1 Apache/2.2.14 (Ubuntu) mod_ssl/2.2.14 OpenSSL/0.9.8k mod_wsgi/2.8 Python/2.6.5 auf Lucid.

• Es ist auch nicht die Dateigröße. Ich kann manchmal 1 + MB-Dateien hochladen, aber scheitern auf 180 Kb-Dateien.

---

Traceback

Traceback (most recent call last): 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/core/handlers/base.py", line 98, in get_response 
    response = middleware_method(request, e) 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/core/handlers/base.py", line 92, in get_response 
    response = callback(request, *callback_args, **callback_kwargs) 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/contrib/auth/decorators.py", line 78, in __call__ 
    return self.view_func(request, *args, **kwargs) 

    File "/home/ubuntu/webapps/anonymous_app/app/do_work/views/__init__.py", line 391, in some_form_ajax_upload 
    f = request.FILES.get('file_upload') 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 187, in _get_files 
    self._load_post_and_files() 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 137, in _load_post_and_files 
    self._post, self._files = self.parse_file_upload(self.META, self.environ['wsgi.input']) 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/__init__.py", line 124, in parse_file_upload 
    return parser.parse() 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 133, in parse 
    for item_type, meta_data, field_stream in Parser(stream, self._boundary): 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 606, in __iter__ 
    for sub_stream in boundarystream: 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 420, in next 
    return LazyStream(BoundaryIter(self._stream, self._boundary)) 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 446, in __init__ 
    unused_char = self._stream.read(1) 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 299, in read 
    out = ''.join(parts()) 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 292, in parts 
    chunk = self.next() 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 314, in next 
    output = self._producer.next() 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 375, in next 
    data = self.flo.read(self.chunk_size) 

    File "/home/ubuntu/.virtualenvs/anonymous_app/lib/python2.6/site-packages/django/http/multipartparser.py", line 405, in read 
    return self._file.read(num_bytes) 

IOError: request data read error 


<WSGIRequest 
GET:<QueryDict: {}>, 
POST:<could not parse>, 
COOKIES:{'__utma': '168279989.1688771210.1285773436.1285773436.1285773436.1', 
'__utmb': '168279989.20.10.1285773436', 
'__utmc': '168279989', 
'__utmz': '168279989.1285773436.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)', 
'beta': 'True', 
'sessionid': 'b1ecf92f2bba13e1885d07803e10aa03', 
'timezone_offset': '-330'}, 
META:{'CONTENT_LENGTH': '188575', 
'CONTENT_TYPE': 'multipart/form-data; boundary=---------------------------57602381214905740261171925981', 
'DOCUMENT_ROOT': '/htdocs', 
'GATEWAY_INTERFACE': 'CGI/1.1', 
'HTTPS': '1', 
'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 
'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 
'HTTP_ACCEPT_ENCODING': 'gzip,deflate', 
'HTTP_ACCEPT_LANGUAGE': 'en-us,en;q=0.5', 
'HTTP_CONNECTION': 'keep-alive', 
'HTTP_COOKIE': 'beta=True; __utma=168279989.1688771210.1285773436.1285773436.1285773436.1; __utmb=168279989.20.10.1285773436; __utmc=168279989; __utmz=168279989.1285773436.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); sessionid=b1ecf92f2bba13e1885d07803e10aa03; timezone_offset=-330', 
'HTTP_HOST': 'xxxxxx.compute-1.amazonaws.com', 
'HTTP_KEEP_ALIVE': '115', 
'HTTP_REFERER': 'https://ec2-184-72-79-96.compute-1.amazonaws.com/do-my-somees/enter/some-documents/', 
'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10', 
'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin', 
'PATH_INFO': u'/do-my-somees/enter/some-documents/ajax-upload/Other-some-Document/', 
'PATH_TRANSLATED': '/home/ubuntu/webapps/anonymous_app/settings/apache/qa.wsgi.py/do-my-somees/enter/some-documents/ajax-upload/Other-some-Document/', 
'QUERY_STRING': '', 
'REMOTE_ADDR': '', 
'REMOTE_PORT': '15561', 
'REQUEST_METHOD': 'POST', 
'REQUEST_URI': '/do-my-somees/enter/some-documents/ajax-upload/Other-some-Document/', 
'SCRIPT_FILENAME': '/home/ubuntu/webapps/anonymous_app/settings/apache/qa.wsgi.py', 
'SCRIPT_NAME': u'', 
'SERVER_ADDR': '10.196.142.182', 
'SERVER_ADMIN': 'dev@anonymous_app.com', 
'SERVER_NAME': 'ec2-184-72-79-96.compute-1.amazonaws.com', 
'SERVER_PORT': '443', 
'SERVER_PROTOCOL': 'HTTP/1.1', 
'SERVER_SIGNATURE': '<address>Apache/2.2.14 (Ubuntu) Server at ec2-184-72-79-96.compute-1.amazonaws.com Port 443</address>\n', 
'SERVER_SOFTWARE': 'Apache/2.2.14 (Ubuntu)', 
'SSL_TLS_SNI': 'ec2-184-72-79-96.compute-1.amazonaws.com', 
'mod_wsgi.application_group': 'qa.anonymous_app.com|', 
'mod_wsgi.callable_object': 'application', 
'mod_wsgi.listener_host': '', 
'mod_wsgi.listener_port': '443', 
'mod_wsgi.process_group': '', 
'mod_wsgi.reload_mechanism': '0', 
'mod_wsgi.script_reloading': '1', 
'mod_wsgi.version': (2, 8), 
'wsgi.errors': <mod_wsgi.Log object at 0xb9456860>, 
'wsgi.file_wrapper': <built-in method file_wrapper of mod_wsgi.Adapter object at 0xb936a968>, 
'wsgi.input': <mod_wsgi.Input object at 0xb9720e30>, 
'wsgi.multiprocess': True, 
'wsgi.multithread': False, 
'wsgi.run_once': False, 
'wsgi.url_scheme': 'https', 
'wsgi.version': (1, 0)}> 

Answer 1

wie Sie vielleicht denken, das ist kein django Fehler.

siehe https://groups.google.com/group/django-users/browse_thread/thread/946936f69c012d96

haben den Fehler selbst (aber IE AJAX-Anfragen nur, keine Datei-Upload, nur Daten veröffentlichen).

wird eine vollständige Antwort hinzufügen, wenn ich jemals herausfinden, wie das zu beheben ist.

Answer 2

Dieses Problem ist seit langem offen und hat etwas mit Bibliotheken auf niedrigerer Ebene zu tun. Ich benutzte Boto, um Dateien nach S3 hochzuladen. Eine temporäre Lücke, die ich gefunden habe, war ein explizites HTTP-Socket-Timeout von 10 Sekunden hinzuzufügen. Ich habe den Fehler danach nicht gesehen. Sie können das tun, indem Sie eine Boto Config auf dem Server zu erstellen:

#/etc/boto.cfg 
[Boto] 
http_socket_timeout=10 

auch sicherstellen, dass die Datei von der App lesbar ist. Siehe meinen ursprünglichen Beitrag auf Google-Gruppe: https://groups.google.com/forum/#!topic/boto-users/iWtvuECAcn4

Answer 3

Ich bekomme diese Ausnahme auch. Im Apache Fehler Logfile sehe ich das:

[Wed Aug 17 08:30:45 2011] [error] [client 10.114.48.206] (70014)End of file found: mod_wsgi (pid=9722): Unable to get bucket brigade for request., referer: https://egs-work/modwork/beleg/188074/edit/ 
[Wed Aug 17 08:30:45 2011] [error] [client 10.114.48.206] mod_wsgi (pid=3572): Exception occurred processing WSGI script '/home/modwork_egs_p/modwork_egs/apache/django_wsgi.py'. 
[Wed Aug 17 08:30:45 2011] [error] [client 10.114.48.206] IOError: failed to write data 

Versionen:

apache2-prefork-2.2.15-3.7.x86_64 
apache2-mod_wsgi-3.3-1.8.x86_64 WSGIDaemonProcess with threads=1 
mod_ssl/2.2.15 
Linux egs-work 2.6.34.8-0.2-default #1 SMP 2011-04-06 18:11:26 +0200 x86_64 x86_64 x86_64 GNU/Linux 
openSUSE 11.3 (x86_64) 

Zuerst habe ich verwirrt war, weil die letzte Zeile „zu Schreib fehlgeschlagen Daten“ nicht auf den django Code passen " Postdaten laden ". Aber ich denke, dass Django eine Fehlerseite auf den Client schreiben möchte. Aber der Client hat die TCP-Verbindung abgebrochen. Und jetzt http 500 Seite kann nicht auf den Client geschrieben werden.

Der Client getrennt, nachdem die Anfrage zu senden, und bevor die Antwort bekommen:

• Der Benutzer den Browser oder navigiert zu einer anderen Seite geschlossen.
• Der Benutzer hat die Reload-Taste gedrückt.

Ich habe dies nur mit POST-Anfragen (nicht GET) gesehen. Wenn POST verwendet wird, liest der Webserver mindestens zweimal: Erstens, um die Header zu erhalten, und zweitens, um die Daten zu erhalten. Der zweite Lesevorgang schlägt fehl.

Es ist leicht zu reproduzieren:

einige Code einfügen, die zu request.POST vor dem ersten Zugriff wartet passiert (sicher sein, dass keine Middleware request.POST vor time.sleep Zugriffe()):

Jetzt machen Sie einen großen POST (zB Datei-Upload). Ich kenne die Größe des Apache-Puffers nicht. Aber 5 MB sollten ausreichen. Wenn der Browser die Sanduhr anzeigt, navigieren Sie zu einer anderen Seite. Der Browser wird die Anfrage abbrechen und die Ausnahme sollte in der Logdatei sein.

Das ist meine Middleware, da will ich nicht die oben Zurückverfolgungs in unseren Logfiles bekommen:

class HandleExceptionMiddleware: 

    def process_exception(self, request, exception): 
     if isinstance(exception, IOError) and 'request data read error' in unicode(exception): 
      logging.info('%s %s: %s: Request was canceled by the client.' % (
        request.build_absolute_uri(), request.user, exception)) 
      return HttpResponseServerError() 

Answer 4

diese Einnahme aus dem Thread: Getting rid of Django IOErrors

die mögliche Lösung Erweiterung durch @dlowe für Django 1.3, die IOError in Sorge zu unterdrücken, wir das volle Arbeitsbeispiel, wie schreiben:

settings.py

LOGGING = { 
    'version': 1, 
    'disable_existing_loggers': False, 
    'filters': { 
     'supress_unreadable_post': { 
      '()': 'common.logging.SuppressUnreadablePost', 
     } 
    }, 
    'handlers': { 
     'mail_admins': { 
      'level': 'ERROR', 
      'class': 'django.utils.log.AdminEmailHandler', 
      'filters': ['supress_unreadable_post'], 
     } 
    }, 
    'loggers': { 
     'django.request': { 
      'handlers': ['mail_admins'], 
      'level': 'ERROR', 
      'propagate': True, 
     }, 
    } 
} 

common/logging.py

import sys, traceback 

class SuppressUnreadablePost(object): 
    def filter(self, record): 
     _, exception, tb = sys.exc_info() 
     if isinstance(exception, IOError): 
      for _, _, function, _ in traceback.extract_tb(tb): 
       if function == '_get_raw_post_data': 
        return False 
     return True 

Answer 5

Wir werden diese Fehler auf Uploads Django Ruhe Rahmen sahen, wenn der Content-Type-Header falsch auf application/json gesetzt wurde. Der Post war tatsächlich mehrteilige Formulardaten. Die Fehler wurden gestoppt, als wir den falschen Content-Type-Header entfernt haben.

Answer 6

Ich habe diesen Fehler bei der Validierung meiner Website auf einer Win8-Maschine mit IE 10. Als ich Dateiupload von IE getestet wurde der Upload auf 1% fest und nach +/- 1 Minute habe ich den Fehler auf Server-Logs. Ich habe gerade festgestellt, dass dies auf die TrendMicro-Ergänzung zurückzuführen ist. Sobald ich die Ergänzung deaktiviert habe, ist der Upload ohne Probleme erfolgt.

Answer 7

Das ist mir vor kurzem passiert. Ich benutzte django-ajax-uploader und kleine Dateien wurden erfolgreich hochgeladen, aber große Dateien, z. Zwischen IOError: request data read error waren 100MB dazwischen.

Ich überprüfte meine Apache-Konfiguration und fand diese Einstellung RequestReadTimeout header=90 body=90, was Allow 90 seconds to receive the request including the headers and 90 seconds for receiving the request body bedeutet.

Datei wird in Blöcken am Backend empfangen, was bedeutet, wenn die Dateigröße groß ist 90 Sekunden sind nicht genug für einige Uploads. Wie kann man den besten Wert (Sekunden) für die Anfragen ermitteln?

So habe ich diese Einstellung verwendet:

RequestReadTimeout header=90,MinRate=500 body=90,MinRate=500 

Definition der MinRate für mich das Problem löst. Die zuvor genannte Einstellung lautet:

Allow at least 90 seconds to receive the request body. If the client sends data, increase the timeout by 1 second for every 500 bytes received

wie der Client Daten sendet kontinuierlich (Ajax upload) ist es sinnvoll zu erhöhen automatisch den Timeout, wenn Daten empfangen werden. Weitere Informationen/Variationen über die RequestReadTimeout finden Sie unter here.