A URI és HTTP szabványok érdekességei - a vary header

A Representational State Transfer - interface constraints és ajánlott szabványok bejegyzésben elég részletesen kitárgyaltam az URI standard egy érdekességét, hogy hogyan lehet valós életbeli dolgokat azonosítani egy-egy fragment identifier-es IRI használatával. Ebben a bejegyzés sorozatban szeretném egy kicsit jobban kibontani a URI és HTTP szabványokat, mert nagyon sokan, akik webre fejlesztenek, nem ismerik kellőképp ezeket a szabványokat. Ami egyrészt szomorú, másrészt meg én is közéjük sorolom magam, és megnőtt bennem az igény a változásra.

A mostani bejegyzés a vary header-ről fog szólni, illetve arról, hogy hogyan lehet felhasználni felhasználóra, böngésző típusra, MIME típusra, nyelvre és tömörítési formára specifikus tartalmak kesselésére. Természetesen a gyakorlati felhasználása még ennél is jóval szélesebb körű ennek a header-nek.
A vary HTTP header-el úgy kerültem közelebbi kapcsolatba, hogy megpróbáltam utána járni, hogy vajon kesselésnél mi alapján történik egy-egy HTTP request azonosítása és összehasonlítása a cache-ben lévő tartalommal.

Ugye itt nagyon leegyszerűsítve mondhatjuk azt, hogy a cache egy key-value storage, így amikor bejön egy-egy HTTP request, akkor az alapján kikeresi, hogy van e olyan kulcs, ami megfelel neki. Ha talál ilyet, akkor a hozzá tartozó érték lesz a HTTP response, amit visszaad, ha nem talál ilyet, akkor meg megkéri a szervert, hogy ugyanmár, gyártson neki egyet. Így pl. a böngészőnek nem is kell meglátogatnia a szervert, ha benne van a keresett tartalom a cache-ben.

Ami számomra evidens volt, hogy a HTTP method és az URI, amit biztosan felhasznál a cache egy-egy kulcs kikeresésére és tárolására. Ami menet közben kiderült, hogyha több kulcsot is talál egy kéréshez, akkor mindig a legfrissebbhez tartozó értéket küldi el a válaszban. Ami viszont nem volt világos, hogy a fent említett két paraméteren kívül még mi az, amit felhasznál kulcs generálásnál a cache. Ami már tapasztalati úton megvolt, hogy az accept header ezek közé a dolgok közé tartozik, különben ha JSON-t kér a kliens, és HTML-t szolgál ki a szerver, abból elég nagy bonyodalmak lehetnek. Ezen kívül az authorization header, ami rémlett, hogy beleszól a kesselésbe. Kis utánajárás után kiderült róla, hogyha nem engedélyezzük kimondottan a kesselést, akkor authorization header megléte esetén ki lesz kapcsolva. Ha egy-egy felhasználónak szánt tartalmat akarunk kesselni, akkor úgy tűnt reménytelen a helyzet ezek alapján, és a private vagy no-cache beállításokat kell használnunk, és minden kérést a szerverrel kell feldolgoztatnunk. Mint kiderült a valóság korántsem ennyire rideg, csak el kell olvasni a szabványt, vagy máshogy fogalmazva RTFM! :-)

Természetesen átlag fejlesztőként én sem olvastam el a teljes HTTP szabványt, és annak minden kiegészítését, mert bár hasznos olvasmány, de belezöldül az ember mire átrágja magát rajta, annyira hosszú, és száraz. Azért megismerkedtem már néhány dologgal, aminek gyakorlati haszna van, ezek majd később szerepelni is fognak. A cache-el kapcslatban nyomoznom kellett egy kicsit, mire megtaláltam a számomra fontos részeket.

4.  Constructing Responses from Caches

   When presented with a request, a cache MUST NOT reuse a stored
   response, unless:
   o  The presented effective request URI (Section 5.5 of [RFC7230]) and
      that of the stored response match, and
   o  the request method associated with the stored response allows it
      to be used for the presented request, and
   o  selecting header fields nominated by the stored response (if any)
      match those presented (see Section 4.1), and
  - 1. idézet - https://tools.ietf.org/html/rfc7234#page-8

 Ezek alapján az URI és a method használata elég nyilvánvaló. Ami érdekes az a harmadik pont, ami a header-ekre vonatkozik. Ehhez tovább kell lapozni a 4.1-es fejezethez.

4.1.  Calculating Secondary Keys with Vary

   When a cache receives a request that can be satisfied by a stored
   response that has a Vary header field (Section 7.1.4 of [RFC7231]),
   it MUST NOT use that response unless all of the selecting header
   fields nominated by the Vary header field match in both the original
   request (i.e., that associated with the stored response), and the
   presented request.
 - 2. idézet - https://tools.ietf.org/html/rfc7234#section-4.1

Ezek alapján a vary header-el lehet hozzáadni header-eket a kulcs ellenőrzéshez. Csak akkor szolgálja ki a cache-ből a kérést, ha az összes hozzáadott header stimmel. Bontsuk ki még jobban a dolgot.

   The "Vary" header field in a response describes what parts of a
   request message, aside from the method, Host header field, and
   request target, might influence the origin server's process for
   selecting and representing this response.  The value consists of
   either a single asterisk ("*") or a list of header field names
   (case-insensitive).
 - 3. idézet - https://tools.ietf.org/html/rfc7231#section-7.1.4

A vary-nak meg lehet adni szép sorban vesszővel elválasztva a header-eket nem case-sensitive módon:
vary: accept, accept-encoding
Vary: Cookie
vary: Accept-Language
 - 1. példakód - A vary header megadása

Ezen kívül meg lehet adni *-ot is értéknek. Ez a dokumentáció alapján minden kérést továbbít a szervernek.

Tehát feltevésem, hogy az accept- és authorization header-ek alapból beleszámítanak a cache kulcs generálásba, valójában téves volt. Muszáj egyenként hozzáadni őket, ha kesselhetővé szeretnénk tenni
  •  az eltérő MIME típusú tartalmakat az accept header-el
  •  a felhasználó specifikus tartalmakat az authorization header-el, vagy a session cookie-val
  •  a böngészőnkénti eltérő tartalmakat proxy-n keresztül az user-agent header-el
  •  az eltérő nyelvű tartalmakat az accept-language header-el
  •  az eltérő tömörítésű tartalmakat az accept-encoding header-el
Összességében tehát a vary header egy elég hasznos header a HTTP szabványban, szóval mindenképp érdemes megismerkedni vele, és használni, ahol szükség van rá. Ha ennyi nem lett volna elég a vary header-ről, akkor találtam még egy hasznos cikket további példákkal, amit érdemes átolvasni.

Nincsenek megjegyzések:

Megjegyzés küldése