Temuduga Umum: Bagaimana Anda Patut Menjelaskan HTTP 507 Insufficient Storage?

Prompt dan konteks

Prompt asas HTTP dan API ini sesuai untuk peranan backend, platform, SRE, dan infrastruktur. Permintaan pada dasarnya adalah sah, tetapi pelayan tidak dapat menyimpan keadaan sumber yang terhasil kerana kuota, sistem fail, belanjawan memori, atau had aplikasi telah habis. Jelaskan bila 507 bermakna, bila status lain lebih tepat, dan cara memulihkannya tanpa menduplikasi penulisan.

Perkara yang dinilai oleh penemuduga

• Bolehkah anda memisahkan kehabisan kapasiti bahagian pelayan daripada permintaan yang sememangnya terlalu besar?
• Adakah anda tahu bahawa 507 berasal dari WebDAV dan merupakan keadaan pelayan sementara dan bukannya ralat pengesahan generik?
• Bolehkah anda menentukan percubaan semula, backoff, keidempotenan, dan pemulihan yang dihadapi pengguna tanpa menyembunyikan puncanya?
• Bolehkah anda mengesan had merentasi lapisan aplikasi, storan, kuota, proksi, dan cache?

Soalan penjelasan untuk ditanya

Tanya operasi mana yang gagal, sama ada perwakilan yang diminta adalah sah, had sumber mana yang dicapai, sama ada had itu khusus untuk penyewa (tenant), dan sama ada operasi telah mengkomit keadaan separa. Sahkan sama ada klien boleh mencuba semula dengan selamat dan sama ada perkhidmatan tersebut mendedahkan isyarat kuota atau kapasiti. Jika muatan melebihi dasar atau had penghurai tanpa mengira kapasiti kosong, gunakan 413; jika perkhidmatan tidak tersedia buat sementara waktu atas sebab pemprosesan yang lebih luas, 503 mungkin lebih sesuai. Jangan pilih 507 hanya kerana amaran cakera wujud di suatu tempat dalam kumpulan pelayan.

Rangka kerja jawapan 30 saat

Saya akan mengembalikan 507 apabila operasi yang diminta adalah sah tetapi pelayan tidak dapat merekodkan keadaan sumber yang terhasil kerana storan yang tersedia atau had pelayan yang berkenaan telah habis. Saya akan membezakannya daripada 413, iaitu mengenai permintaan yang terlalu besar, dan daripada 503, yang mewakili ketidaktersediaan sementara yang lebih luas. Respons harus mendedahkan jenis masalah yang stabil dan ID permintaan tanpa membocorkan laluan dalaman. Klien mencuba semula hanya apabila operasi adalah idempoten atau mempunyai kunci keidempotenan, dengan backoff yang terhad; pengendali mengukur dimensi tepat yang habis, mengosongkan atau memperluas kapasiti, dan mengesahkan penulisan lengkap sebelum mengisytiharkan pemulihan.

Penyelaman mendalam langkah demi langkah

1. Kelaskan kegagalan. RFC 4918 mentakrifkan 507 untuk kaedah yang tidak dapat merekodkan keadaan sumber selepas pelaksanaan kerana destinasi kekurangan ruang yang mencukupi. MDN menyatakan bahawa pelaksanaan juga menggunakannya untuk sumber pelayan atau had aplikasi yang telah habis. Syarat utamanya ialah tindakan sah yang disekat oleh sempadan kapasiti bahagian pelayan.
2. Asingkan status yang berdekatan. Kembalikan 413 apabila kandungan terlalu besar tanpa bergantung pada kapasiti semasa. Kembalikan 409 atau 412 apabila konflik keadaan atau prasyarat gagal. Kembalikan 503 apabila perkhidmatan tidak dapat memproses permintaan secara umum dan mungkin menyediakan Retry-After. Respons 507 tidak seharusnya menjadi perangkap umum untuk setiap kegagalan penulisan.
3. Jadikan kegagalan boleh diambil tindakan. Gunakan jenis masalah yang stabil, tajuk yang boleh dibaca manusia, ID permintaan, dan petunjuk percubaan semula hanya jika kapasiti dijangka pulih. Kuota penyewa boleh merangkumi pengecam kuota selamat atau pautan pemulihan, manakala laluan sistem fail, nama hos, dan butiran dasar rahsia kekal dalaman.
4. Lindungi percubaan semula. Muat naik yang tamat masa boleh mempunyai keadaan komit yang tidak diketahui. Wajibkan kunci keidempotenan atau token muat naik boleh sambung, kekalkan keadaan operasi, dan pastikan klien menanyakan status sebelum memainkan semula. Gunakan backoff eksponen dengan batas masa (deadline); percubaan semula tanpa had boleh memburukkan lagi sistem yang penuh.
5. Kesan sempadan sumber. Rekodkan bait atau inod bebas, kuota storan objek, penggunaan pementasan pangkalan data/blob, had memori, peruntukan penyewa, dan lapisan yang mengeluarkan 507. Bandingkan log aplikasi dengan metrik storan dan ID permintaan supaya ralat yang dijana proksi tidak disalah anggap sebagai keputusan asal (origin).
6. Pulihkan dan sahkan. Salirkan (drain) atau tolak penulisan baharu jika perlu, kembangkan atau tuntut semula kapasiti, dan jalankan semula penulisan terhad menggunakan kunci keidempotenan asal. Sahkan checksum objek, metadata, keterlihatan, dan perakaunan kuota. Berikan amaran sekiranya berulang dan uji bahawa penyewa yang penuh tidak boleh menggunakan rizab penyewa lain.

Contoh jawapan yang kukuh

Saya akan menggunakan 507 hanya apabila permintaan adalah sah tetapi pelayan tidak dapat mengekalkan keadaan yang terhasil kerana had storan atau sumber pelayan telah habis. Muatan yang sentiasa terlalu besar ialah 413, dan keadaan penyelenggaraan atau beban berlebihan yang luas mungkin 503. Saya akan mengembalikan jenis masalah yang stabil dan ID permintaan, serta petunjuk percubaan semula hanya apabila pemulihan munasabah:

HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120

{
  "type": "https://api.example.com/problems/storage-exhausted",
  "title": "The resource could not be stored",
  "status": 507,
  "detail": "The workspace storage limit prevented this operation.",
  "request_id": "req-7f2"
}

Klien tidak boleh menghantar semula muat naik secara membuta tuli jika keadaan komitnya tidak diketahui. Ia mencuba semula dengan kunci keidempotenan yang sama atau meminta status operasi terlebih dahulu. Pengendali mengaitkan permintaan dengan metrik kuota, pementasan, storan objek, pangkalan data, dan inod, kemudian mengesahkan checksum, keterlihatan, dan perakaunan selepas kapasiti dipulihkan. Jika get laluan mengeluarkan 507 manakala origin mengembalikan 200, saya menganggap get laluan sebagai lapisan yang mengeluarkan dan menguji setiap lompatan secara bebas.

Kesilapan biasa

• Mengembalikan 507 untuk permintaan bersaiz terlalu besar → perubahan kapasiti tidak boleh menjadikan muatan itu sah → gunakan 413 untuk dasar saiz permintaan tetap.
• Mencuba semula setiap 507 serta-merta → sumber yang penuh menjadi lebih dipertikaikan → gunakan backoff terhad dan batas masa operasi.
• Memainkan semula muat naik selepas tamat masa → penulisan asal mungkin telah dikomit → buat pertanyaan status atau guna semula kunci keidempotenan.
• Mengatakan "cakera penuh" tanpa mencari sempadan → kuota, inod, pementasan, dan storan objek boleh gagal secara bebas → kenal pasti lapisan yang mengeluarkan dan dimensi yang habis.
• Melaporkan laluan mentah dan nama hos kepada klien → topologi dalaman dan data penyewa mungkin bocor → kembalikan jenis masalah yang stabil dan ID permintaan, sambil menyimpan diagnostik dalam log yang dilindungi.

Soalan susulan dan jawapan

Patutkah klien mencuba semula HTTP 507?

Hanya apabila operasi selamat untuk dicuba semula dan kapasiti dijangka pulih. Gunakan kunci keidempotenan atau carian status untuk penulisan, backoff eksponen, dan batas masa. Jika ralat mewakili kuota penyewa yang tegar, paparkan pemulihan dan bukannya mencuba semula.

Bagaimanakah anda membezakan 507 daripada 503?

507 mengenal pasti ketidakupayaan untuk merekodkan keadaan sumber yang sah kerana had storan atau pelayan telah habis. 503 ialah ketidakupayaan sementara yang lebih luas untuk menyampaikan permintaan dan mungkin merangkumi penyelenggaraan atau beban berlebihan. Gunakan sempadan kegagalan yang diukur dan dasar perkhidmatan yang konsisten dan bukannya meneka dari lapisan HTTP sahaja.

Bagaimana jika origin berjaya tetapi proksi mengembalikan 507?

Tangkap ID permintaan dan bandingkan permintaan terus ke origin, proksi, dan cache-cold. Proksi ialah lapisan yang mengeluarkan dan mungkin mempunyai penimbal atau kuotanya sendiri. Selaraskan keadaan akhir klien sebelum mencuba semula, kerana origin mungkin sudah mengandungi sumber tersebut.