Soalan dan senario yang sesuai
Anda memiliki API gateway yang mungkin menapis lampiran berniat jahat, membuang medan peribadi, atau mentranskod respons. Permintaan origin berjaya, tetapi perwakilan downstream bukan lagi bait asal origin. Terangkan bila perlu mengembalikan 203, cara mengendalikan pengesah (validators), dan cara menghalang klien daripada menganggap data yang diubah sebagai data origin yang berwibawa.
HTTP 203 ialah respons berjaya yang menunjukkan bahawa proksi transformatif telah menukar pengepala atau kandungan daripada respons 200 origin. Ia merupakan isyarat protokol untuk "berjaya, tetapi diubah suai", bukan ralat generik atau status kebenaran.
Perkara yang diuji oleh penemu duga
- Sempadan yang tepat antara 203, 200, 304, 4xx, dan 5xx.
- Memahami bagaimana transformasi mempengaruhi cache, ETag, tandatangan, dan permintaan seterusnya.
- Pautan audit yang boleh dikesan antara perwakilan origin dan downstream.
- Mengendalikan pelbagai proksi, kegagalan origin, dan klien yang tidak memahami 203.
- Mengubah semantik protokol kepada pengepala yang boleh diuji dan tingkah laku cache.
Penjelasan sebelum menjawab
- Adakah perubahan tersebut merupakan penapisan perisian hasad, transkod, atau penyuntingan khusus pengguna? Ini mempengaruhi perkongsian cache.
- Bolehkah klien mengenali 203? Jika tidak, adakah lapisan keserasian diperlukan?
- Adakah perwakilan asal perlu boleh dikesan? Tandatangan dan rekod audit memerlukan kedua-dua versi.
- Adakah transformasi bersifat deterministik? Jika peraturan berbeza-beza, versi peraturan perlu dimasukkan ke dalam kunci cache.
Rangka jawapan 30 saat
Mula-mula saya mengesahkan sama ada get laluan menukar kandungan aplikasi atau pengepala yang berkaitan. Respons origin yang berjaya dengan perwakilan yang diubah menerima 203; perwakilan yang tidak disentuh kekal 200. 203 tidak menggantikan 304, yang hanya mengesahkan perwakilan sedia ada klien. Saya menjana ETag untuk perwakilan downstream dan menyertakan rundingan kandungan, versi peraturan, dan sempadan penyewa dalam kunci cache. Rekod audit memautkan versi origin kepada output yang diubah. Kegagalan origin mengekalkan semantik kegagalan sebenar mereka.
Jawapan mendalam langkah demi langkah
1. Menetapkan sempadan kod status
200 menyatakan bahawa respons semasa berjaya tanpa mengisytiharkan transformasi aplikasi. 203 menyatakan permintaan berjaya tetapi proksi transformatif telah menukar pengepala atau kandungan daripada respons 200 origin. 304 tidak membawa perwakilan baharu dan meminta klien menggunakan semula perwakilan yang telah disahkan. Kegagalan penapisan, penolakan, dan tamat masa origin menggunakan semantik 4xx atau 5xx yang sesuai.
2. Mengklasifikasikan transformasi
Menggantikan URL yang disekat oleh perisian hasad, penapisan privasi, transkod format, dan metadata cermin boleh mewajarkan 203. Menukar pemampatan pemindahan atau medan hop-by-hop sahaja biasanya tidak mengubah perwakilan aplikasi. Get laluan harus merekodkan perkara yang berubah dan sebabnya.
3. Mengira semula pengesah
ETag origin menerangkan perwakilan origin. Output yang diubah memerlukan ETag downstream yang sah untuk output tersebut. Jika versi peraturan menukar bait, sertakannya dalam kunci cache atau input pengesah; jika tidak, pelancaran peraturan boleh menggunakan semula output lapuk.
4. Mereka bentuk caching dan rundingan
Vary, pengekodan kandungan, bahasa, penyewa, dan peraturan transformasi semuanya mempengaruhi kebolehkongsian. Jadikan hasil sensitif privasi kepada caching peribadi secara lalai; kongsi hanya transformasi awam yang deterministik. Untuk If-None-Match, sahkan perwakilan get laluan dan bukannya memajukan 304 origin untuk bait yang tidak dimiliki oleh klien.
5. Melindungi tandatangan dan jejak audit
Tandatangan origin ke atas bait asal tidak boleh membuktikan badan downstream yang telah diubah suai. Tandatangan semula perwakilan yang diubah atau buang tandatangan yang tidak sah. Log ID permintaan origin, ETag origin, versi peraturan, ETag output, dan sebab transformasi.
6. Mengendalikan pelbagai proksi
Setiap lapisan harus mengekalkan asal usul transformasi dan mengelakkan pengulangan peraturan bukan idempoten. Jika klien tidak dapat memahami 203, lapisan keserasian eksplisit boleh mengembalikan 200 dengan metadata yang didokumenkan, tetapi ia tidak boleh menyembunyikan transformasi keselamatan atau privasi secara senyap.
7. Mengesahkan dan membuat pengembalian semula (rollback)
Uji origin 200, 203 yang diubah, 200 yang tidak disentuh, downstream 304, pelancaran peraturan, tamat masa origin, dan kegagalan penapis. Semasa pengembalian semula, pastikan ETag lama dan baharu tidak boleh bertembung serta periksa entri cache kongsi yang dibuat di bawah peraturan lama.
Contoh jawapan berkualiti tinggi
Saya menganggap 203 sebagai pengisytiharan "permintaan berjaya, tetapi proksi transformatif mengubah perwakilan origin." Respons aplikasi yang tidak disentuh kekal 200; respons yang diubah ialah 203; 304 hanya mengesahkan perwakilan downstream dan tidak boleh disampaikan secara membuta tuli dari origin. Get laluan mencipta ETag baharu untuk bait yang diubah dan mengunci caching mengikut versi peraturan, rundingan, dan sempadan privasi. Jika tandatangan origin meliputi bait asal, get laluan menandatangani semula atau membuangnya. Ujian merangkumi 200/203/304, perubahan peraturan, rantaian proksi, dan kegagalan origin supaya klien tidak tersilap menganggap data yang ditapis sebagai data origin.
Kesilapan lazim
- Mengembalikan 203 untuk setiap respons proksi → semantik menjadi bising → gunakan ia hanya untuk perubahan perwakilan sebenar.
- Menggunakan semula ETag origin → pengesah menerangkan bait yang salah → jana satu untuk output downstream.
- Menganggap 203 sebagai ralat → klien mungkin mencuba semula atau mencetuskan amaran → kekalkan semantik kegagalan 4xx/5xx sebenar.
- Memajukan 304 origin secara membuta tuli → cache yang diubah mungkin tidak sah → sahkan perwakilan downstream.
- Mengabaikan versi peraturan → pelancaran boleh memberikan output lapuk → sertakan versi dalam kunci atau pengesah.
Soalan susulan dan respons
Adakah menukar Content-Encoding sahaja memerlukan 203?
Biasanya tidak. Pengekodan pemindahan ialah pengendalian pengangkutan; jika perwakilan aplikasi tidak berubah, kekalkan 200 dan gunakan peraturan rundingan biasa.
Bolehkah respons 203 dikongsi oleh cache?
Ya, jika transformasi adalah deterministik, setiap dimensi yang berbeza dimasukkan ke dalam kunci, dan tiada data peribadi pengguna. Output khusus penyewa harus bersifat peribadi.
Bagaimana jika 203 origin diubah sekali lagi oleh get laluan?
Kekalkan kedua-dua pautan asal usul, kira ETag akhir, dan sahkan keidempotenan. Jika keidempotenan tidak dijamin, benarkan satu transformasi sahaja.
Bolehkah lapisan keserasian menukar 203 kepada 200?
Ia boleh dilakukan apabila didokumenkan secara eksplisit, dengan metadata yang boleh dikesan dan pengelogan audit. Ia tidak boleh menyembunyikan penapisan keselamatan atau penyuntingan privasi secara senyap.
Bagaimana jika origin mengembalikan 304 tetapi tiada objek yang diubah wujud secara setempat?
Jangan kembalikan 304 secara langsung. Dapatkan perwakilan yang boleh digunakan dan ubah ia, atau kembalikan kegagalan yang mencerminkan ketiadaan perwakilan setempat.