Requests: 418 Aku seorang Teko

BTW, saya sadar ini adalah perubahan yang melanggar; mencela dan menunda ke rilis besar berikutnya baik-baik saja.

Baris kode yang dimaksud: https://github.com/requests/requests/blob/master/requests/status_codes.py#L55

Harap perhatikan versi alternatif untuk 200 OK: https://github.com/requests/requests/blob/master/requests/status_codes.py#L13

Hah. Satu-satunya hal yang membuat saya khawatir adalah penggunaan unicode dan garis miring terbalik; permintaan tidak memancarkan itu, bukan?

Tidak, ini hanya untuk pencarian terbalik — sama dengan saya teko.

OK itu bagus. Masalahnya adalah bahwa implementasi digunakan sebagai bukti untuk mencegah penggunaan aktual dari kode status, yang _akhirnya_ akan menjadi masalah.

Silakan lihat https://github.com/nodejs/node/issues/14644 dan https://github.com/golang/go/issues/21326 untuk diskusi mengenai perubahan serupa.

Saya baik-baik saja dengan menghapusnya, kecuali jika kami ingin menambahkan kode status lain seperti 420 dan teman.

HTTPbin.org menyimpannya :)

Server individu, saya kurang peduli :)

Kirim PR!

Buat itu melawan cabang 3.0.0, ini akan menjadi perubahan yang melanggar.

Tahan! Saya orang di balik http://save418.com (https://github.com/WhataShane/save418). Saya, seperti banyak orang lain , senang menemukan (hampir seluruhnya) lelucon tidak berbahaya seperti 418. Ini adalah hal yang akan membuat Anda tersenyum bahkan ketika Anda ditekan untuk memenuhi tenggat waktu proyek dan bos Anda mengoceh pada Anda satu kantor selesai. Akan sangat memalukan untuk melihatnya pergi.

Mengutip @romellem dari utas Go, yang dengan fasih merangkum argumen untuk 418:

Untuk memperjelas, apakah argumen Anda bahwa ketika/jika blok 400 habis, kami ingin satu kode tambahan tersedia untuk memperluas kegunaan blok 400 sedikit lebih jauh?

Kecuali saya salah membacanya, 400 blok kode status HTTP memiliki lebih dari 50 kode yang tersedia. Dengan "ruang" yang tersedia dari blok 400 lebih dari 50%, ini mungkin merupakan pengoptimalan yang belum matang untuk masalah yang mungkin tidak akan pernah terjadi (yaitu, 400 blok kehabisan kode yang tersedia).

Tidak berusaha terdengar kasar, tetapi saya menyukai telur paskah kecil yang menyenangkan yang Anda temukan sepanjang karier pemrograman. Bagi saya, ini menunjukkan bahwa segala sesuatu yang membuat komputer benar-benar bekerja masih dibuat oleh manusia, dan menyimpan potongan kecil elemen manusia itu bagus (menurut saya). Argumen Anda masuk akal dan logis, tetapi perubahan yang diminta ini sedikit menurunkan "kesenangan" Go (dan berpotensi NodeJS) dalam semangat kekokohan rekayasa. Pada akhirnya, saya harus mengatakan bahwa saya tidak berpikir bahwa pengorbanan itu sepadan.

(Saya menghargai pelajaran sejarah! Saya selalu berpikir 418 adalah bagian dari spesifikasi HTTP/1.x; tidak tahu tentang spesifikasi "HTCPCP/1.0". )

Saya setuju bahwa ini adalah telur paskah yang menyenangkan.

Permintaan dianggap serius, tetapi tidak terlalu serius. :)

Ini mungkin kalimat "terlalu serius".

Bukankah jawaban yang jelas di sini untuk menjadikannya bagian dari spesifikasi dengan memulai dengan RFC baru?

@tSavo Jelas!

Meskipun saya mengenali 418 bukan bagian dari spesifikasi kode status HTTP di RFC 7231, itu memang ada di alam liar. Bahkan google telah menerapkannya di sini . Jika IETF memutuskan untuk menerapkan penggunaan nyata untuk 418, kami akan memiliki banyak peringatan untuk mengatasi hal ini. Saya mendukung untuk membiarkan ini apa adanya kecuali ada alasan yang lebih kuat yang perlu dihapus.

Beri aku kuncimu.

Untuk memperjelas, saya setuju dengan tim Permintaan lainnya: kita harus menyimpan pemetaan 418 di sini. Tapi alasan saya setuju adalah murni pragmatis, bukan karena menyenangkan telur Paskah (meskipun menyenangkan): codes.py digunakan untuk membangun pemetaan dari frase alasan untuk kode. Untuk alasan ini, itu harus menyertakan frasa alasan apa pun yang mungkin muncul untuk kode yang diberikan. Untuk saat itu adalah I'm A Teapot. Jika ini berubah, kami akan menambahkan frasa lain yang ditetapkan IANA.

@mnot , jangan ragu untuk menggunakan tanggapan ini sebagai komitmen yang mengatakan bahwa IETF/IANA harus merasa bebas untuk menggunakan kembali 418, dan tidak memblokirnya atas nama kami. Saya pikir frase alasan bagaimanapun juga bodoh.

Permintaan untuk mendaftar 418 telah diajukan ke IANA , dengan nomor 979050.

Baik; ini bukan forum diskusi untuk kebaikan 418. @mnot jika Anda ingin menindaklanjuti ini, kirimkan saya email. Untuk semua orang: kami menghargai masukan Anda, tetapi saya merasa cukup baik dengan keputusan yang telah kami buat.