Werkzeug: Werkzeug tidak sesuai dengan RFC2616

Perilaku ini disebabkan oleh spesifikasi WSGI itu sendiri, dan Werkzeug tidak mungkin membuat perbedaan antara kedua header tersebut sambil tetap mengikuti spesifikasi WSGI. Saya tidak tahu situasi apa pun di mana ini menjadi masalah dalam praktik.

Omong-omong, RFC 2616 sudah tidak digunakan lagi, tetapi RFC yang lebih baru tidak mengubah apa pun dalam hal itu.

Werkzeug juga tidak bertanggung jawab untuk menguraikan atau menulis permintaan atau tanggapan HTTP pada tingkat sintaksis. Ini dilakukan oleh server WSGI mana pun yang Anda pilih. Werkzeug memang memiliki server bawaan, tetapi itu hanya memperluas server WSGI dari pustaka standar.

Perilaku ini tidak disebabkan oleh spesifikasi WSGI, jika Anda mengacu pada PEP 3333.
PEP 3333 menyatakan bahwa:
Variabel HTTP_
Variabel yang sesuai dengan header permintaan HTTP yang disediakan klien (yaitu, variabel yang namanya dimulai dengan "HTTP_" ). Ada atau tidak adanya variabel ini harus sesuai dengan ada atau tidaknya header HTTP yang sesuai dalam permintaan.

Tidak ada dalam Spec tentang memperlakukan garis bawah secara berbeda. Faktanya, Anda tidak mengikuti PEP 3333 karena saya tidak tahu header mana yang ada atau tidak, yaitu jika "App_H" atau "App-H" ada.

WSGI adalah port CGI khusus Python. PEP 0333 mereferensikan spesifikasi CGI untuk definisi "variabel lingkungan CGI", yang menyatakan:

The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with "_" and has `HTTP_' prepended to give the meta-variable name.

Lihat https://tools.ietf.org/html/rfc3875#section -4.1.18

Semua ini tidak relevan karena Werkzeug, sebagian besar, tidak mengurai permintaan HTTP mentah dan tidak menghasilkan lingkungan WSGI. Ini mem-parsing lingkungan WSGI. Saya tidak mengerti mengapa Anda mengajukan masalah ini terhadap implementasi khusus ini. Jangan tembak utusan itu.

Pada dasarnya ada banyak warisan dari CGI di sini, yang diwarisi oleh WSGI, itulah yang coba diterapkan oleh Werkzeug.

Saya benar-benar tidak bermaksud untuk memulai perkelahian; Tetapi ini adalah masalah dengan implikasi keamanan, terutama untuk server web yang berada di belakang gateway aplikasi "warisan" yang meneruskan informasi sensitif/khusus aplikasi di header yang berisi garis bawah tanpa memfilter header lain (Saya punya contoh konkret, yaitu, ini sebenarnya merupakan masalah dalam praktik, yang telah Anda singkirkan dengan komentar awal Anda). CGI berusia lebih dari 20 tahun, oleh karena itu spesifikasi WSGI dan HTTP harus diutamakan.

Adapun penguraian mentah:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

(Saya punya contoh konkret, yaitu, ini sebenarnya adalah masalah dalam praktiknya, yang telah Anda tolak oleh komentar awal Anda)

Maka yang bisa saya katakan adalah saya menyesal Anda memiliki server seperti itu. Werkzeug tidak bisa berbuat apa-apa. Cuplikan yang Anda tunjukkan persis mengapa saya mengatakan "sebagian besar". Werkzeug juga menyertakan server uji sederhana yang dapat digunakan dalam pengembangan (untuk menghindari keharusan menyiapkan Gunicorn + Nginx/Apache, misalnya). Tetapi jika Anda mengekspos server itu ke internet, masalah potensial yang Anda sebutkan akan menjadi masalah (keamanan) Anda yang paling kecil.

WSGI dirancang agar kompatibel dengan CGI semaksimal mungkin. WSGI tidak menimpa atau menggantikan CGI. WSGI _is_ CGI. Ada sedikit pekerjaan yang terlibat dalam membuat aplikasi WSGI menjadi aplikasi CGI yang valid. os.environ dari skrip Python CGI sebagian besar terlihat seperti lingkungan WSGI yang setara. Ada banyak warisan yang perlu dipertimbangkan ketika mengubah apa pun tentang ini. Werkzeug sebagai proyek tidak memiliki suara dalam hal ini, dan terutama bukan saya.

Sekali lagi, masalah untuk proyek ini tidak ada gunanya. Werkzeug tidak sendirian dalam perilaku ini. Terakhir kali saya memeriksa nginx memblokir header HTTP dengan garis bawah secara default, karena seluruh masalah ambiguitas. Sebagian besar alat lain mungkin hanya menggabungkannya. Jika sebagian besar alat tidak dapat membedakan antara tanda hubung dan garis bawah, tidak masalah lagi ketika standar mengatakan ada satu. Semua orang dipaksa untuk bermain bersama, dan akhirnya alat yang mengeluarkan header dengan garis bawah yang harus disalahkan.