Proxy reverse-mana yang mendukung header HTTP / 1.1 ETag dan If-None-Match?

Saya sedang mengembangkan sistem caching untuk platform e-niaga yang akan menggunakan proxy terbalik untuk caching. Saya berencana untuk menangani pembatalan dengan menggunakan tajuk HTTP / 1.1 yang tepat. Artinya, saya akan mengatur ETag pada generasi pertama konten dan cache nilai ETag dalam aplikasi. Header Cache-Control akan menentukan "harus-divalidasi ulang" sehingga proxy harus menetapkan header If-None-Match pada permintaan berikutnya dengan ETag. Aplikasi akan mencari nilai ETag yang di-cache dan jika cocok, akan mengirimkan respons 304, jika tidak maka akan menghasilkan respons 200 penuh.

Saya berharap untuk menggunakan nginx tapi saya tidak bisa memastikan bahwa itu mendukung ETags (dokumen menunjukkan itu tidak tetapi mungkin mereka ketinggalan zaman?). Varnish adalah pilihan lain, tetapi saya juga tidak positif di sini ..

Server proxy terbalik mana di luar sana yang memiliki dukungan penuh untuk ETag? Saya ingin benar-benar cache beberapa versi sehingga saya dapat melakukan hal-hal seperti pengujian split tanpa harus menonaktifkan cache. Artinya, HTTP / 1.1 menetapkan bahwa klien dapat mengirim If-None-Match dengan beberapa nilai ETag dan server harus merespons dengan ETag yang cocok (jika ada). Jika proxy terbalik menyimpan banyak salinan daripada hanya nilai yang terakhir dilihat dan membiarkan server menentukan pada setiap permintaan yang akan digunakan, itu akan ideal.

Saya baru saja memeriksa kode sumber Varnish dan meskipun itu mendukung If-Modified-Sincedan If-None-Matchheader, itu tidak mendukung must-revalidatedi Cache-Control. Satu-satunya atribut yang didukung Cache-Controladalah max-agedan s-max-age.

Referensi:

• bin/varnishd/cache/cache_rfc2616.cdalam RFC2616_Do_Cond ()
• bin/varnishd/cache/cache_rfc2616.cdalam RFC2616_Ttl ()
• include/tbl/http_headers.h

nginx membutuhkan modul pihak ketiga untuk mendukung ETag. Dan mereka ada dua .

• ETag statis untuk caching konten statis
• ETag dinamis untuk caching konten dinamis

Perbaiki saya jika saya salah, dan saya tahu ini adalah posting lama - tetapi saya ingin berkomentar untuk orang yang baru lewat. Saya percaya cache Proksi Terbalik tidak membantu sebanyak yang Anda inginkan saat menggunakan ETag.

Mekanisme caching validasi menggunakan server asal untuk memvalidasi jika ETag (atau tanggal modifikasi terakhir) dalam permintaan masih valid (cocok atau tidak cocok dengan etag sumber daya, tergantung pada header mana yang digunakan, atau telah / belum dimodifikasi) sejak tanggal yang diberikan dalam permintaan).

Ini berarti cache proksi terbalik seperti Varnish masih akan meneruskan permintaan itu ke server asal. Mungkin merespons dengan permintaan daripada meminta server untuk menanganinya, tetapi Anda tidak menyimpan pulang pergi ke server asal.

Peramban dapat men-cache respons dan menangani respons 304 dalam hal apa pun, sehingga cache pribadi pengguna mungkin lebih cocok untuk menangani ini daripada menggunakan proxy terbalik (YMMV, terutama pada skala, dan tergantung pada kasus penggunaan Anda tentu saja. Saya tidak ingin membuat asumsi tentang aplikasi Anda).

Dari spec 13.3 :

Ketika cache memiliki entri basi yang ingin digunakan sebagai respons terhadap permintaan klien, pertama-tama harus memeriksa dengan server asal (atau mungkin cache menengah dengan respons baru) untuk melihat apakah entri yang di-cache masih dapat digunakan . Kami menyebutnya "memvalidasi" entri cache. Karena kami tidak ingin harus membayar overhead untuk mengirim kembali respons penuh jika entri yang di-cache baik, dan kami tidak ingin membayar overhead dari perjalanan pulang-pergi tambahan jika entri yang di-cache tidak valid, protokol HTTP / 1.1 mendukung penggunaan metode kondisional.

dan kemudian catat 13.3.4 :

Proxy cache HTTP / 1.1, setelah menerima permintaan bersyarat yang mencakup tanggal yang Terakhir Dimodifikasi dan satu atau lebih tag entitas sebagai validator cache, TIDAK HARUS mengembalikan respons yang di-cache secara lokal ke klien kecuali jika respons yang di-cache konsisten dengan semua bidang header kondisional dalam permintaan.

Jadi, Varnish dapat mengembalikan respons untuk Anda, tetapi Anda masih harus bolak-balik ke server. Jika Anda dapat menggunakan aplikasi-cache seperti APC atau memcache, maka itu mungkin masih layak untuk Anda. Caching validasi umumnya lebih baik untuk penghematan bandwidth daripada penghematan sumber daya server.

Caching validasi sebaiknya diserahkan kepada klien (browser atau kode api).

Menggunakan model Kadaluarsa untuk caching adalah tempat cache reverse-proxy benar-benar bersinar. Ini memungkinkan Anda melewati memukul server asal sama sekali. Menggunakan Expires, Cache-Control, Date, dll, adalah yang terbaik (sekali lagi, IMO) mekanisme untuk cache reverse proxy sebagai cache dapat kembali respon, dengan asumsi yang tidak basi, tanpa pernah memukul server asal.

Anda dapat melihat Apache TrafficServer , yang tampaknya memiliki apa yang Anda butuhkan .

Sampai saat ini saya yakin masih belum ada proxy yang sepenuhnya mendukung spesifikasi HTTP ini. Jadi, sekitar setahun yang lalu saya memutuskan untuk menulis sendiri menggunakan Node.js dan MongoDb.

https://github.com/colinmollenhour/node-caching-proxy