Quali proxy inversi supportano le intestazioni HTTP / 1.1 ETag e If-None-Match?


8

Sto sviluppando un sistema di memorizzazione nella cache per una piattaforma di e-commerce che utilizzerà un proxy inverso per la memorizzazione nella cache. Ho intenzione di gestire l'invalidazione utilizzando le intestazioni HTTP / 1.1 appropriate. Cioè, imposterò un ETag sulla prima generazione del contenuto e memorizzerò nella cache quel valore ETag nell'applicazione. L'intestazione Cache-Control specificherà "must-revalidate", quindi il proxy dovrebbe impostare l'intestazione If-None-Match sulle richieste successive con ETag. L'applicazione cercherà il valore ETag memorizzato nella cache e se corrisponde invierà una risposta 304, altrimenti genererà una risposta completa 200.

Speravo di usare nginx ma non posso dire con certezza che supporta ETags (i documenti indicano che non lo fa, ma forse non sono aggiornati?). La vernice è un'altra opzione, ma non sono positivo neanche qui.

Quali server proxy inverso là fuori hanno pieno supporto per ETag? Vorrei che in realtà cache più versioni in modo da poter fare cose come split test senza dover disabilitare la cache. Cioè, HTTP / 1.1 specifica che un client può inviare If-None-Match con più valori ETag e il server deve rispondere a quale ETag corrisponde (se presente). Se il proxy inverso conservasse più copie anziché solo il valore visualizzato per ultimo e consentisse al server di specificare su ogni richiesta quale utilizzare, sarebbe l'ideale.

Risposte:


2

Ho appena controllato nel codice sorgente per unghie e anche se il supporto If-Modified-Sincee If-None-Matchle intestazioni, non supporta must-revalidatein Cache-Control. Gli unici attributi supportati in Cache-Controlsono max-agee s-max-age.

Riferimenti:


Grazie. Non so molto su Varnish VCL, ma è possibile specificare l'utilizzo di VCL per riconvalidare sempre dato che Varnish sembra supportare la riconvalida?
ColinM,

Ho appena scoperto che il ramo "sperimentale-ims" di Varnish sembra aggiungere il supporto completo per If-None-Match. Speriamo che alla fine verrà unito in una versione stabile. varnish-cache.org/trac/wiki/BackendConditionalRequests
ColinM

2

nginx richiede moduli di terze parti per supportare ETag. E ce ne sono due .

  • ETags statici per la memorizzazione nella cache di contenuto statico
  • ETag dinamici per la memorizzazione nella cache di contenuti dinamici

Il modulo etags statico serve per generare etags, non memorizzare nella cache contenuti con etags. Allo stesso modo, il modulo etags dinamici genera etags per contenuti dinamici per l'uso a monte, non per uso proxy inverso. Tuttavia, penso che nginx 1.3 abbia aggiunto il supporto ufficiale per etags con proxy inversi.
ColinM,

1
Solo per riferimento futuro, nginx supporta ETag e If-None-Match a partire dall'1.7.3, ma può comunque memorizzare nella cache solo un risultato per un determinato URL, quindi non chiamerei questo supporto completo. Cioè, non è possibile avere più risposte memorizzate nella cache e negoziate con il server durante la riconvalida. Vedi trac.nginx.org/nginx/ticket/101
ColinM il

1

Correggimi se sbaglio, e so che questo è un vecchio post, ma vorrei commentare per i nuovi passanti. Credo che una cache del proxy inverso non sia di aiuto quanto si desidera quando si utilizzano ETag.

I meccanismi di memorizzazione nella cache di convalida utilizzano il server di origine per convalidare se l'ETag (o la data dell'ultima modifica) nella richiesta è ancora valida (corrisponde o non corrisponde all'etag delle risorse, a seconda dell'intestazione utilizzata o se è / non è stata modificata dalla data indicata nella richiesta).

Ciò significa che una cache proxy inversa come Varnish passerà comunque tale richiesta al server di origine. Potrebbe rispondere con la richiesta anziché far gestire il server, ma non è stato salvato il round trip sul server di origine.

I browser possono memorizzare nella cache le risposte e gestire una risposta 304 in ogni caso, quindi la cache privata dell'utente potrebbe essere più adatta a gestirla rispetto all'utilizzo di un proxy inverso (YMMV, specialmente su larga scala e ovviamente in base al caso d'uso. vuoi fare ipotesi sulle tue app).

Dalla specifica 13.3 :

Quando una cache ha una voce non aggiornata che desidera utilizzare come risposta alla richiesta di un client, deve prima verificare con il server di origine (o possibilmente una cache intermedia con una nuova risposta) per vedere se la sua voce memorizzata nella cache è ancora utilizzabile . Chiamiamo questo "convalida" la voce cache. Poiché non vogliamo pagare l'overhead della ritrasmissione della risposta completa se la voce memorizzata nella cache è buona e non vogliamo pagare l'overhead di un round trip aggiuntivo se la voce memorizzata nella cache non è valida, il protocollo HTTP / 1.1 supporta l'uso di metodi condizionali.

e quindi nota 13.3.4 :

Un proxy di cache HTTP / 1.1, dopo aver ricevuto una richiesta condizionale che include sia una data ultima modifica sia uno o più tag entità come validatori di cache, NON DEVE restituire una risposta memorizzata nella cache locale al client a meno che tale risposta memorizzata nella cache non sia coerente con tutte le campi di intestazione condizionale nella richiesta.

Quindi, Varnish può restituirti una risposta, ma hai ancora un round-trip sul server. Se puoi usare una cache di app come APC o memcache, allora potrebbe valerne la pena. La memorizzazione nella cache di convalida è generalmente migliore per i risparmi della larghezza di banda rispetto ai risparmi delle risorse del server.

La memorizzazione nella cache di convalida potrebbe essere lasciata al client (browser o codice api).

L'uso del modello di scadenza per la memorizzazione nella cache è il punto in cui una cache proxy inversa brilla davvero. Ciò ti consente di saltare a colpire del tutto il server di origine. Usando Expires, Cache-Control, Date, ecc, è la migliore (di nuovo, IMO) Meccanismo per una cache proxy inverso come cache può restituire la risposta, assumendo la sua non stantio, senza mai colpire il server di origine.


Il caso d'uso che avevo in mente per questa domanda è di riconvalidare il proxy con il server di origine e il server di origine restituisce 304 se l'ETag corrisponde all'ETag che verrebbe memorizzato nella cache per un determinato record. Cioè, l'ETag verrebbe generato casualmente quando la pagina viene visualizzata per la prima volta e salvata con la chiave primaria per quel record. Se il record viene modificato, ETag viene cancellato.
ColinM,


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.