Pertanyaan dan skenario yang sesuai
Anda mengelola API gateway yang dapat memfilter lampiran berbahaya, menghapus kolom privat, atau melakukan transcode pada respons. Permintaan ke origin berhasil, tetapi representasi downstream bukan lagi byte asli dari origin. Jelaskan kapan harus mengembalikan 203, bagaimana cara menangani validator, dan bagaimana mencegah klien memperlakukan data yang telah ditransformasi sebagai data origin yang otoritatif.
HTTP 203 adalah respons sukses yang mengindikasikan bahwa proxy transformatif mengubah header atau konten dari respons 200 origin. Ini adalah sinyal protokol untuk "sukses, tetapi ditransformasi", bukan status error umum atau otorisasi.
Apa yang sedang diuji oleh pewawancara
- Batasan akurat antara 203, 200, 304, 4xx, dan 5xx.
- Pemahaman tentang bagaimana transformasi memengaruhi cache, ETag, tanda tangan, dan permintaan berikutnya.
- Tautan audit yang dapat dilacak antara representasi origin dan downstream.
- Penanganan multi-proxy, kegagalan origin, dan klien yang tidak memahami 203.
- Mengubah semantik protokol menjadi header dan perilaku cache yang dapat diuji.
Klarifikasi sebelum menjawab
- Apakah perubahannya berupa pemfilteran malware, transcoding, atau redaksi khusus pengguna? Ini memengaruhi pembagian cache.
- Bisakah klien mengenali 203? Jika tidak, apakah lapisan kompatibilitas diperlukan?
- Haruskah representasi asli dapat dilacak? Tanda tangan dan catatan audit memerlukan kedua versi tersebut.
- Apakah transformasinya deterministik? Jika aturan bervariasi, versi aturan harus dimasukkan ke dalam kunci cache.
Kerangka jawaban 30 detik
Pertama, saya memverifikasi apakah gateway mengubah konten aplikasi atau header yang relevan. Respons origin yang berhasil dengan representasi yang diubah akan mendapatkan 203; representasi yang tidak tersentuh tetap 200. 203 tidak menggantikan 304, yang hanya memvalidasi representasi klien yang ada. Saya membuat ETag untuk representasi downstream dan menyertakan negosiasi konten, versi aturan, dan batasan tenant dalam kunci cache. Catatan audit menautkan versi origin ke output yang ditransformasi. Kegagalan origin tetap mempertahankan semantik kegagalan yang sebenarnya.
Jawaban mendalam langkah demi langkah
1. Menetapkan batasan kode status
200 menyatakan respons saat ini berhasil tanpa mendeklarasikan transformasi aplikasi. 203 menyatakan permintaan berhasil tetapi proxy transformatif mengubah header atau konten dari respons 200 origin. 304 tidak membawa representasi baru dan meminta klien untuk menggunakan kembali representasi yang telah divalidasi. Kegagalan pemfilteran, penolakan, dan timeout origin menggunakan semantik 4xx atau 5xx yang sesuai.
2. Mengklasifikasikan transformasi
Mengganti URL yang diblokir karena malware, pemfilteran privasi, transcoding format, dan metadata cermin dapat membenarkan 203. Hanya mengubah kompresi transfer atau kolom hop-by-hop biasanya tidak mengubah representasi aplikasi. Gateway harus mencatat apa yang diubah dan alasannya.
3. Menghitung ulang validator
ETag origin mendeskripsikan representasi origin. Output yang ditransformasi memerlukan ETag downstream yang valid untuk output tersebut. Jika versi aturan mengubah byte, sertakan versi tersebut dalam kunci cache atau input validator; jika tidak, peluncuran aturan baru dapat menggunakan kembali output yang usang.
4. Merancang caching dan negosiasi
Vary, pengodean konten, bahasa, tenant, dan aturan transformasi semuanya memengaruhi keterbagian cache. Tetapkan default untuk hasil yang sensitif terhadap privasi ke caching privat; bagikan hanya transformasi publik yang deterministik. Untuk If-None-Match, validasi representasi gateway daripada meneruskan 304 origin untuk byte yang tidak dimiliki klien.
5. Melindungi tanda tangan dan jejak audit
Tanda tangan origin atas byte asli tidak dapat membuktikan isi body downstream yang dimodifikasi. Tandatangani ulang representasi yang ditransformasi atau hapus tanda tangan yang tidak valid. Catat ID permintaan origin, ETag origin, versi aturan, ETag output, dan alasan transformasi.
6. Menangani banyak proxy
Setiap lapisan harus mempertahankan asal-usul transformasi dan menghindari pengulangan aturan non-idempoten. Jika klien tidak dapat memahami 203, lapisan kompatibilitas eksplisit dapat mengembalikan 200 dengan metadata yang terdokumentasi, tetapi tidak boleh menyembunyikan transformasi keamanan atau privasi secara diam-diam.
7. Memverifikasi dan melakukan rollback
Uji respons origin 200, 203 yang ditransformasi, 200 yang tidak tersentuh, downstream 304, peluncuran aturan, timeout origin, dan kegagalan filter. Selama rollback, pastikan ETag lama dan baru tidak dapat bertabrakan dan periksa entri cache bersama yang dibuat di bawah aturan lama.
Contoh jawaban berkualitas tinggi
Saya memperlakukan 203 sebagai deklarasi "permintaan berhasil, tetapi proxy transformatif mengubah representasi origin." Respons aplikasi yang tidak tersentuh tetap 200; respons yang ditransformasi adalah 203; 304 hanya memvalidasi representasi downstream dan tidak dapat diteruskan begitu saja secara membabi buta dari origin. Gateway membuat ETag baru untuk byte yang ditransformasi dan menentukan kunci cache berdasarkan versi aturan, negosiasi, dan batasan privasi. Jika tanda tangan origin mencakup byte asli, gateway menandatangani ulang atau menghapusnya. Pengujian mencakup 200/203/304, perubahan aturan, rantai proxy, dan kegagalan origin sehingga klien tidak pernah mengira data yang difilter sebagai data origin.
Kesalahan umum
- Mengembalikan 203 untuk setiap respons proxy → semantik menjadi bising → gunakan hanya untuk perubahan representasi yang nyata.
- Menggunakan kembali ETag origin → validator mendeskripsikan byte yang salah → buat satu untuk output downstream.
- Memperlakukan 203 sebagai error → klien dapat mencoba lagi atau memicu peringatan → pertahankan semantik kegagalan 4xx/5xx yang sebenarnya.
- Meneruskan 304 origin secara membabi buta → cache yang ditransformasi mungkin tidak valid → validasi representasi downstream.
- Mengabaikan versi aturan → peluncuran aturan dapat menyajikan output lama → sertakan versi dalam kunci atau validator.
Pertanyaan lanjutan dan tanggapan
Apakah hanya mengubah Content-Encoding memerlukan 203?
Biasanya tidak. Transfer encoding adalah penanganan transport; jika representasi aplikasi tidak berubah, pertahankan 200 dan terapkan aturan negosiasi normal.
Bisakah respons 203 dibagikan oleh cache?
Ya, jika transformasinya deterministik, setiap dimensi yang bervariasi diberi kunci, dan tidak ada data privat pengguna yang ada. Output khusus tenant harus bersifat privat.
Bagaimana jika respons origin 203 ditransformasi lagi oleh gateway?
Pertahankan kedua tautan asal-usul, hitung ETag akhir, dan verifikasi idempotensi. Jika idempotensi tidak dijamin, izinkan hanya satu transformasi.
Bisakah lapisan kompatibilitas mengubah 203 menjadi 200?
Bisa jika didokumentasikan secara eksplisit, dengan metadata yang dapat dideteksi dan pencatatan log audit. Lapisan ini tidak boleh menyembunyikan pemfilteran keamanan atau redaksi privasi secara diam-diam.
Bagaimana jika origin mengembalikan 304 tetapi tidak ada objek yang ditransformasi secara lokal?
Jangan mengembalikan 304 secara langsung. Ambil representasi yang dapat digunakan dan transformasikan, atau kembalikan kegagalan yang mencerminkan hilangnya representasi lokal.