Requests: "OverflowError: string lebih panjang dari 2147483647 byte" saat mencoba request.put

Daripada membaca seluruh file dan mengirimkannya dalam satu permintaan, apakah mungkin bagi Anda untuk menggunakan penyandian transfer chunked? http://docs.python-requests.org/en/latest/user/advanced/#chunk -encoded-requests

Batasan ini ada di httplib . Anda dapat dengan mudah menghindarinya dengan sedikit mengubah kode Anda:

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

@Lukasa itu tidak akurat. Traceback berasal dari soket yang dibungkus SSL. Ini tidak ada hubungannya dengan httplib dari apa yang saya lihat. OverflowErrors dinaikkan ketika nilai lebih besar dari ukuran integer C yang mendasarinya yang diizinkan. Ini dapat dilihat jika Anda memanggil len(something_larger_than_four_gb) pada sistem 32 bit.

Sayangnya sepertinya tidak bisa dihindari ketika Anda melakukan permintaan POST dengan beberapa header. Kemudian file (atau file-file) selalu dibaca sepenuhnya.

Akan sangat bagus jika ini dapat dihindari dalam permintaan karena saya sering harus mengirim file yang lebih panjang dari memori utama yang tersedia di sistem.

Aku hanya akan berpadu.

Jika Anda mencoba mengirim file melalui Web yang lebih besar dari
memori sistem dapat menangani, HTTP mungkin bukan protokol terbaik untuk melakukan ini
melalui.

Pada Selasa, 11 Okt 2016, 5:54 Erik Tews [email protected] menulis:

Sayangnya sepertinya tidak bisa dihindari ketika Anda melakukan POST
permintaan dengan beberapa header. Kemudian file (atau file) selalu dibaca
sama sekali.

Akan sangat bagus ketika ini bisa dihindari dalam permintaan karena saya sering
harus mengirim file yang lebih panjang dari memori utama yang tersedia di
sistem.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kennethreitz/requests/issues/2717#issuecomment -252729478,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AGk_7XIpx0UDRPXDuoopI7jDSfAlurgLks5qypf7gaJpZM4FqFGb
.

Itu benar, tapi saya tidak bisa memutuskan protokol dan titik akhir.

Melakukan permintaan dengan curl berfungsi dengan baik, dan sebagai solusinya, saat ini saya sedang mencetak perintah curl ke STDOUT sehingga pengguna dapat meluncurkannya.

@eriktews bisa share gimana uploadnya? Ada cara untuk streaming unggahan (seperti acara komentar Lukasa ). Apakah ada alasan mengapa Anda tidak dapat melakukan itu (jika Anda belum mencobanya)? Juga, dapatkah Anda memberikan traceback Anda yang sebenarnya?

Jadi komentar dari Lukasa sepertinya berfungsi ketika Anda mengunggah satu file, lalu Anda dapat melakukan unggahan streaming. Tetapi saya harus melakukan permintaan posting normal dengan beberapa variabel di bagian data dan file sebagai bagian dari unggahan multi-bagian.

Ada dokumentasi API di https://canvas.instructure.com/doc/api/file.file_uploads.html yang menunjukkan perintah curl di bagian "Langkah 2". Pada dasarnya saya ingin mereplikasi panggilan itu dengan paket permintaan dalam mode streaming.

Saya tidak memiliki traceback saat ini, tetapi ketika saya mendapatkannya, saya akan mempostingnya di sini.

Sudahkah Anda mencoba menggunakan MultipartEncoder dari request-toolbelt ? Itu memungkinkan Anda untuk melakukan streaming unggahan multipart/form-data seperti melakukan unggahan satu file. Itu ditulis khusus untuk kasus penggunaan ini dan telah ditambahkan ke dokumen kami.

Tidak, tapi sepertinya itu yang saya butuhkan. Saya akan mencobanya dan melihat apakah ini berhasil. Saya tidak tahu sama sekali tentang paket toolbelt, jadi mungkin Anda harus merujuknya di dokumentasi paket permintaan normal.

jadi mungkin Anda harus merujuknya dalam dokumentasi paket permintaan normal.

Dia :)

Metode @Lukasa tidak berfungsi - bahkan dengan httplib mati, penandatanganan masih terjadi untuk transportasi itu sendiri. Dalam kasus saya, saya memiliki permintaan POST 2GB+ (bukan file, hanya data POST). Ini untuk pembaruan massal elasticsearch. Titik akhir hanya memiliki HTTPS jadi saya sedang mengerjakan solusi lain sekarang.

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

Maaf, bisakah Anda menunjukkan kode Anda?

Ini harus membuang kesalahan:

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

Jika endpoint adalah https maka ssl harus memproses payload. Saya ingin tahu apakah requests atau requests-toolbelt dapat memiliki opsi untuk melakukan tanda tangan dengan beberapa perpustakaan lain yang tidak mati saat menandatangani string 2GB. Tentu saja, saya akan mengatakan bahwa orang tidak boleh menandatangani hal-hal besar seperti itu, tetapi itu pasti kecelakaan nyata yang terjadi di dunia nyata.

@adamn Itu bukan solusi yang saya usulkan. Solusi yang saya usulkan adalah tidak membaca file secara manual sama sekali. Anda mengalami kesalahan yang sama seperti sebelumnya, yaitu kami mengirim satu string raksasa ke httplib.

Ini adalah perilaku yang dapat kami perbaiki: jika kami melihat seseorang mengunggah string tunggal raksasa melalui Python maka kami dapat menyelesaikannya. Tetapi pada titik ini saya sangat menyarankan Anda menggunakan objek file perantara: baik yang ada di disk, atau dengan melakukan urlencoding sendiri dan membungkus hasilnya dalam BytesIO .

Saya sudah menemukan solusi jadi sayangnya tidak akan bisa menggali lebih dalam tentang ini. Saya masih curiga bahwa muatan SSL perlu ditandatangani/dienkripsi sehingga hal yang sama akan terjadi terlepas dari apakah ada objek file atau tidak karena pengecualian dimunculkan oleh ssl.write itu sendiri dan saya menganggap metode itu membutuhkan keseluruhan muatan. Memotong POST sepertinya satu-satunya pilihan nyata. Bagaimanapun, terima kasih atas bantuannya.

@adamn Tidak, itu tidak perlu. TLS menggunakan enkripsi aliran, tidak memerlukan seluruh muatan sekaligus.

Apa yang Anda lewatkan adalah ketika diberikan objek file, permintaan akan secara otomatis mengalirkannya dalam potongan yang lebih kecil (khususnya, potongan 8192 kb). Mereka tidak menyebabkan masalah.

Maaf untuk mengomentari masalah lama, tetapi ini terlihat _mirip_ dengan masalah yang kami hadapi dan saya mencoba memutuskan apakah perlu membuka masalah baru untuk itu.

Sekali lagi, requests.put mana data adalah string _huge_ tidak berfungsi, tetapi kami tidak mendapatkan kesalahan. permintaan hanya hang pengiriman; pengambilan paket menunjukkan bahwa tidak ada lagi data yang dikirim.

Perilaku ini _lebih buruk_ dari pengecualian yang dimunculkan.

Apakah rekan jarak jauh sudah ACKing di level TCP? Apakah masih membaca dari buffer penerima? Apakah itu TCP FIN'd?

Ya, ujung jarak jauh mengirim ACK dengan tepat, tidak ada FIN atau semacamnya.

Faktanya, jika Anda memiliki file besar f , kami melihat masalah jika Anda melakukannya requests.put(url, data=f.read()) tetapi tidak jika Anda melakukannya requests.put(url, data=f) . Jelas jika kami memiliki pegangan file, kami tidak akan repot-repot memanggil read di atasnya, tetapi intinya adalah bahwa kedua panggilan seharusnya menghasilkan permintaan yang sama, dan tangkapan paket menunjukkan bahwa mereka melakukannya sampai titik di mana seseorang berhenti mengirim paket.

Hm. Apakah mungkin bagi Anda untuk menyusun skenario repro kecil? Apakah Anda melihat efek yang sama dengan host lain?

Seperti keberuntungan, saya sudah melakukannya.

Github sepertinya tidak mengizinkan saya melampirkan file, jadi:

#!/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

Dan server untuk menjalankannya melawan:

#!/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()

Jelas ini bukan server yang kami hadapi ketika kami pertama kali mengalami masalah ini :)

Sebagai catatan logis pertama, saya harus menunjukkan bahwa ini bukanlah masalah yang sama seperti yang dilaporkan sebelumnya tentang masalah ini, karena laporan asli hanya memengaruhi TLS, seperti yang dibahas di atas. :wink: Apapun, mari kita gali ini sedikit.

Ah maaf. Apakah layak saya membuka edisi baru, atau haruskah saya biarkan saja di sini, karena Anda sudah melihatnya?

Mari kita tinggalkan di sini untuk saat ini. =)

Hah. Itu berperilaku ... sangat aneh. Di mesin saya, melalui loopback, saya tidak melihat data apa pun yang dikirim sama sekali: sepertinya Permintaan baru saja menyerah untuk mengirimnya. Debug lebih lanjut tampaknya menunjukkan ini terjadi pada level socket.sendall , yang karena alasan yang tidak masuk akal tidak mengirimkan respons lengkap. Dengan "tidak mengirim respons lengkap" maksud saya socket.sendall kembali lebih awal, tetapi terbukti tidak mengirim semua data.

Tentu, alasan ini terjadi sama dengan alasan Python melakukan banyak omong kosong bodoh lainnya: socket.sendall ditulis dalam C. Hal pertama yang dilakukan socket.sendall adalah mendapatkan panjang data yang dikirim ke dalamnya dan memasukkannya ke dalam C int . Sekarang, ini salah untuk memulai: Py_buffer.len adalah Py_ssize_t , dan sizeof(ssize_t) sering kali lebih besar dari sizeof(int) . Jadi itu sangat bodoh, dan mungkin sumber bug ini.

Faktanya, memang benar, karena master Python saat ini telah mengubah sendall yang menggunakan ukuran yang benar. Ini tampaknya telah dibersihkan sekitar Python 3 kali sebagai "masalah 64-bit" umum (lihat python/cpython@19467d27ff14ebe31978438078ed5a661ffd29fb) dalam modul soket.

Itu membuat ini pada akhirnya merupakan duplikat dari masalah CPython #18100 . Ini telah lama dibuka dan membutuhkan tinjauan tambalan, dan mengingat bahwa Python 2.7 sekarang hanya mendapatkan perbaikan keamanan, saya ragu pengembang CPython akan memperbaikinya pada saat ini.

Ini adalah masalah yang sulit untuk Permintaan untuk bijaksana polisi. Kita dapat mengetahui kapan orang pasti akan memukulnya (misalnya karena inputnya adalah string yang panjangnya lebih dari 2 GB), tetapi ada banyak situasi di mana orang akan memukulnya tetapi kita tidak dapat mengetahuinya (misalnya karena string ditambah headernya lebih besar dari 2GB, atau karena ada jenis penggunaan yang berbeda yang akan diperlakukan oleh CPython sebagai "stringish" yang lebih besar dari 2GB). Jadi kecenderungan awal saya adalah, mengingat ini adalah masalah yang dapat diselesaikan dengan pindah ke versi Python yang lebih baru, dan itu dapat diatasi dengan tidak membaca string raksasa ke dalam memori (yang merupakan praktik terbaik), dan bahwa jika kami pindah dari httplib, kami akan memperbaikinya secara otomatis, saya cenderung menyarankan bahwa kami mungkin tidak memiliki tekanan besar untuk menyelesaikan masalah? Bagi saya, saya pikir ini semakin mendekati "Dr, sakit ketika saya melakukan ini." "Kalau begitu jangan lakukan itu!" wilayah.

Namun, saya bersedia untuk tidak setuju dengan di sini.

Solusinya sangat sederhana - cukup bungkus dalam StringIO/BytesIO, tetapi ketika Anda mengalaminya, sulit untuk mendiagnosis, jadi bantuan apa pun yang dapat diberikan permintaan, bahkan jika itu hanya peringatan dalam dokumentasi, akan dihargai.

Saya bisa mendapatkan ide dari PR yang menambahkan catatan dalam dokumentasi.

Mengalami masalah yang sama, saya tidak memiliki utas ini memiliki solusi yang diterima, adakah yang punya solusi untuk ini?

Ini juga menghasilkan OverflowError di self._sslobj.write(data) :

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

Filenya berukuran 3GB.

@SpoonMeiser Membungkus konten file dalam BytesIO tidak memperbaiki masalah pada Python 3.6, masih menimbulkan kesalahan yang sama persis.

Saya mengalami masalah dasar yang sama dengan @gjedeer dan melihat perilaku yang sama dengan @cmbasnett (pembungkus dalam BytesIO bukanlah solusi). Saya mencoba menggunakan objek file untuk mengunggah sesuatu yang lebih besar dari 2GB menggunakan pos terenkripsi TLS. Secara khusus saya mencoba menggunakan url yang telah ditentukan untuk mengunggah file ke S3. Tampaknya pustaka ssl yang mendasarinya di python tidak menyukai file lebih dari 2GB. Apakah ada solusi yang diterima untuk ini? Jejak tumpukan:

Kode dasar:

 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

Mengenai pertanyaan yang lebih baru (sejak 2018) untuk solusi di sini:
Solusi menggunakan request-toolbelt berfungsi untuk saya di Python 3.8.

Kode permintaan untuk diunggah adalah sebagai berikut:
requests.request(method, url, *args, **kwargs)
... dengan kwarg menjadi:
{'files': {'file': ({filename}', <_io.BufferedReader name='{filepath}'>), 'parent_dir': '/bert_files/bert_models'}, 'headers': {'Authorization': 'Token {token}'}} .
Bungkusnya seperti ini:

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

...mengarah ke kwargs ini:
{'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}'}>}

Seperti ini itu bekerja dengan sempurna untuk saya.