Requests: "OverflowError: String länger als 2147483647 Bytes" beim Versuch von request.put

Wäre es möglich, die Chunked-Transfer-Codierung zu verwenden, anstatt die gesamte Datei zu lesen und in einer einzigen Anfrage zu senden? http://docs.python-requests.org/en/latest/user/advanced/#chunk -encoded-requests

Diese Einschränkung liegt in httplib . Sie können dies leicht vermeiden, indem Sie Ihren Code leicht ändern:

datafile = 'someHugeFile'
with open(datafile, 'rb') as myfile:
    resp = requests.put(url, data=myfile, verify=False)

@Lukasa das ist ungenau. Das Traceback kommt von einem SSL-verpackten Socket. Dies hat nichts mit httplib zu tun, wie ich sehe. OverflowErrors werden ausgelöst, wenn ein Wert größer als die zugrunde liegende zulässige C-Ganzzahl ist. Dies kann gesehen werden, wenn Sie len(something_larger_than_four_gb) auf einem 32-Bit-System aufrufen.

Leider sieht es so aus, als ob es sich nicht vermeiden lässt, wenn Sie eine POST-Anfrage mit mehreren Headern ausführen. Dann wird die Datei (oder die Dateien) immer vollständig gelesen.

Es wäre toll, wenn dies bei Anfragen vermieden werden könnte, da ich oft Dateien senden muss, die länger sind als der verfügbare Hauptspeicher auf dem System.

Ich melde mich einfach.

Wenn Sie versuchen, Dateien über das Web zu senden, die größer sind als Ihre
Systemspeicher verarbeiten kann, ist HTTP wahrscheinlich nicht das beste Protokoll dafür
über.

Am Dienstag, 11. Oktober 2016, 05:54 Uhr schrieb Erik Tews [email protected] :

Leider sieht es so aus, als ob es bei einem POST nicht vermieden werden kann
Anfrage mit mehreren Headern. Dann wird die Datei (oder die Dateien) immer gelesen
ganz und gar.

Es wäre toll, wenn dies bei Anfragen vermieden werden könnte, da ich oft
müssen Dateien versenden, die länger sind als der verfügbare Hauptspeicher auf dem
System.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/2717#issuecomment -252729478,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AGk_7XIpx0UDRPXDuoopI7jDSfAlurgLks5qypf7gaJpZM4FqFGb
.

Das stimmt, aber ich kann mich nicht für das Protokoll und den Endpunkt entscheiden.

Die Anfrage mit curl funktioniert gut, und als Workaround drucke ich derzeit einen curl-Befehl an STDOUT, damit der Benutzer ihn starten kann.

@eriktews kannst du teilen, wie du den Upload durchführst? Es gibt Möglichkeiten, Uploads zu streamen (wie Lukasas Kommentar zeigt). Gibt es einen Grund, warum Sie das nicht tun können (wenn Sie das nicht bereits versuchen)? Können Sie auch Ihren tatsächlichen Traceback bereitstellen?

Der Kommentar von Lukasa scheint also zu funktionieren, wenn Sie eine einzelne Datei hochladen, dann können Sie einen Streaming-Upload durchführen. Aber ich muss einen normalen Post-Request mit mehreren Variablen im Datenteil und der Datei als Teil eines mehrteiligen Uploads durchführen.

Es gibt eine API-Dokumentation unter https://canvas.instructure.com/doc/api/file.file_uploads.html, die einen curl-Befehl im Abschnitt "Schritt 2" zeigt. Grundsätzlich möchte ich diesen Aufruf mit dem Request-Paket im Streaming-Modus replizieren.

Ich habe den Traceback im Moment nicht, aber wenn ich ihn habe, werde ich ihn hier posten.

Haben Sie versucht, das MultipartEncoder aus dem Requests-Toolbelt zu verwenden ? Auf diese Weise können Sie Multipart-/Formulardaten-Uploads streamen, wie beim Hochladen einer einzelnen Datei. Es wurde speziell für diesen Anwendungsfall geschrieben und unseren Dokumenten hinzugefügt.

Nein, aber das sieht nach dem aus, was ich brauche. Ich werde es ausprobieren und sehen, ob das funktioniert. Ich wusste überhaupt nichts über das Toolbelt-Paket, daher sollten Sie es vielleicht in der Dokumentation des normalen Anforderungspakets nachschlagen.

Vielleicht sollten Sie also in der Dokumentation zum normalen Anforderungspaket darauf verweisen.

Es ist :)

Die Methode von @Lukasa funktioniert nicht - selbst wenn httplib ausgeschaltet ist, erfolgt die Signierung immer noch für den Transport selbst. In meinem Fall habe ich eine POST-Anfrage von mehr als 2 GB (keine Datei, nur POST-Daten). Dies ist für ein Elasticsearch-Massenupdate. Der Endpunkt hat nur HTTPS, daher arbeite ich jetzt andere Lösungen durch.

Traceback (most recent call last):
  File "/var/virtualenvs/centr/lib/python3.5/site-packages/elasticsearch/connection/http_requests.py", line 75, in perform_request
    timeout=timeout or self.timeout, verify=False)
  File "/var/virtualenvs/centr/lib/python3.5/site-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/var/virtualenvs/centr/lib/python3.5/site-packages/requests/adapters.py", line 423, in send
    timeout=timeout
  File "/var/virtualenvs/centr/lib/python3.5/site-packages/requests/packages/urllib3/connectionpool.py", line 600, in urlopen
    chunked=chunked)
  File "/var/virtualenvs/centr/lib/python3.5/site-packages/requests/packages/urllib3/connectionpool.py", line 356, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/lib/python3.5/http/client.py", line 1106, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.5/http/client.py", line 1151, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.5/http/client.py", line 1102, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.5/http/client.py", line 936, in _send_output
    self.send(message_body)
  File "/usr/lib/python3.5/http/client.py", line 908, in send
    self.sock.sendall(data)
  File "/usr/lib/python3.5/ssl.py", line 891, in sendall
    v = self.send(data[count:])
  File "/usr/lib/python3.5/ssl.py", line 861, in send
    return self._sslobj.write(data)
  File "/usr/lib/python3.5/ssl.py", line 586, in write
    return self._sslobj.write(data)
OverflowError: string longer than 2147483647 bytes

Entschuldigung, können Sie bitte Ihren Code demonstrieren?

Dies sollte den Fehler auslösen:

datafile = 'someHugeFile'
with open(datafile, 'rb') as myfile:
    r = requests.post(endpoint, data={'key': myfile.read()}, verify=False)

Wenn endpoint https ist, muss ssl die Nutzlast verarbeiten. Ich frage mich, ob requests oder requests-toolbelt eine Option zum Signieren mit einer anderen Bibliothek haben könnten, die beim Signieren einer 2-GB-Zeichenfolge nicht stirbt. Natürlich würde ich sagen, dass die Leute nicht so große Dinge unterschreiben sollten, aber es ist definitiv ein echter Crash, der in der realen Welt passiert.

@adamn Das war nicht mein Lösungsvorschlag. Meine vorgeschlagene Lösung bestand darin, die Datei überhaupt nicht manuell einzulesen. Sie stoßen auf den gleichen Fehler wie zuvor, nämlich dass wir eine einzelne riesige Zeichenfolge an httplib senden.

Dies ist ein Verhalten, das wir beheben können: Wenn wir sehen, dass jemand einen riesigen einzelnen String über Python hochlädt, können wir es lösen. An dieser Stelle empfehle ich Ihnen jedoch dringend , ein Zwischendateiobjekt zu verwenden: entweder eines auf der Festplatte oder indem Sie die URL selbst codieren und das Ergebnis in ein BytesIO einpacken.

Ich habe bereits eine Problemumgehung gefunden und kann daher leider nicht näher darauf eingehen. Ich vermute immer noch, dass die SSL-Nutzlast signiert / verschlüsselt werden muss, damit dasselbe passiert, unabhängig davon, ob ein Dateiobjekt vorhanden ist oder nicht, da die Ausnahme von ssl.write selbst ausgelöst wird und ich vermute, dass diese Methode die gesamte Nutzlast. Das Aufteilen des POST scheint die einzige echte Option zu sein. Danke jedenfalls für die Hilfe.

@adamn Nein, das ist nicht notwendig. TLS verwendet Stream-Verschlüsselung, es benötigt nicht die gesamte Nutzlast auf einmal.

Was Sie vermissen, ist, dass Anfragen, die ein Dateiobjekt erhalten, es automatisch in kleineren Blöcken (insbesondere 8192-KB-Chunks) streamen. Die machen kein Problem.

Es tut mir leid, zu einem alten Problem einen Kommentar abgeben zu müssen, aber das sieht einem Problem, auf das wir gestoßen sind, _ähnlich_ aus, und ich versuche zu entscheiden, ob es sich lohnt, dafür ein neues Problem zu eröffnen.

Auch hier funktioniert requests.put wo data ein _riesiger_ String ist nicht, aber wir erhalten keinen Fehler. Anfragen hängen einfach beim Senden auf; eine Paketerfassung zeigt, dass keine Daten mehr gesendet werden.

Dieses Verhalten ist _schlimmer_ als das Auslösen einer Ausnahme.

Hat die Gegenstelle auf TCP-Ebene ein ACKing durchgeführt? Wird noch aus dem Empfangspuffer gelesen? Hat es TCP FIN'd?

Ja, die Gegenstelle sendet entsprechend ACKs, keine FIN oder ähnliches.

In der Tat, wenn Sie eine große Datei f , sehen wir das Problem, wenn Sie requests.put(url, data=f.read()) tun, aber nicht, wenn Sie requests.put(url, data=f) tun. Wenn wir ein Datei-Handle haben, würden wir uns natürlich nicht die Mühe machen, darauf zu lesen, aber der Punkt ist, dass beide Aufrufe die gleiche Anfrage generieren sollen, und eine Paketerfassung zeigt dies bis zu dem Punkt, an dem einer aufhört zu senden Pakete.

Hm. Ist es Ihnen möglich, ein kleines Repro-Szenario zusammenzustellen? Sehen Sie den gleichen Effekt bei anderen Hosts?

Wie es der Zufall so wollte, habe ich es bereits getan.

Github will mich anscheinend keine Dateien anhängen lassen, also:

#!/usr/bin/env python

import requests


MB = 1024 ** 2
GB = MB * 1024


if __name__ == '__main__':
    data = 'x' * 4 * GB
    resp = requests.put('http://localhost:8000', data=data)
    print resp

Und ein Server, gegen den es ausgeführt wird:

#!/usr/bin/env python

import BaseHTTPServer
import logging


READ_CHUNK = 1024 ** 2


class Handler(BaseHTTPServer.BaseHTTPRequestHandler):
    def do_PUT(self):
        logging.info("PUT request recieved")
        for header, value in self.headers.items():
            logging.info("header: %s = %s", header, value)

        length = int(self.headers['Content-Length'])

        logging.info("Content length %s, getting content...", length)

        while length:
            to_read = min(length, READ_CHUNK)
            logging.info("reading %s bytes...", to_read)
            self.rfile.read(to_read)
            length -= to_read

        logging.info("Recieved content")

        self.send_response(200)


def run(server_class=BaseHTTPServer.HTTPServer):
    server_address = ('', 8000)
    httpd = server_class(server_address, Handler)
    httpd.serve_forever()


if __name__ == '__main__':
    logging.basicConfig(
        level=logging.DEBUG,
        format="%(asctime)s %(levelname)s: %(message)s",
    )
    logging.debug("Starting server")
    run()

Offensichtlich ist dies nicht der Server, auf dem wir liefen, als wir zum ersten Mal auf dieses Problem stießen :)

Als ersten logischen Hinweis sollte ich darauf hinweisen, dass dies nicht unbedingt das gleiche Problem ist, wie es ursprünglich zu diesem Thema gemeldet wurde, da der ursprüngliche Bericht, wie oben beschrieben, nur TLS betraf. :wink: Egal, lassen Sie uns das ein bisschen untersuchen.

Oh, tut mir leid. Lohnt es sich dann, ein neues Heft zu eröffnen, oder soll ich es einfach hier lassen, da du es schon anschaust?

Lassen wir es vorerst hier. =)

Hm. Das verhält sich ... sehr seltsam. Auf meinem Computer sehe ich über das Loopback überhaupt keine gesendeten Daten: Es ist, als hätten Requests das Senden einfach aufgegeben. Weiteres Debugging scheint zu zeigen, dass dies auf der Ebene von socket.sendall geschieht, die aus irgendeinem absurden Grund einfach nicht die vollständige Antwort sendet. Mit "nicht die vollständige Antwort senden" meine ich, dass socket.sendall vorzeitig zurückkehrt , aber nachweislich nicht alle Daten sendet.

Der Grund dafür ist natürlich der gleiche wie der Grund, warum Python viele andere dumme Sachen macht: socket.sendall ist in C geschrieben. Das allererste, was socket.sendall tut, ist die Länge der Daten zu ermitteln das wurde hineingeschickt und schiebt es in ein C int . Das ist anfangs falsch: Py_buffer.len ist ein Py_ssize_t , und sizeof(ssize_t) ist häufig größer als sizeof(int) . Das ist also blödsinnig und wahrscheinlich die Quelle dieses Fehlers.

Tatsächlich ist es das definitiv, da der aktuelle Python-Master ein geändertes sendall , das die richtige Größe verwendet. Dies scheint um Python 3 herum als allgemeines "64-Bit-Problem" (siehe python/cpython@19467d27ff14ebe31978438078ed5a661ffd29fb) im Socket-Modul bereinigt worden zu sein.

Das macht dies letztendlich zu einem Duplikat der CPython-Ausgabe #18100 . Dies war lange Zeit offen und benötigte eine Patch-Überprüfung, und da Python 2.7 jetzt nur noch Sicherheitsfixes erhält, bezweifle ich, dass die CPython-Entwickler es zu diesem Zeitpunkt beheben werden.

Dies ist ein schwieriges Thema für Anfragen an eine vernünftige Polizei. Wir können sagen, wann die Leute es definitiv treffen werden (zB weil die Eingabe eine Zeichenfolge mit einer Länge von mehr als 2 GB ist), aber es gibt viele Situationen, in denen die Leute es treffen, aber wir können es nicht sagen (zB weil die Zeichenfolge plus die Header größer als 2 GB ist oder weil ein anderer Typ verwendet wird, den CPython als "strähnig" behandelt, der größer als 2 GB ist). Meine anfängliche Neigung ist daher, dass dies ein Problem ist, das durch den Wechsel zu einer neueren Version von Python gelöst werden kann und dass es umgangen werden kann, indem keine riesigen Strings in den Speicher gelesen werden (was sowieso eine Best-Practice ist) und dass, wenn wir jemals httplib verlassen, wir es sowieso automatisch beheben werden, neige ich zu der Annahme, dass wir wahrscheinlich keinen großen Druck haben, das Problem zu lösen? Ich für meinen Teil denke, das kommt dem "Dr., es tut weh, wenn ich das tue", ziemlich nahe. "Dann tu das also nicht!" Gebiet.

Ich bin jedoch bereit, hier anderer Meinung zu sein.

Die Problemumgehung ist wirklich einfach - packen Sie es einfach in StringIO / BytesIO ein, aber wenn Sie darauf stoßen, ist es schwierig zu diagnostizieren.

Ich kann die Idee einer PR, die einen Hinweis in die Dokumentation einfügt, unterstützen.

Wenn ich das gleiche Problem habe, habe ich in diesem Thread keine akzeptierte Lösung, hat jemand eine Lösung dafür?

Dies führt auch zu einem OverflowError in self._sslobj.write(data) :

files = {'file': open(tar_file_path, 'rb')}
headers = {'key': 'abc123'}
r = requests.post(url, files=files, headers=headers)

Die Datei ist 3GB groß.

@SpoonMeiser Das Umschließen des Dateiinhalts in ein BytesIO behebt das Problem in Python 3.6 nicht, wirft immer noch genau den gleichen Fehler auf.

Ich habe das gleiche grundlegende Problem wie @gjedeer und sehe das gleiche Verhalten wie @cmbasnett (das Einwickeln in BytesIO ist keine Lösung). Ich versuche, ein Dateiobjekt zu verwenden, um etwas größer als 2 GB mit einem TLS-verschlüsselten Beitrag hochzuladen. Insbesondere versuche ich, eine vorsignierte URL zu verwenden, um eine Datei auf S3 hochzuladen. Es scheint, dass die zugrunde liegende SSL-Bibliothek in Python keine Dateien über 2 GB mag. Gibt es dafür einen akzeptierten Workaround? Stapelverfolgung:

Grundcode:

 with open(self.path_to_data, 'rb') as f:
    fields = 'defined elsewhere...'
    files = {'file': f}
    request('post', url, data=fields, files=files)

Traceback (most recent call last):
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/bin/mds", line 11, in <module>
    load_entry_point('mdscli', 'console_scripts', 'mds')()
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/Users/coltonhicks/dev/mds_cli/mdscli/cli.py", line 133, in upload_member_data
    uploader.main()
  File "/Users/coltonhicks/dev/mds_cli/mdscli/upload_member_data.py", line 30, in main
    self.client.upload_member_data(self.mida, self.data_type, f)
  File "/Users/coltonhicks/dev/mds_cli/mdscli/requests_client.py", line 300, in upload_member_data
    logger.info(
  File "/Users/coltonhicks/dev/mds_cli/mdscli/requests_client.py", line 186, in _request
    res = requests.request(method, url, data=data, files=files)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
    timeout=timeout
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/urllib3/connectionpool.py", line 603, in urlopen
    chunked=chunked)
  File "/Users/coltonhicks/.virtualenvs/mds_cli-AtYG3_5U/lib/python3.7/site-packages/urllib3/connectionpool.py", line 355, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1229, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1275, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1224, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1055, in _send_output
    self.send(chunk)
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 977, in send
    self.sock.sendall(data)
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ssl.py", line 1015, in sendall
    v = self.send(byte_view[count:])
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ssl.py", line 984, in send
    return self._sslobj.write(data)
OverflowError: string longer than 2147483647 bytes

Zu den neueren (seit 2018) Fragen zur Lösung hier:
Die Problemumgehung mit Requests-Toolbelt funktioniert für mich in Python 3.8.

Der Request-Code zum Hochladen war der folgende:
requests.request(method, url, *args, **kwargs)
...wobei die Kwargs sind:
{'files': {'file': ({filename}', <_io.BufferedReader name='{filepath}'>), 'parent_dir': '/bert_files/bert_models'}, 'headers': {'Authorization': 'Token {token}'}} .
Wickeln Sie es so ein:

m = MultipartEncoder(
    fields={'file': (kwargs['files']['file'][1].name, open(kwargs['files']['file'][1].name, 'rb'), 'text/plain'),
            'parent_dir': kwargs['files']['parent_dir']}
)
del kwargs['files']
kwargs['data'] = m
kwargs['headers']['Content-Type'] =  m.content_type

...was zu diesen Kwargs führt:
{'headers': {'Authorization': 'Token {token}', 'Content-Type': 'multipart/form-data; boundary={boundary}'}, 'data': <MultipartEncoder: {'file': ('filename', <_io.BufferedReader name={filepath}'>, 'text/plain'), 'parent_dir': '{parent_tir}'}>}

So hat es bei mir perfekt funktioniert.