2014-09-08 14 views
5

La mia applicazione utilizza ASP.NET MVC 5 con OutputCache (in dettaglio, usiamo MVCDonutCaching) per memorizzare nella cache siti ad alto traffico e percorsi costosi.ASP.NET MVC OutputCache non memorizza intestazioni personalizzate

Alcune azioni dispongono di un filtro di azione personalizzato che aggiunge un'intestazione Content-Range in base al modello di visualizzazione. Senza il caching funziona come un incantesimo. Quando la cache è abilitata, il primo hit è ok (l'intestazione Content-Range è presente nella risposta) - ma la seconda contiene solo Content-Type e la risposta HTML/JSON e manca l'intestazione personalizzata Content-Range (che interrompe la funzionalità del client).

C'è un modo per abilitare il corretto caching dell'intestazione senza scrivere una propria implementazione di OutputCache?

Grazie mille.

+0

E 'anche facendo richiesta o utilizzando la richiesta memorizzata localmente, a cosa serve il set OutputCache? – Lloyd

+0

La richiesta viene inviata al server e risponde da essa. La richiesta passa attraverso il routing e si ferma sul ActionFilter 'DonutOutputCache' che serve una copia del contenuto Http originale, set del tipo di contenuto e alcune intestazioni della cache. –

+0

L'annotazione del filtro di azione dell'intestazione personalizzata prima o dopo l'annotazione della cache di output? – Carl

risposta

1

La risposta memorizzata nella cache è una risposta HTTP "304 - Non modificata" e non è previsto che questo tipo di risposta restituisca intestazioni di entità (tranne alcune eccezioni come "Ultima modifica").

Il "Content-Range" intestazione si sta cercando di tornare è un colpo di testa di entità:

http://www.freesoft.org/CIE/RFC/2068/178.htm

Ecco una lista completa delle intestazioni di entità:

https://tools.ietf.org/html/rfc2616#section-7.1

La ragione perché 304 non restituisce intestazioni di entità è che la risposta 304 non dovrebbe restituire una rappresentazione completa della risorsa di destinazione, poiché nulla è cambiato.

The (Not Modified) codice di stato 304 indica che un condizionale GET o HEAD richiesta è stata ricevuta e avrebbe comportato una risposta 200 (OK) se non fosse per il fatto che la condizione ha valutato a falso. In altre parole, non è necessario che il server trasferisca una rappresentazione della risorsa di destinazione poiché la richiesta indica che il client, che ha effettuato la richiesta condizionale, ha già una rappresentazione valida;

Ciò significa che le intestazioni di entità non devono essere trasferite di nuovo. Questo assicura coerenza e ha anche alcuni vantaggi in termini di prestazioni.

Se il GET condizionale ha utilizzato un valido validatore di cache (vedere la sezione 13.3.3), la risposta NON DEVE includere altre intestazioni di entità. Altrimenti (vale a dire, il GET condizionale ha utilizzato un validatore debole), la risposta NON DEVE includere altre intestazioni di entità; ciò evita incoerenze tra entità-entità memorizzate nella cache e intestazioni aggiornate.

https://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-23#section-4.1

mia conclusione è che ASP.NET e IIS interpretano questa specifica correttamente, e ciò che si sta cercando di fare non è supportata. A dimostrazione del fatto che Apache e altri server web famosi fanno lo stesso come spiegato sopra.

Se è ancora necessaria l'intestazione nel 304, sarà necessario identificare e sostituire (se possibile) i componenti responsabili del filtraggio delle 304 risposte.

Problemi correlati