You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Når en klient (feks websidene) henter en session, får den med en "lastUpdatedDate" eller lignende, som i praksis er eventDate fra siste relaterte event.
Når web-clienten skal poste en oppdatert session, så må den sende med en If-Unmodified-Since http-header med datoen den fikk i steg 1
Web-serveren sjekker at If-Unmodified-Since er lik lastUpdated og excepter med en 4xx-exception hvis ikke.
Anders var ikke enig i å bruke datoer. En modifisert versjon bruker etag. Da må vi ha en etag for en gitt session. Det kan være id'en til siste event (kanskje litt vel brutalt), eller id'en til siste event som er relevant for en gitt session. Da må denne id'en oppdaters når en Session oppdateres, men det er jo ikke noe problem. Da blir det slik:
Sørge for at Session-oppdatereren tar vare på id til siste event som oppdaterte denne Session
Server sender med en http-header ETag: W/"123", der 123 er relevant event-id
Når en klient ønsker å oppdatere en event sender den med http-header If-Match: "123".
Når server tar i mot en update-request, sjekker den If-Match-headeren og dersom den ikke stemmer (lengre) så excepter den med HTTP-kode 412.
For å unngå at noen overskriver feks en session med gamle data, trenger vi en form for optimistic locking.
Jeg tenker det er greit å følge http-specen og bruke If-Match, men det er andre måter å løse dette på.
The text was updated successfully, but these errors were encountered: