ResponseCache

Ahogy már a bevezető cikkben is mondtuk, minden modern böngésző már beépített gyorsítótárazási funkcionalitással bír. Igyekeznek a statikus dolgokat felismerni, például képeket és stíluslapokat, amiket gyorsítótárba raknak a következő kéréshez. A tényleges oldalra ez viszont nem vonatkozik, mivel a böngésző nem tudja, hogy a szerver pontosan ugyanazt a választ adja-e a következő kérésre, vagy sem. Ez nem azt jelenti, hogy lehetetlen az oldalt gyorsítótárazni, viszont segítened kell benne a böngészőnek. Erre a célra szolgál ASP.NET MVC-ben a ResponseCache nevű technika.

A ResponseCache, amit HTTP alapú válasz-gyorsítótárazásnak is hívnak, leggyakrabban közvetlen egy vezérlőakcióra kerül, ezzel tudja a böngésző, hogy biztonságosan gyorsítótárazhatja a kapott választ egy bizonyos időre. Ha tehát a vezérlőakciód eredménye mindig statikus, vagy legalábbis valamennyi előrelátható ideig ugyanaz marad, akkor megengedheted a böngészőnek a gyorsítótárazást:

public class CacheController : Controller  
{  
    [ResponseCache(Duration = 120)]      
    public IActionResult Index()  
    {          
    return View();  
    }  
}

Ezzel a kérést adó böngésző engedélyt kap a választ gyorsítótárazására két percig (120 másodpercig). Ezt látni lehet a válaszfejlécben is, amit a böngésződben található fejlesztői eszközökkel magad is ellenőrizhetsz (pl. DevTools a Google Chrome-ban). Itt egy ehhez hasonló válaszfejlécet láthatsz:

Cache-Control: public,max-age=120

Egy fontos dologot azonban érdemes megjegyezni: ez csak egy javaslat a böngésző részére. A böngésző bármikor figyelmen kívül hagyhatja ezt a javaslatot, és újra lekérheti az oldalt. Ez például valószínűleg meg fog történni, amikor a felhasználó frissíti az oldalt, ahelyett, hogy link segítségével érkezne az oldalra.

Vary-lehetőségek

A fenti példában az oldal minden esetben gyorsítótárazva lesz, de sok esetben az oldalad változhat annak függvényében, hogy a felhasználó hogyan jut az oldalra. Például ha a query stringben lévő paramétereket különböző tartalom megjelenítésére használod, mondjuk így:

/Users/Details?id=1
/Users/Details?id=2
....

Ilyen esetben nem szeretnéd, ha az 1-es számú felhasználó adatai gyorsítótárazva lennének, és a 2-es számú felhasználó oldalán ugyanez jelenne meg. Szerencsére a ResponseCache direktíva különböző beállítási lehetőségeket tartalmaz a query stringen alapuló tartalomváltozásokra, de ez úgynevezett ResponseCache middleware-t igényel. Más szavakkal ezt a NuGet csomagot kell telepítened a projektbe, majd a Startup.cs fájlban referenciát tenni rá mindössze pár sornyi kóddal:

    public class Startup
    {
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddResponseCaching();        
        services.AddMvc();        
    }
    
    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        if (env.IsDevelopment())
        {
        app.UseDeveloperExceptionPage();
        }
        app.UseResponseCaching();        
        app.UseMvcWithDefaultRoute();
    }
    }

A releváns sorok a services.AddResponseCaching() és a app.UseResponseCaching(). Ezekkel már használhatod a VaryByQueryKeys paramétert:

[ResponseCache(Duration = 120, VaryByQueryKeys = new[] { "id" })]      
public IActionResult Details(int id)  
{          
...

Így a kért oldal csak akkor lesz gyorsítótárból előhívva, ha az id paraméter értéke egyezik. Több paramétert is megadhatsz a megkülönböztetés alapjaként, vagy egy csillaggal jelölheted, ha azt szeretnéd, hogy minden paraméter meg legyen különböztetve:

[ResponseCache(Duration = 120, VaryByQueryKeys = new[] { "*" })]        

VaryByHeader

A kliens által a szervernek küldött fejlécek alapján is megkülönböztetést tehetsz, pl. a "User-Agent" szerint, ami azonosítja a klienst (egy böngészőt). Ezt így használhatod:

[ResponseCache(Duration = 120, VaryByHeader = "User-Agent" )]

Összefoglaló

A ResponseCache direktíva segítségével irányt szabhatsz a kliensnek, hogy mikor gyorsítótárazhatja a kapott oldalakat. Tartsd viszont észben, hogy ez pusztán javaslat a kliens részére, a megspórolt erőforrások és sávszélesség nem lesz akkora, mintha a gyorsítótárazás a teljes irányításod alatt lenne. Erről a következő cikkben beszélünk alaposabban.