Prompt dan konteks
Satu get laluan cache menambah Warning: 110 - "Response is stale" dan Warning: 111 - "Revalidation failed". Pelayar dan perkhidmatan hiliran tidak memaparkan medan ini secara konsisten, dan piawaian yang lebih baharu tidak lagi mengesyorkannya. Terangkan semantik sejarah, sempadan pengesahan cache, medan penggantian, dan penghijrahan tanpa kehilangan (lossless).
Soalan ini sesuai untuk temu duga backend, get laluan, CDN, dan platform. Kuncinya adalah memisahkan metadata protokol, ralat pengguna, dan kebolehcerapan dalaman dan bukannya menggantikan satu pengepala yang ditamatkan dengan pengepala bentuk bebas yang lain.
Perkara yang diuji oleh penemu duga
Jawapan yang kukuh menerangkan bahawa Warning boleh menerangkan masalah mesej dan amaran 1xx berkaitan cache boleh dialih keluar selepas pengesahan berjaya. Ia juga menyatakan bahawa medan tersebut ditamatkan penggunaannya kerana ia tidak dijana atau dipaparkan secara meluas, manakala sebahagian daripada maklumatnya boleh disimpulkan daripada medan seperti Age. Calon harus menggunakan Cache-Control, Date, Age, pengesah (validators), kod status, dan metrik berstruktur dan bukannya kontrak klien bentuk bebas.
Soalan penjelasan untuk ditanya terlebih dahulu
- Adakah Warning dijana oleh origin, cache kongsi, atau get laluan pinggir (edge gateway), dan adakah terdapat berbilang lapisan proksi?
- Adakah 110 dan 111 untuk diagnostik sahaja, atau adakah klien menukar tingkah laku perniagaan berdasarkannya?
- Adakah respons mengandungi
Date,Age,Cache-Control,ETag, danLast-Modified? - Klien legasi yang manakah mesti disokong, dan bolehkah sistem melakukan dwi-tulis (dual-write) buat sementara waktu?
- Siapa yang memerlukan "fresh", "stale", dan "revalidation failed": pengguna, logik perniagaan, atau pengendali?
Rangka kerja jawapan 30 saat
"Saya akan menganggap Warning sebagai diagnostik cache sejarah, bukan kontrak ralat pengguna yang stabil. 110 menerangkan respons lapuk (stale) dan 111 menerangkan pengesahan semula yang gagal, tetapi medan itu telah ditamatkan dan tidak sesuai untuk teks bentuk bebas. Saya akan menginventori pengguna dan lapisan proksi, menyatakan fakta dengan Cache-Control, Date, Age, pengesah, dan metrik berstruktur, melakukan dwi-tulis hanya untuk tetingkap keserasian yang terhad, kemudian mengalih keluar Warning selepas memerhatikan tingkah laku klien. Kadar hit cache, penyajian lapuk, kegagalan pengesahan semula, dan metrik bajet ralat akan mengesahkan penghijrahan tersebut."
Jawapan mendalam langkah demi langkah
Langkah 1: Memulihkan peranan sejarah Warning
Warning ialah pengepala permintaan dan respons yang mengandungi kod tiga digit, ejen penjana, dan teks. Kod 110 dan 111 berkaitan cache menerangkan respons lapuk dan pengesahan semula yang gagal; ia bukan kod status HTTP dan tidak bermaksud 4xx atau 5xx. Pelbagai proksi boleh menambah medan, menjadikan sumber dan kepercayaan teks bentuk bebas tidak stabil.
Langkah 2: Terangkan sebab penghijrahan diperlukan
MDN menandakan Warning sebagai ditamatkan penggunaannya (deprecated) kerana ia tidak dijana atau dipaparkan secara meluas dan piawaian yang berkaitan tidak lagi mengesyorkan mekanisme amaran umum ini. Bergantung padanya mengikat diagnostik cache kepada teks yang tidak stabil dan menyukarkan penaakulan mengenai penduaan, penyusunan semula, atau penapisan oleh proksi. Mula-mula buktikan bahawa tiada klien yang menganggapnya sebagai isyarat perniagaan.
Langkah 3: Nyatakan fakta dengan medan cache standard
Date mengenal pasti masa penjanaan respons, manakala Age menganggarkan masa berada dalam cache kongsi. Cache-Control mentakrifkan keperluan kesegaran (freshness) dan pengesahan semula, dan ETag atau Last-Modified menyokong permintaan bersyarat. Bersama-sama ia menerangkan keadaan cache; rentetan tersuai X-Warning bukan pengganti. Origin juga mesti menetapkan Vary dengan betul supaya perwakilan bagi permintaan berbeza tidak bercampur.
Langkah 4: Pindahkan diagnostik ke dalam kebolehcerapan
Get laluan harus merekodkan peristiwa berstruktur seperti cache_status=stale, revalidation=failed, upstream=timeout, lapisan cache, dan ID surih (trace ID). Log harus mengelakkan nilai pertanyaan URL yang sensitif; metrik harus diagregatkan mengikut laluan, keluarga kunci cache (cache-key family), dan kelas ralat huluan. Respons hanya perlu membawa keadaan yang berkaitan dengan pengguna, manakala butiran operasi kekal dalam sistem yang terkawal.
Langkah 5: Reka bentuk tetingkap dwi-tulis keserasian
Berhenti menggunakan Warning pada trafik bayangan (shadow traffic) atau laluan kecil terlebih dahulu, memeriksa kebergantungan dalam SDK, skrip, dan peraturan proksi. Jika klien legasi wujud, kekalkan Warning secara ringkas sambil menerbitkan medan penggantian atau panduan naik taraf. Penggantian memerlukan enum yang stabil dan kontrak berversi, bukan teks sebarangan yang disalin. Berikan dwi-tulis tarikh tamat (sunset date) yang jelas.
Langkah 6: Mengendalikan cache berlapis dan kegagalan pengesahan
Pengesahan semula yang gagal tidak semestinya bermakna origin tergendala; ia boleh jadi tamat masa (timeout), permintaan bersyarat ditolak, atau 5xx dari huluan. Tentukan sama ada hendak menyajikan kandungan lapuk, mengembalikan ralat, atau menggunakan dasar stale-if-error, dan rekodkan sebabnya. Mengalih keluar Warning tidak boleh menyembunyikan penyajian lapuk atau mencipta percubaan semula tanpa henti.
Langkah 7: Pisahkan 103 Early Hints daripada amaran cache
103 Early Hints mendahului respons akhir dan memberi petunjuk tentang sumber yang mungkin, biasanya melalui Link untuk preconnect atau preload. Ia tidak melaporkan kesegaran cache atau kegagalan pengesahan semula dan tidak menggantikan Age atau Cache-Control. Nyatakan pemasaan, pengguna, dan semantik kegagalan bagi setiap medan daripada menganggap setiap petunjuk sebagai Warning.
Langkah 8: Alih keluar secara berperingkat dan sahkan
Bandingkan bacaan Warning, kadar hit cache, nisbah penyajian lapuk, kejayaan permintaan bersyarat, ralat origin, kependaman P95, dan ralat klien sebelum dan selepas penghijrahan. Nyahdayakan penjanaan dalam satu lapisan cache, luaskan merentasi rantaian, kemudian alih keluar kod, dokumentasi, dan amaran (alerts) selepas klien legasi bersih. Suis undur balik (rollback switch) hanya perlu memulihkan output keserasian, jangan sesekali memulihkan kebergantungan perniagaan pada Warning.
Pertukaran (trade-offs) dan sempadan
Mengekalkan Warning mempunyai kos keserasian jangka pendek yang rendah tetapi memanjangkan kontrak yang tidak stabil dan penyelesaian masalah yang samar-samar. Penyingkiran serta-merta mengurangkan hingar protokol tetapi boleh merosakkan skrip legasi. Laluan paling selamat ialah memerhatikan kebergantungan sebenar, kemudian memindahkan keperluan tersebut kepada medan cache standard dan kebolehcerapan berstruktur.
Jangan mentafsirkan Age sebagai masa penjanaan origin atau Cache-Control: no-cache sebagai "jangan simpan cache"; ia memerlukan pengesahan semula sebelum penggunaan semula. Dasar cache, pengesah, dan respons ralat mesti direka bentuk dengan tetingkap kesegaran yang boleh diterima oleh perniagaan.
Pelan pelancaran dan bukti
Pada minggu pertama, eksport laluan bacaan Warning daripada pinggir, cache kongsi, dan klien, bagi mewujudkan garis dasar mengikut laluan dan lapisan cache. Seterusnya, lakukan dwi-tulis metrik berstruktur pada laluan tanpa kebergantungan kritikal dan bandingkan Age, permintaan bersyarat, dan kadar ralat. Akhir sekali, nyahdayakan Warning lapisan demi lapisan sambil mengekalkan suis output keserasian satu klik.
Penerimaan memerlukan: tiada klien pengeluaran membaca Warning; kejayaan hit cache dan pengesahan semula tidak mengalami regresi; peristiwa stale-if-error boleh dijelaskan; log dan metrik dikorelasikan mengikut ID surih; dan dokumen, SDK, serta amaran dikemas kini.
Perangkap biasa dan tindakan susulan
Menganggap 110 sebagai 4xx atau 5xx
110 ialah kod Warning sejarah, bukan status respons. Ralat perniagaan tergolong dalam kontrak status dan respons; diagnostik cache tergolong dalam metrik.
Mencipta semula masalah dengan X-Warning
Teks bebas, penambahan proksi, dan keserasian versi kekal tidak menentu. Jika keserasian diperlukan, gunakan enum yang stabil, versi, dan pengguna yang jelas.
Mengalih keluar pengepala tanpa kebolehcerapan
Memadamkan medan tidak membetulkan penyajian lapuk atau pengesahan semula yang gagal. Wujudkan metrik keadaan cache, penjejakan (tracing), dan amaran sebelum mengalih keluar pengepala luaran.
Menganggap 103 Early Hints sebagai amaran cache
Pemasaan dan tujuan 103 adalah petunjuk sumber; ia tidak boleh menyatakan kesegaran atau kegagalan pengesahan semula. Kekalkan medan dan laluan pemprosesan yang berasingan.
Bagaimanakah anda membuktikan ia boleh dialih keluar?
Perhatikan bacaan klien, konfigurasi proksi, kadar ralat, dan metrik cache; jalankan tetingkap dwi-tulis yang terhad dan kembangkan selepas canary lapisan tunggal. Jangan padamkan secara global tanpa bukti kebergantungan.