Werkzeug: Werkzeug lumpuh setelah menulis ke pipa tertutup

Gunakan server WSGI produksi seperti Gunicorn atau uWSGI, bukan server pengembang Werkzeug.

Saya memiliki masalah yang sangat mirip kecuali bahwa saya menggunakan server dev Werkzeug untuk pengembangan (yaitu, AFAICT, tujuan penggunaannya), yaitu dengan browser yang terhubung langsung ke port 5000.

Kesalahan terjadi beberapa kali per jam, memaksa restart manual server untuk terus berkembang.

Berikut tracebacknya:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 659, in inner
    srv.serve_forever()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 499, in serve_forever
    HTTPServer.serve_forever(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 238, in serve_forever
    self._handle_request_noblock()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 297, in _handle_request_noblock
    self.handle_error(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 655, in __init__
    self.handle()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 216, in handle
    rv = BaseHTTPRequestHandler.handle(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle
    self.handle_one_request()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 251, in handle_one_request
    return self.run_wsgi()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi
    execute(self.server.app)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 186, in execute
    write(b'')
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write
    self.send_header(key, value)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 401, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

Saya mengalami masalah yang sama seperti @sfermigier dengan server pengembangan ( debug=True ), dan memiliki kesalahan traceback yang sama.

Perilaku ini biasanya terjadi dalam kasus yang sangat sederhana: Anda menggunakan semacam fitur pelengkapan otomatis. Browser memulai koneksi untuk token kueri, lalu berhenti dan memulai permintaan lain untuk token lainnya. Anda akan berakhir dengan banyak Pipa Rusak. Dan ini bukan masalah sampai rilis terakhir yang membuat server dev diblokir sepenuhnya.
Jadi, menyarankan untuk menggunakan server aplikasi berfitur lengkap adalah solusi yang baik tetapi saya masih melihat masalah di sini. Tentu saja masalah pengembangan saja tetapi fakta bahwa pemicunya sangat umum membuatnya mengganggu banyak pengembang yang tidak terbiasa dengan _protokol internal_.
Pipa yang rusak sangat umum (pikirkan tentang permintaan panjang karena kesalahan dan pengembang menekan tombol berhenti browser) dan tidak boleh merusak server pengembangan.
Hanya pendapat saya. :)

@xcash

Perilaku ini biasanya terjadi dalam kasus yang sangat sederhana: Anda menggunakan semacam fitur pelengkapan otomatis. Browser memulai koneksi untuk token kueri, lalu berhenti dan memulai permintaan lain untuk token lainnya.

Jika terkait, saya dapat mengonfirmasi bahwa saya mengalami masalah ini menggunakan browsersync dengan gulp.js .

Adakah yang punya solusi yang tidak termasuk menjalankan server WSGI? Sepertinya saya mengalami masalah ini dengan bot yang melakukan pemindaian SYN terhadap Host saya.

@glennzw dapatkah Anda lebih spesifik tentang lingkungan Anda? Anda seharusnya tidak membuat server dev Anda publik di web terbuka yang dapat diakses oleh bot. :) Dalam situasi seperti itu, seperti host demo untuk klien, selalu lebih baik menggunakan setidaknya server aplikasi nyata seperti gunicorn yang memiliki footprint yang sangat kecil.

FWIW, saya belum banyak mengikuti rilis dan masalah (sangat menjengkelkan) ini mulai terjadi pada saya antara Mei - Agustus 2016 yang terbaik yang saya tahu. Saya menambahkan ini ke setup.py install_requires = ['Werkzeug<0.11', 'flask<0.11', ... - yang tampaknya mengatasi masalah ini (IME, hanya menyematkan Werkzeug sepertinya tidak berhasil?)

Bagi saya kasus duplikasi cukup sederhana - memuat halaman, tetapi jangan biarkan selesai memuat. Artinya, cukup picu _any_ kesalahan pipa yang rusak - dan server web akan mogok dan gagal melayani permintaan lainnya. IMHO, server web tidak dapat _jatuh_ ketika klien menutup koneksi sebelum waktunya - bahkan yang pengembangan.

Mungkinkah Anda semua memiliki passthrough_errors suatu tempat?

@untitaker dalam hal ini, palet/termos#1674 palet/labu#1679 palet/labu#1928 mungkin terkait?

Saya tidak tahu, saya ingin salah satu wartawan mengkonfirmasi.

Pada 26 Agustus 2016 17:05:25 CEST, David Lord [email protected] menulis:

@untitaker dalam hal ini, palet/labu#1674 palet/labu#1679
pallets/flask#1928 mungkin terkait?

Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242761250

Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

cc @miguelgrinberg

Saya pikir Werkzeug harus menangani pipa yang rusak dan kesalahan pengaturan ulang koneksi. Ini benar-benar bukan indikasi kesalahan, klien pergi begitu saja. Tampaknya dalam kasus ini pengecualian khusus harus dimunculkan, pengecualian yang dikenali oleh cara catch-all di atas sebagai pengecualian untuk diabaikan, bahkan jika kesalahan passthrough diatur.

Inilah cara gunicorn melakukannya: https://github.com/benoitc/gunicorn/blob/39f62ac66beaf83ceccefbfabd5e3af7735d2aff/gunicorn/workers/sync.py#L151 -L154

Itulah yang seharusnya dilakukan. Saya mencoba mencari cara untuk mereproduksi
perilaku ini, tetapi belum ada testcase yang jelas. Oleh karena itu pertanyaannya
tentang passthrough_errors .

Saya menduga ini bukan bug di Werkzeug, dan browser pengguna
hanya memiliki koneksi yang masih terbuka yang memblokir permintaan lain (alih-alih
server mogok). Jika Anda menutup browser dan membuka kembali, server harus
berfungsi lagi.

Pada Jumat, 26 Agustus 2016 pukul 11:54:16AM -0700, Miguel Grinberg menulis:

Saya pikir Werkzeug harus menangani pipa yang rusak dan kesalahan pengaturan ulang koneksi. Ini benar-benar bukan indikasi kesalahan, klien pergi begitu saja. Tampaknya dalam kasus ini pengecualian khusus harus dimunculkan, pengecualian yang dikenali oleh cara catch-all di atas sebagai pengecualian untuk diabaikan, bahkan jika kesalahan passthrough diatur.

Inilah cara gunicorn melakukannya: https://github.com/benoitc/gunicorn/blob/39f62ac66beaf83ceccefbfabd5e3af7735d2aff/gunicorn/workers/sync.py#L151 -L154

Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242821084

Oh, dan kesalahan pipa yang rusak _are_ ditampilkan, ya, tetapi mereka tidak boleh menutup server seperti yang dijelaskan. Lihat komentar sebelumnya tentang kemungkinan alasannya.

Saya menguji lagi bit terbaru dan saya masih melihat perilaku yang sama di lingkungan saya. Tetapi karena Anda tampaknya mengalami kesulitan untuk bereproduksi, saya mencoba menjelaskan mengapa saya istimewa.

import time
from flask import Flask
app = Flask(__name__)


@app.route('/')
def hello_world():
    time.sleep(5)
    return 'Hello, World!'


if __name__ == "__main__":
    app.run()

Ini berfungsi seperti yang diharapkan dengan flask run tetapi server web akan macet jika Anda menutup browser web Anda sebelum membiarkan respons diberikan ketika dimulai melalui python hello.py

Tampaknya sebagian dari respons Anda hilang.

Pada Jum, 26 Agustus 2016 pukul 12:29:39 PM -0700, clayg menulis:

Saya menguji lagi bit terbaru dan saya masih melihat perilaku yang sama di lingkungan saya. Tetapi karena Anda tampaknya mengalami kesulitan untuk bereproduksi, saya mencoba menjelaskan mengapa saya istimewa.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment-242829536

ya, dalam slack triple-ticks adalah cara Anda memblokir kutipan dan ctrl-return adalah cara Anda membuat baris baru
di github, triple-ticks adalah cara Anda memblokir kutipan, tetapi ctrl-return adalah cara Anda mengirimkan
... bagaimanapun ... memori otot

Saya mengedit posting saya segera setelah mengirimkannya untuk menyelesaikannya - dan saya hanya menanggapi karena tampaknya Anda membalas dari email dan saya tidak yakin github akan mengirimi Anda pemberitahuan lain setelah saya mengeditnya.

Saya tidak dapat mereproduksi dengan tes tidur oleh @clayg di atas. Saya sebenarnya tidak mendapatkan kesalahan pipa rusak sama sekali. Saya menutup browser sebelum permintaan itu mengembalikan respons, tetapi Werkzeug tetap menjalankan permintaan itu sampai akhir, ia mencetak 200 baris log ke konsol dan tidak menunjukkan kesalahan apa pun.

Saya juga mencoba trik yang sama menggunakan contoh streaming video flask saya yang menggunakan respons streaming untuk menyediakan bingkai video dalam aliran yang tidak pernah berakhir, dan bahkan untuk yang itu, saya dapat menutup browser dan permintaan berakhir tanpa kesalahan. Yang ini aneh, karena saya yakin di masa lalu aplikasi ini akan memicu kesalahan pipa putus ke konsol sebelum mengakhiri permintaan.

Sebenarnya, saya berbicara terlalu cepat. Saya dapat mereproduksi setiap saat dengan aplikasi streaming video saya saat menggunakan Python 2.7. Saya tidak dapat mereproduksi pada 3.5. Semua jejak tumpukan di atas adalah untuk 2.7, jadi ingatlah itu jika Anda menguji dengan Python 3.

Satu lagi poin data yang menarik. Jika berjalan dengan reloader, ketika proses anak keluar, proses master yang menjalankan reloader memulai yang lain, jadi tidak ada gangguan. Tetapi jika Anda menjalankan server tanpa reloader, kesalahan pipa yang rusak membawa Anda kembali ke konsol.

Sunting: abaikan reloader yang memulai bagian proses lain, yang sepertinya tidak terjadi dan sebaliknya saya mungkin melihat efek mengubah pengaturan kesalahan passthrough.

Oke, inilah analisis dari apa yang menurut saya sedang terjadi:

• Klien pergi di tengah permintaan
• Permintaan terus berjalan. Sambungan soket tampaknya disangga, jadi dalam kebanyakan kasus, menulis ke soket tidak akan menimbulkan masalah.
• Setelah permintaan berakhir, kelas server soket akan mengeluarkan flush() pada soket. Ini adalah subjek dari bug lama di pustaka Python yang saat ini diperbaiki: http://bugs.python.org/issue14574. Solusi dalam perbaikan ini adalah menangkap socket.error dan mengabaikannya.
• Kemudian socket server mencoba untuk menutup koneksi. Ini adalah bingkai tumpukan berikut, dari penelusuran balik dari OP:

File "/usr/lib/python2.7/SocketServer.py", line 710, in finish self.wfile.close()

• Sayangnya, di Python 2.7, hal pertama yang dilakukan metode socket.close() adalah menyiram lagi:

File "/usr/lib/python2.7/socket.py", line 279, in close self.flush()

• Upaya kedua pada flush ini tidak dilindungi dengan try/except, sehingga memunculkan pengecualian EPIPE.
• Server soket menangkap pengecualian, dan kemudian mengirimkannya ke metode handle_error() server.
• Implementasi Werkzeug dari handle_error() melihat pada pengaturan passthrough_errors , dan karena ini selalu disetel ke True , memunculkan kembali kesalahan EPIPE dan membiarkannya naik ke atas.

Kode soket pada Python 3 benar-benar berbeda, dan khususnya, tampaknya tidak memiliki panggilan flush tanpa mencoba/kecuali di sekitarnya. Kesalahan EPIPE bahkan tidak menggelembung ke Werkzeug saat menggunakan Python 3.

Apakah kita bahkan memiliki passthrough_errors yang disetel ke true? Di Werkzeug itu salah secara default.

Pada 27 Agustus 2016 02:10:13 CEST, Miguel Grinberg [email protected] menulis:

Oke, inilah analisis dari apa yang menurut saya sedang terjadi:

• Klien pergi di tengah permintaan
• Permintaan terus berjalan. Koneksi soket tampaknya
  buffered, jadi dalam banyak kasus, menulis ke soket tidak akan menyebabkan
  masalah.
• Setelah permintaan berakhir, kelas server soket akan mengeluarkan flush()
  pada soket. Ini adalah subjek dari bug lama di perpustakaan Python
  yang saat ini diperbaiki: http://bugs.python.org/issue14574 . NS
  solusi dalam perbaikan ini adalah menangkap socket.error dan mengabaikannya.
• Kemudian socket server mencoba untuk menutup koneksi. Ini adalah
  bingkai tumpukan berikut, dari penelusuran balik dari OP:

 File "/usr/lib/python2.7/SocketServer.py", line 710, in finish
 self.wfile.close()

• Sayangnya, di Python 2.7, hal pertama yang socket.close()
  metode yang dilakukan adalah menyiram lagi:

 File "/usr/lib/python2.7/socket.py", line 279, in close
 self.flush()

• Percobaan kedua pada flush ini tidak dilindungi dengan percobaan/kecuali, jadi
  itu menimbulkan pengecualian EPIPE.
• Server soket menangkap pengecualian, dan kemudian mengirimkannya ke
  metode handle_error() server.
• Implementasi Werkzeug dari handle_error() melihat pada
  passthrough_errors , dan karena ini selalu disetel ke
  True , memunculkan kembali kesalahan EPIPE dan membiarkannya naik ke atas.

Kode soket pada Python 3 benar-benar berbeda, dan khususnya,
tampaknya tidak ada panggilan flush tanpa mencoba/kecuali sekitar
mereka. Kesalahan EPIPE bahkan tidak menggelembung ke Werkzeug saat menggunakan
Python 3.

Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242881523

Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

Oh, ahem: https://github.com/pallets/flask/pull/1679

Saya pikir passthrough_errors harus bergantung pada app.debug . NVM, tidak berguna

Saya tidak melihat pilihan selain mengembalikan PR itu sebenarnya. passthrough_errors=True hanya melakukan apa yang seharusnya dilakukan, yang bukan merupakan perilaku default yang baik jika seseorang belum memasang debugger ke program.

Tidak apa-apa, saya menemukan cara lain. Dua PR:

• https://github.com/pallets/flask/pull/1996 -- ini akan memperbaiki masalah sendiri, kecuali traceback masih terlihat
• https://github.com/pallets/werkzeug/pull/998 -- bahkan jika passthrough_errors=True , jangan pernah memunculkan kembali kesalahan soket. Saya tidak berpikir itu pernah menjadi niatnya

Karena keduanya adalah perubahan perilaku dalam arti luas, saya lebih suka tidak mendukungnya.

Saya pikir https://github.com/pallets/flask/pull/1996 adalah solusi yang dapat diterima. Yang penting adalah itu memperbaiki kasus umum di mana Anda tidak ingin pengecualian disebarkan. Jika Anda ingin menyebarkan, maka Anda sedang men-debug, dan dalam hal ini mendapatkan socket.error disebarkan ketika tidak seharusnya bukan masalah besar.

Perbaikan https://github.com/pallets/werkzeug/pull/998 tidak bagus. Aplikasi mungkin memunculkan pengecualian ini secara sah dari sesuatu yang dilakukannya dengan soket di penangannya sendiri, dan itu juga akan dibungkam. Solusi idealnya adalah bahwa ini ditangkap di tempat terjadinya dan kemudian dinaikkan kembali sebagai beberapa kelas pengecualian khusus yang dapat dikenali dan diabaikan oleh handle_error . Mengingat bahwa kita mungkin tidak ingin mengubah atau membebani SocketServer , saya pikir pilihan saya adalah membiarkan bagian ini apa adanya. Anda akan mendapatkan EPIPE dibuang ke konsol, tetapi hanya pada Python 2, dan setidaknya itu tidak akan menghentikan server setelah perbaikan lainnya masuk. Ini tidak berbahaya, dan itu adalah perilaku yang ada di masa lalu, sebelum saya membuat passthrough_errors perubahan.

Perilaku yang Anda gambarkan hanya terjadi dengan PASSTHROUGH_ERRORS diaktifkan. Jika tidak, pengecualian ditangkap dari dalam Flask.

Saya kira perbaikan kosmetik ini tidak sepadan.

Pada 27 Agustus 2016 18:29:30 CEST, Miguel Grinberg [email protected] menulis:

Saya pikir https://github.com/pallets/flask/pull/1996 dapat diterima
larutan. Yang penting adalah memperbaiki kasus umum di mana
Anda tidak ingin pengecualian disebarkan. Jika Anda ingin menyebarkan,
kemudian Anda men-debug, dan dalam hal ini mendapatkan socket.error
disebarkan ketika seharusnya tidak bukan masalah besar.

Perbaikan https://github.com/pallets/werkzeug/pull/998 tidak bagus
meskipun. Aplikasi mungkin memunculkan pengecualian ini secara sah dari
sesuatu yang dilakukannya dengan soket di penangannya sendiri, dan itu akan
dibungkam juga. Solusi ideal adalah bahwa ini ditangkap
di tempat mereka terjadi dan kemudian diangkat kembali sebagai beberapa pengecualian khusus
kelas yang handle_error dapat mengenali dan mengabaikan. Mengingat bahwa kita
mungkin tidak ingin mengubah atau membebani SocketServer , saya pikir saya
pemungutan suara adalah membiarkan bagian ini apa adanya. Anda akan mendapatkan EPIPE yang dibuang ke
konsol, tetapi hanya di Python 2, dan setidaknya itu tidak akan berhenti
server setelah perbaikan lainnya masuk. Ini tidak berbahaya, dan itu a
perilaku yang ada di masa lalu, sebelum saya membuat
passthrough_errors perubahan.

Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242926832

Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

Tetap di master.

Perilaku yang Anda gambarkan hanya terjadi dengan PASSTHROUGH_ERRORS diaktifkan

Ya, saya menghilangkan detail itu. Tetapi perubahan ini bahkan akan memengaruhi Python 3, di mana semua ini tidak menjadi masalah. Pada Py3, dengan kesalahan passthrough diaktifkan, socket.error sah yang dimunculkan oleh aplikasi akan dibungkam.

master tampaknya wfm, menantikan rilis berikutnya, terima kasih!

Hai, saya menggunakan server dev Werkzeug yang berjalan di belakang NGINX, saya menghadapi masalah yang sama, adakah yang bisa membantu saya dengan ini,
11:13:11 web.1 | 127.0.0.1 - - [15/Sep/2016 11:13:11] "GET /api/method/frappe.utils.print_format.download_pdf?doctype=Purchase%20Order&name=PO-00001&format=PO&no_letterhead=0 HTTP/1.1" 200 - 11:13:11 web.1 | Error on request: 11:13:11 web.1 | Traceback (most recent call last): 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi 11:13:11 web.1 | execute(self.server.app) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 184, in execute 11:13:11 web.1 | write(data) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write 11:13:11 web.1 | self.send_header(key, value) 11:13:11 web.1 | File "/usr/lib/python2.7/BaseHTTPServer.py", line 401, in send_header 11:13:11 web.1 | self.wfile.write("%s: %s\r\n" % (keyword, value)) 11:13:11 web.1 | IOError: [Errno 32] Broken pipe

Tolong bantu

Ragav menggunakan server aplikasi lain alih-alih dev bawaan werkzeug
server, seperti gunicorn. Ini satu-satunya solusi saat ini.

15-09-2016 8:07 GMT+02:00 Ragav [email protected] :

Hai, saya menggunakan server pengembang Werkzeug yang berjalan di belakang NGINX, saya menghadapi
masalah yang sama adakah yang bisa membantu saya dengan ini, ```
11:13:11 web.1 | 127.0.0.1 - - [15/Sep/2016 11:13:11] "DAPATKAN
/api/method/frappe.utils.print_format.download_pdf?
doctype=Pembelian%20Pesanan&nama=PO-00001&format=PO&no_kepala surat=0
HTTP/1.1" 200 -
11:13:11 web.1 | Kesalahan berdasarkan permintaan:
11:13:11 web.1 | Traceback (panggilan terakhir terakhir):
11:13:11 web.1 | File "/home/ommi/frappe-bench/env/
lib/python2.7/site-packages/werkzeug/serving.py", baris 193, di run_wsgi
11:13:11 web.1 | jalankan (self.server.app)
11:13:11 web.1 | File "/home/ommi/frappe-bench/env/
lib/python2.7/site-packages/werkzeug/serving.py", baris 184, di eksekusi
11:13:11 web.1 | tulis (data)
11:13:11 web.1 | File "/home/ommi/frappe-bench/env/
lib/python2.7/site-packages/werkzeug/serving.py", baris 152, secara tertulis
11:13:11 web.1 | self.send_header(kunci, nilai)
11:13:11 web.1 | File "/usr/lib/python2.7/BaseHTTPServer.py", baris 401,
di send_header
11:13:11 web.1 | self.wfile.write("%s: %s\r\n" % (kata kunci, nilai))
11:13:11 web.1 | IOError: [Errno 32] Pipa rusak

Tolong bantu

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pallets/werkzeug/issues/954#issuecomment -247243400,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AA6MZ6DNiRIfL91CLeYOoA70W9_nQQzGks5qqOCMgaJpZM4I58cy
.

Dipandu oleh komit perbaikan baru-baru ini, saya dapat memperbaiki masalah ini dengan memanggil app.run dengan passthrough_errors=False. YMMV

Bug yang menyebabkan crash telah diperbaiki di Versi 0.12 , Dirilis pada 21 Desember 2016.

• Kembalikan perubahan perilaku yang membuat server dev mogok alih-alih mengembalikan Kesalahan Server Internal (permintaan tarik #2006).

Versi 0.12 baru dirilis minggu lalu.

Pada Senin, 20 Maret 2017 pukul 09:05:00 -0700, Alan Rotman menulis:

Bug yang menyebabkan crash telah diperbaiki di Versi 0.12 , Dirilis pada 21 Desember 2016.

• Kembalikan perubahan perilaku yang membuat server dev mogok alih-alih mengembalikan Kesalahan Server Internal (permintaan tarik #2006).

--
Anda menerima ini karena Anda mengubah status buka/tutup.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -287807602

Saya baru saja melihat ReleaseNotes hari ini, dan telah lama menunggu perbaikan ini.

Lihat di: http://flask.pocoo.org/docs/0.12/changelog/
Versi 0.12
Dirilis pada 21 Desember 2016, dengan nama kode Punsch.

https://pypi.python.org/pypi/Flask/0.12
Jenis File Versi Py Diunggah pada Ukuran
Flask-0.12-py2.py3-none-any.whl (md5) Roda Python 2.7 2016-12-21 80KB
Flask-0.12.tar.gz (md5) Sumber 2016-12-21 519KB

Ah, ya, maksudmu Flask. Tentu.

Pada Senin, 20 Maret 2017 pukul 09:22:15 -0700, Alan Rotman menulis:

Saya baru saja melihat ReleaseNotes hari ini, dan telah lama menunggu perbaikan ini.

Lihat di: http://flask.pocoo.org/docs/0.12/changelog/
Versi 0.12
Dirilis pada 21 Desember 2016, dengan nama kode Punsch.

https://pypi.python.org/pypi/Flask/0.12
Jenis File Versi Py Diunggah pada Ukuran
Flask-0.12-py2.py3-none-any.whl (md5) Roda Python 2.7 2016-12-21 80KB
Flask-0.12.tar.gz (md5) Sumber 2016-12-21 519KB

--
Anda menerima ini karena Anda mengubah status buka/tutup.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -287813405

Sekedar catatan untuk siapa saja yang mengalami masalah ini saat menjalankan flask 0.12.2 di werkzeug dalam mode threaded=True:
Dalam mode berulir, menjadi default sepertinya setiap utas werkzeug sebenarnya masih memiliki masalah ini, yaitu jika Anda meminta rute yang membutuhkan waktu untuk kembali, dan kemudian menutup koneksi dari klien, werkzeug tertentu mencatat IOError Broken Pipe dan kemudian mati. Server secara keseluruhan terus berfungsi, kecuali bahwa dalam aplikasi saya, saya menemukan bahwa ini entah bagaimana menyebabkan kebocoran memori, dengan proses labu tumbuh perlahan setelah pipa rusak di utas apa pun, menggunakan semua RAM dan kemudian SWAP dan akhirnya menjadi dibunuh oleh OS.
Mengirim passthrough_errors=False secara eksplisit di app.run tampaknya telah menyelesaikan masalah - utas tidak lagi mati ketika klien terputus, mereka dengan anggun mencatat IOError dan kemudian juga mencatat ini (yang tidak pernah saya lihat tanpa secara eksplisit mengatur passthrough_errors=False):

Exception happened during processing of request from ('127.0.0.1', 50652)
----------------------------------------

Dan kemudian server terus berjalan seperti biasa. Saya masih harus menunggu beberapa jam untuk melihat apakah kebocoran memori muncul lagi, tapi saya harap tidak.

Untuk berjaga-jaga jika itu bermanfaat bagi siapa saja.

Saya melihat kesalahan ini juga di wadah Ubuntu Docker di Kubernetes di Ubuntu VM:

Error on request:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 270, in run_wsgi
    execute(self.server.app)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 261, in execute
    write(data)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 227, in write
    self.send_header(key, value)
  File "/usr/lib/python2.7/BaseHTTPServer.py", line 412, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

Saya membuat VM xenial Ubuntu baru dan menjalankan kode yang sama di wadah Ubuntu Docker di Kubernetes, dan kesalahan ini tidak terlihat dan Python Flask berfungsi seperti yang diharapkan. Saya pikir itu masalah dengan Host saya (Ubuntu VM).

@vhosakot Bisakah Anda memberi tahu saya bagaimana Anda mengatur konfigurasi aplikasi Anda? Saya mengalami masalah serupa di lingkungan yang sama dengan Anda.

Dalam fungsi rute, saya menggunakan fungsi lain yang dimaksudkan untuk perutean.
Saya mengambil data dari respons fungsi itu.
Sekarang, ketika saya menggunakan _loads()_ pada data itu, saya mendapatkan kesalahan.

...
response = get_contents().data
        if response:
            data = loads(response)
..

Kesalahan: IOError: [Errno 32] Broken pipe