WEB / WEB-12.04

Client ve server state sahipliği

Bir not Browser’da görünür, server’da kaydedilmiş olabilir veya henüz sırada bekleyebilir. State sahipliği, hangi kopyanın hangi kararı verebildiğini belirler.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Hareket olmadan bütün senaryoları oku

Base version matches

Taslak henüz gönderilmedi
Browser v3 snapshot’ından yeni not üretir; server record hâlâ v3.
Browser / Duru
Base: v3; draft unsaved
Application
Request yok
Authoritative record
Current: v3
Update request ulaştı
Application yeni metin ve If-Match v3 alır. Receiver arrival request’in kabul edildiğini henüz söylemez.
Browser / Duru
Base: v3; waiting
Application
Received: If-Match v3; checks pending
Authoritative record
Current: v3
Trusted kontroller geçer
Supplied authenticated context, authorization ve input valid kabul edilir. Mutation henüz yok.
Browser / Duru
Base: v3; waiting
Application
Trusted checks passed; conditional commit pending
Authoritative record
Current: v3
Koşullu local commit
Current v3 eşleşir; check ve write aynı boundary’de v4 üretir. Mantıksal in-process işlem, wire yok.
Browser / Duru
Base: v3; waiting
Application
Committed result: v4
Authoritative record
Current: v4
Başarılı response ulaştı
Browser yeni version’ı öğrenir ve yalnız şimdi server save durumunu gösterir.
Browser / Duru
Known: v4; saved on server
Application
Response: 200, ETag v4
Authoritative record
Current: v4

Stale precondition

Browser eski snapshot kullanır
Yeni taslak v2 üzerine kurulmuştur; trusted record v3’tür.
Browser / Duru
Base: v2; draft unsaved
Application
Request yok
Authoritative record
Current: v3
Eski validator ulaştı
Application If-Match v2 alır; bu alan authorization kanıtı değildir.
Browser / Duru
Base: v2; waiting
Application
Received: If-Match v2; checks pending
Authoritative record
Current: v3
Precondition false
Trusted kontroller valid olsa da v2/v3 eşleşmez. Fixture mutation uygulamaz.
Browser / Duru
Base: v2; waiting
Application
Rejected: precondition false
Authoritative record
Current: v3; unchanged
Conflict response ulaştı
412 Browser’a ulaşır. Taslak korunur; server record değişmedi.
Browser / Duru
Conflict; draft preserved
Application
Response: 412
Authoritative record
Current: v3; unchanged
Reconcile gerekir
UI güncel record’u okumayı ve taslağı karşılaştırmayı önerir; zorla overwrite etmez.
Browser / Duru
Conflict; current record needed
Application
Response: 412
Authoritative record
Current: v3; unchanged

Commit · response lost

Snapshot ve taslak
Browser v3 snapshot’ını ve henüz kaydedilmemiş taslağı tutar. Request gönderilmedi; server’ın authoritative kaydı hâlâ v3’tür.
Browser / Duru
Base: v3; draft unsaved
Application
Request yok
Authoritative record
Current: v3
Request Application’a ulaştı
Update request geldi; Browser sonucu bekler.
Browser / Duru
Base: v3; waiting
Application
Received: If-Match v3
Authoritative record
Current: v3
Trusted conditional commit
Supplied trusted kontroller ve v3 precondition geçer; record v4 olur. Local işlem.
Browser / Duru
Base: v3; waiting
Application
Committed: v4; response prepared
Authoritative record
Current: v4
Response ulaşmadı
Bu authored branch’te bağlantı commit sonrası kopar. Completed arrival olmadığı için Browser’a transfer çizilmez.
Browser / Duru
Known: v3; no response
Application
Response delivery failed after commit
Authoritative record
Current: v4
Client outcome unknown
Browser taslağı korur; yeniden gözlemleme gerekir. Server v4 olması fixture’ın bildiği, Browser’ın henüz bilmediği sonuçtur.
Browser / Duru
Outcome unknown; draft preserved
Application
Response delivery failed after commit
Authoritative record
Current: v4

ROLLER · STATE · VERİ AKIŞI

Bir notun birden fazla doğru durumu vardır

Duru Atlas’ta kitabına bir not yazıyor. Browser input’unda “yeni not” görünmesi, server’daki record’un da değiştiğini göstermez. İlk kopyanın owner’ı UI; kalıcı business record’un owner’ı uygulamanın trusted server tarafıdır.

Client state yalnız geçici olmak zorunda değildir; IndexedDB’de uzun süre kalabilir. Server state de yalnız database olmak zorunda değildir; process memory veya başka bir store’da tutulabilir. Ayrım storage ürününün adından değil, kimin güncellemeyi kabul ettiği ve hangi karar için authoritative olduğundan doğar.

Bu örnekte UI tercihleri ve henüz gönderilmeyen taslak Browser’a aittir. Notun kabul edilmiş metni, resource ownership ve Atlas üyeliği server tarafından belirlenir. Bu farklı state’lerin hepsini tek “saved” etiketi altında toplamak yanlış güven oluşturur.

Snapshot ile authority’yi ayır

Browser server’dan aldığı metni ve version bilgisini saklayabilir. Bu, belirli bir anda gözlenmiş snapshot’tır. Başka bir sekme veya worker notu güncellediğinde Browser’ın eski kopyası kendi kendine authoritative hale gelmez.

Server da request body içindeki tenant, owner veya role alanlarını kullanıcı iddiası olarak görmelidir. Request’in gerçekten Duru’ya ait authenticated context’i ve hedef notun Atlas içindeki sahibi, trusted kayıtlarla çözülür. Client bir resource ID seçebilir; o resource üzerinde işlem yapma hakkını seçemez.

Görselde Application ile Authoritative record ayrı aktör olarak çizilse de bu dersin modelinde aynı server process’indeki mantıksal bileşenlerdir. Aradaki commit bir HTTP request değildir; bir sonraki session-store dersinde remote store farklı gösterilir.

Normal save: kabul edilen güncellemeyi görünür kıl

Fixture başlangıcında server note-v3 sürümünü, Browser ise aynı sürümün snapshot’ını bilir. Duru’nun yeni metni bu snapshot üzerine kurulmuştur. Request, yeni metin ve strong ETag olan “note-v3” için If-Match precondition taşır.

Application önce authenticated context’i, resource authorization’ı ve input kurallarını uygular. Ardından precondition ile güncellemeyi aynı tutarlı commit boundary’sinde değerlendirir. Fixture’da record hâlâ v3 ise yeni metin v4 olarak kabul edilir. Yanıt yeni representation version’ını bildirir.

Browser ancak başarılı yanıtı işledikten sonra “server’da kaydedildi” diyebilir. Request’i göndermek bir niyet, server commit bir karar, response arrival ise Browser’ın bu kararı öğrenmesidir. Üçünü ayrı state olarak izlemek bağlantı hatalarını anlaşılır kılar.

Stale snapshot: son yazan her zaman kazanmasın

İkinci branch’te Browser v2 üzerinden yazarken server’ın güncel notu v3’tür. Koşulsuz overwrite Duru’nun başka bir yerde kabul edilmiş değişikliğini silebilir. If-Match, mevcut representation için strong comparison yaparak bu lost update durumunu önlemeye yarar.

Fixture, precondition false olduğunda mutation uygulamayıp 412 Precondition Failed döner. Bu response login başarısızlığı değildir; Browser’ın dayandığı representation güncel state ile uyuşmamıştır. Server v3 kalır, taslak korunur ve UI conflict gösterir.

Client yalnız yeni ETag alıp eski taslağı otomatik zorla yazmamalıdır. Güncel notu getir, kullanıcının niyetini mevcut metinle karşılaştır ve gerekirse yeni base version üzerine tekrar onaylı update kur. Check ile write’ın farklı yarışabilir işlemler olması, header’ın sağladığı amaçlanan korumayı bozar.

Response kaybolursa sonuç unknown olabilir

Server v4 commit ettikten sonra response Browser’a ulaşmayabilir. Browser hâlâ v3 bildiği için “server kaydetmedi” demesi de, yalnız request gönderdiği için “kaydedildi” demesi de kanıtsızdır. Bu branch’te server state changed, client knowledge unknown’dur.

Düzeltme, kayıp bağlantıyı otomatik başarısız mutation saymak değil, güncel representation’ı yeniden okuyup taslakla reconcile etmektir. Bu örneğin PUT method’u HTTP semantics açısından idempotent’tir: aynı request’in tekrarı aynı amaçlanan etkiyi taşır, fakat response farklı olabilir. Fixture’ın strict If-Match politikasında ilk commit sonrası v3 artık eşleşmez. Diğer operation’ların güvenli retry davranışı kendi semantics ve idempotency tasarımına bağlıdır.

Offline queue için aynı ayrımı koru. “Yerelde sıraya alındı” kullanıcıya faydalı bir başarıdır, ancak server acceptance vaadi değildir. Yetki ve state değişmiş olabileceği için queued update server’a vardığında tekrar doğrulanır.

ETag neyi kanıtlar?

ETag, representation version’ının opaque validator’ıdır; credential, role veya ownership proof değildir. Bu örnekte note-v3 okunabilir bir instructional alias’tır. Gerçek uygulama validator biçimini kendisi seçer; artan sayıya benzeyen her alan otomatik strong ETag olmaz.

If-Match concurrency koşulunu taşır. Authorization ise “Duru bu notu bu eylemle değiştirebilir mi?” sorusunu yanıtlar. İkisi gerekli olduğunda ikisi de uygulanır. Aynı sürümü bilmek yetki vermediği gibi, yetki sahibi olmak eski state’i koşulsuz overwrite etme zorunluluğu yaratmaz.

Hareket olmadan bütün senaryoları oku

Eşleşen snapshot

Update niyeti browser’da
Duru’nun taslağı note-v3 snapshot’ına dayanır. PUT için If-Match="note-v3" hazırlanır; browser’daki yeni metin server record’unun değiştiğini göstermez.
Browser draft
Draft; base="note-v3"
Application
Update alınmadı
Server record
Server="note-v3"
Conditional update ulaştı
Application PUT /books/book-17/notes/mine girdisini aldı. Bu fixture’da Duru/Atlas authorization önceden allowed olarak verilmiştir; header’dan yeni bir izin türetilmez.
Browser draft
Sonuç bekleniyor
Application
If-Match="note-v3" alındı
Server record
Server="note-v3"
Version koşulu ayrıldı
If-Match concurrency koşuludur; ETag bir credential veya ownership proof değildir. Application’ın identity, input ve resource kontrolleri bu koşuldan bağımsızdır.
Browser draft
Sonuç bekleniyor
Application
Base note-v3; current note-v3
Server record
Server="note-v3"
Koşul commit sınırında uygulandı
Karşılaştırma ile mutation aynı tutarlı boundary’dedir. Base ve current eşleştiğinden yeni not note-v4 olarak commit edilir. Application ile record bu sahnede aynı process’in mantıksal bileşenleridir.
Browser draft
Sonuç bekleniyor
Application
precondition=true
Server record
Server="note-v4"
HTTP sonucu hazırlandı
Application 200 response’unu hazırlar. Başarılı commit henüz browser tarafından öğrenilmiş değildir.
Browser draft
Sonuç bekleniyor
Application
200 response hazır
Server record
Server="note-v4"
Server sonucu browser’a ulaştı
Browser response’u aldıktan sonra server’da kaydedildi sonucunu ve note-v4 snapshot’ını bilir.
Browser draft
Saved; note-v4
Application
200 response hazır
Server record
Server="note-v4"

Eski snapshot

Update niyeti browser’da
Duru’nun taslağı note-v2 snapshot’ına dayanır. PUT için If-Match="note-v2" hazırlanır; browser’daki yeni metin server record’unun değiştiğini göstermez.
Browser draft
Draft; base="note-v2"
Application
Update alınmadı
Server record
Server="note-v3"
Conditional update ulaştı
Application PUT /books/book-17/notes/mine girdisini aldı. Bu fixture’da Duru/Atlas authorization önceden allowed olarak verilmiştir; header’dan yeni bir izin türetilmez.
Browser draft
Sonuç bekleniyor
Application
If-Match="note-v2" alındı
Server record
Server="note-v3"
Version koşulu ayrıldı
If-Match concurrency koşuludur; ETag bir credential veya ownership proof değildir. Application’ın identity, input ve resource kontrolleri bu koşuldan bağımsızdır.
Browser draft
Sonuç bekleniyor
Application
Base note-v2; current note-v3
Server record
Server="note-v3"
Koşul commit sınırında uygulandı
Karşılaştırma ile mutation aynı tutarlı boundary’dedir. Base v2 current v3 ile eşleşmediğinden mutation yapılmaz; note-v3 korunur. Application ile record bu sahnede aynı process’in mantıksal bileşenleridir.
Browser draft
Sonuç bekleniyor
Application
precondition=false
Server record
Server="note-v3"
HTTP sonucu hazırlandı
Application 412 response’unu hazırlar. 412 concurrency conflict’tir; login başarısızlığı değildir ve korunmuş draft’ı değiştirmez.
Browser draft
Sonuç bekleniyor
Application
412 response hazır
Server record
Server="note-v3"
Server sonucu browser’a ulaştı
Browser response’u aldıktan sonra conflict durumunu bilir; eski snapshot ve draft korunur. Eski metin yeni ETag ile körlemesine zorla yazılmaz.
Browser draft
Conflict; draft korundu
Application
412 response hazır
Server record
Server="note-v3"

VARSAYIM · SINIR · KONTROL

Hangi state kararın girdisi oluyor?

Defensive incelemede UI’da düğmenin görünmesi ile server’ın eylemi kabul etmesini farklı gözlemler say. Hidden/disabled kontrol yalnız interaction state’tir. Browser’da role=editor görülmesi trusted authorization sonucu değildir.

Tenant ve owner seçimini client’tan alan bir iş akışında server’ın authenticated subject ile resource ilişkisini kendi trusted verisi üzerinden çözmesi gerekir. Bu dersin fixture’ında Duru/Atlas context’i önceden doğrulanmış supplied input’tur; bir login akışı veya izin testi taklidi değildir.

Başarı metni de bir claim’dir

Bir save flow’u değerlendirirken optimistic UI’nın hangi anda “saved” dediğini izle. Server reddettiğinde veya sonucu bilinmediğinde bu ifade geri alınmıyorsa ürün kullanıcının state bilgisini bozar.

İnceleme için üç inert branch yeterli: eşleşen base version, stale base version ve commit sonrası response loss. Sonuncusunda iki farklı kopyanın farklı bilgi taşıması normaldir; hepsini authentication compromise diye yorumlama.

Retry değerlendirmesinde aynı amaçlanan etkiyi korumak ile aynı yanıtı almak ayrı sorulardır. Bu örnekte ilk PUT kaydedilmişse aynı eski If-Match ile ikinci deneme strict politika nedeniyle 412 alabilir; bu, ilk commit’in geri alındığını göstermez. Yeniden okunan representation o anda gözlenen state’i açıklar. Kayıp yanıtın kendisi, arada başka bir update olup olmadığını açıklamaz; UI pending durumunu bu belirsizliğe göre göstermelidir.

Hareket olmadan bütün senaryoları oku

Response gözlendi

Update evidence kapsamı seçildi
İnceleme normal satırını kullanır. Server kararı ve browser knowledge ayrı alanlardır; aynı snapshot’a sahip olmaları zorunlu değildir.
Update satırı
case=normal
Commit incelemesi
Karşılaştırma yapılmadı
Client knowledge
Client sonucu bilinmiyor
Precondition sonucu okundu
browserBase ve serverBefore note-v3’tür; precondition=true kaydı bu update’in version koşulunu açıklar. Bu alan authentication veya resource permission kanıtı değildir.
Update satırı
case=normal
Commit incelemesi
precondition=true
Client knowledge
Client sonucu bilinmiyor
Server commit ayrı doğrulandı
serverDecision=committed ve serverAfter=note-v4 kayıtlıdır. Response status 200 olarak hazırlanmıştır; bu status tek başına response receipt göstermez.
Update satırı
case=normal
Commit incelemesi
Committed; note-v4; status=200
Client knowledge
Client sonucu bilinmiyor
Receipt bilgisi karşılaştırıldı
responseObserved=true olduğundan browserKnowledge=note-v4 ve UI saved on server durumundadır.
Update satırı
case=normal
Commit incelemesi
Server: note-v4
Client knowledge
Browser: note-v4; saved
Integrity seçimi sınırlandı
Precondition false iken committed true satırlarını sayan selector ana fixture’da 0 döndürür; ayrı positive fixture 1 verir. Response receipt eksikliği bu predicate’in ihlali değildir.
Update satırı
case=normal
Commit incelemesi
Ana count=0; positive=1
Client knowledge
Receipt: true
Client claim’i kanıta bağlandı
Bu satır hem commit hem receipt gösterir; server’da kaydedildi claim’i desteklenir. Daha sonraki başka update’ler hakkında hüküm verilmez.
Update satırı
case=normal
Commit incelemesi
Commit kanıtı var
Client knowledge
Receipt kanıtı var

Response eksik

Update evidence kapsamı seçildi
İnceleme response-lost satırını kullanır. Server kararı ve browser knowledge ayrı alanlardır; aynı snapshot’a sahip olmaları zorunlu değildir.
Update satırı
case=response-lost
Commit incelemesi
Karşılaştırma yapılmadı
Client knowledge
Client sonucu bilinmiyor
Precondition sonucu okundu
browserBase ve serverBefore note-v3’tür; precondition=true kaydı bu update’in version koşulunu açıklar. Bu alan authentication veya resource permission kanıtı değildir.
Update satırı
case=response-lost
Commit incelemesi
precondition=true
Client knowledge
Client sonucu bilinmiyor
Server commit ayrı doğrulandı
serverDecision=committed ve serverAfter=note-v4 kayıtlıdır. Response status 200 olarak hazırlanmıştır; bu status tek başına response receipt göstermez.
Update satırı
case=response-lost
Commit incelemesi
Committed; note-v4; status=200
Client knowledge
Client sonucu bilinmiyor
Receipt bilgisi karşılaştırıldı
responseObserved=false olduğundan browserKnowledge eski note-v3 snapshot’ı ve outcome unknown olarak kalır. Commit yapılmadığı sonucu çıkarılamaz.
Update satırı
case=response-lost
Commit incelemesi
Server: note-v4
Client knowledge
Browser: note-v3; UNKNOWN
Integrity seçimi sınırlandı
Precondition false iken committed true satırlarını sayan selector ana fixture’da 0 döndürür; ayrı positive fixture 1 verir. Response receipt eksikliği bu predicate’in ihlali değildir.
Update satırı
case=response-lost
Commit incelemesi
Ana count=0; positive=1
Client knowledge
Receipt: false
Client claim’i kanıta bağlandı
Bu satırda server commit bilinir, client sonucu unknown’dur. Taslak korunur; güncel representation yeniden okunup reconcile edilmeden kaydedilmedi veya kaydedildi diye kesin UI sonucu verilmez.
Update satırı
case=response-lost
Commit incelemesi
Commit kanıtı var
Client knowledge
UNKNOWN: client confirmation

UYGULAMA · GÜVENLİK KONTROLÜ · DOĞRULAMA

Owner ve başarı boundary’sini yaz

UI input ve local draft için Browser owner; accepted note ve access policy için trusted server owner tanımla. Her state’in data source, version ve freshness bilgisi olsun. Cache veya snapshot kullanıldığında authoritative kaydın yerini açıkça belirt.

UI’da unsaved, saving, saved locally, queued, saved on server ve conflict gibi gerçekten farklı durumları yalnız gerekli yerde kullan. State model’in bilmediği sonucu başarı ya da başarısızlık diye uydurma.

Koşulu commit ile birlikte uygula

Concurrent update kabul eden endpoint’te request authorization ve input validation’ı uygula; precondition karşılaştırması ile mutation’ı tutarlı bir commit sınırında yap. Database conditional update veya transaction gibi uygun primitive seçimi server implementasyonuna bağlıdır.

Stale precondition durumunda mevcut record değişmemelidir. Taslağı koruyan conflict response ve reconcile akışı oluştur. ETag kontrolünü yalnız frontend’da yapmak server’ın lost update sınırını korumaz.

Unknown response’u yeniden gözlemle

Bağlantı kopmasında server record’u yeniden okuyup bilinen version ve taslakla karşılaştır. Mutation tekrarı gerekiyorsa işlemin idempotency ve concurrency politikasını kullan. Kullanıcıya draft’ın korunduğunu ve server sonucu doğrulanırken neyin pending kaldığını anlat.

Secret içermeyen observation’da baseVersion, currentVersion, decision ve responseObserved alanları yararlıdır. Bunlar gerçek HTTP capture sayılmaz; fixture kendi durum geçişlerini gösterir. Kullanıcının not metnini veya session credential’ını log’a taşımadan da sınırı anlayabilirsin.

ŞİMDİ VAKAYA UYGULA

Server değişirken browser ne zaman bunu bilir?

Not güncellemesinde If-Match yalnız version koşuludur. Server commit ile browser’ın response’u öğrenmesi ayrı boundary’ler olarak gösterilir.

Vakadaki browser verisi hangi owner’ın state’idir? Bir client değerinin bulunması veya silinmesiyle server-side session sonucunun neden aynı şey olmadığını açıkla.

Bağlı vaka dosyasını aç ↗

ÖRNEĞİ BİRLİKTE OKUYALIM

Not update ownership ve version defteri

Bir alan seç; hangi sonucu desteklediğini ve nerede yetersiz kaldığını incele.

Ham kaydı ve alan açıklamalarını oku

{
  "resource": "atlas/book-17/note-duru",
  "authenticatedContext": {
    "displayName": "Duru",
    "tenant": "Atlas",
    "authorization": "supplied as already allowed; not verified by this fixture"
  },
  "requestShape": {
    "method": "PUT",
    "path": "/books/book-17/notes/mine",
    "ifMatch": "\"note-v3\"",
    "bodyClass": "harmless new reading note"
  },
  "cases": [
    {
      "case": "normal",
      "browserBase": "\"note-v3\"",
      "serverBefore": "\"note-v3\"",
      "precondition": true,
      "serverAfter": "\"note-v4\"",
      "serverDecision": "committed",
      "responseStatus": 200,
      "responseObserved": true,
      "browserKnowledge": "\"note-v4\"",
      "ui": "saved on server"
    },
    {
      "case": "stale",
      "browserBase": "\"note-v2\"",
      "serverBefore": "\"note-v3\"",
      "precondition": false,
      "serverAfter": "\"note-v3\"",
      "serverDecision": "not committed",
      "responseStatus": 412,
      "responseObserved": true,
      "browserKnowledge": "old snapshot plus conflict",
      "ui": "conflict; draft preserved"
    },
    {
      "case": "response-lost",
      "browserBase": "\"note-v3\"",
      "serverBefore": "\"note-v3\"",
      "precondition": true,
      "serverAfter": "\"note-v4\"",
      "serverDecision": "committed",
      "responseStatus": 200,
      "responseObserved": false,
      "browserKnowledge": "\"note-v3\"; outcome unknown",
      "ui": "pending confirmation; draft preserved"
    }
  ],
  "selector": {
    "xml": "<updates><update case=\"normal\" precondition=\"true\" committed=\"true\" responseObserved=\"true\"/><update case=\"stale\" precondition=\"false\" committed=\"false\" responseObserved=\"true\"/><update case=\"response-lost\" precondition=\"true\" committed=\"true\" responseObserved=\"false\"/></updates>",
    "xpath": "count(/updates/update[@precondition=\"false\" and @committed=\"true\"])",
    "expected": 0,
    "positiveFixtureXml": "<updates><update precondition=\"false\" committed=\"true\"/></updates>",
    "positiveExpected": 1
  }
}

browserBase / serverBefore: Browser snapshot validator’ı ile server’ın current validator’ı; eşitlik yalnız concurrency precondition’ıdır.
serverAfter / serverDecision: Trusted server commit sonucu; response’ın ulaşıp ulaşmadığından bağımsızdır.
responseObserved / browserKnowledge: Browser’ın sonucu öğrenip öğrenmediği; gönderim tek başına server save kanıtı değildir.
selector: False precondition ile commit’i aynı anda iddia eden fixture kaydını seçer.

ETag’ler instructional alias; response code’ları seçilmiş fixture davranışıdır. Store aynı process’te mantıksal record’dur. Gerçek authorization, HTTP server, concurrency race veya ağ hatası çalıştırılmadı.

İki yanlış kanı

Browser’da saklanan veya UI’da görünen değer server için authoritative state’tir.

Client kopyası input ya da snapshot olabilir. Resource ownership, authenticated authority ve accepted record trusted server’da çözülür.

Response alınmadıysa server update kesin başarısızdır; tekrar göndermek her zaman güvenlidir.

Commit olup response kaybolmuş olabilir. Outcome unknown durumunda güncel state’i gözlemle ve operation’ın concurrency/idempotency kuralıyla reconcile et.

SIRA SENDE

Bu hikâyeyi sen çöz.

Sonucu tahmin et, kanıtın sınırını bul ve nedenini kendi cümlenle anlat.

Browser note-v2 ile PUT yapıyor; server’da note-v3 var. State değişir mi?

Hayır. 412 döner; note-v3 ve client draft korunur.
Evet. Client draft her zaman güncel server kaydının üstündedir.

Gerekçeli cevabı oku

Hayır. 412 döner; note-v3 ve client draft korunur. — Stale precondition sağlanmaz ve commit yapılmaz. Bu sonuç client’ın draft’ını silmesini gerektirmez.

Response-lost branch’inde browser saved hakkında ne söyleyebilir?

Dersten seçilen artifact alanları; öğretim örneği

cases[2].serverDecision: committed
cases[2].responseObserved: false
cases[2].browserKnowledge: "note-v3"; outcome unknown
cases[2].ui: pending confirmation; draft preserved

Request hata verdiyse server kesinlikle write yapmamıştır.
Sonuç bilinmiyor; onay beklenirken draft korunabilir.

Gerekçeli cevabı oku

Sonuç bilinmiyor; onay beklenirken draft korunabilir. — Örnekte server commit eder, fakat responseObserved=false. Browser’ın bildikleri bu commit bilgisini henüz içermez.

Client draft, güncel server kaydı ve verilmiş authorization sonucu hangi üç sınırı temsil eder?

Gerekçeli cevabı oku

Client draft, browser’ın henüz server’a kabul ettirmediği içeriktir. Server kaydı güncel revision ile commit edilmiş değeri taşır; If-Match eski snapshot’ı ayırır. Bu örnekte authenticatedContext izni önceden kabul edilmiş girdi olarak verilmiştir; authentication testi değildir. Revision eşleşmesi tenant/user izninin yerine geçmez.

□ Draft ile güncel server kaydını ayırdım.

□ Verilen permission sonucunu çalıştırılmış authentication testi saymadım.

Uygulama konsolunu aç · request / response / browser

Request, URL, cookie ve DOM örneklerini ayrıca aç

Kaynaklar ve kapsam

OWASP — Authorization Cheat SheetValidate the Permissions on Every Request · Verify that Authorization Checks are Performed in the Right Location
OWASP — HTML5 Security Cheat SheetStorage APIs: Local Storage · Storage APIs: IndexedDB
RFC 9110 — HTTP Semantics8.8.3 ETag · 13.1.1 If-Match · 13.2.1 When to Evaluate Preconditions · 15.5.13 412 Precondition Failed · 9.2.2 Idempotent Methods

KENDİ NOTUN / BU TARAYICIDA

Client ve server state sahipliği

1. Core · Mekanizma

Base version matches

Stale precondition

Commit · response lost

Bir notun birden fazla doğru durumu vardır

Snapshot ile authority’yi ayır

Normal save: kabul edilen güncellemeyi görünür kıl

Stale snapshot: son yazan her zaman kazanmasın

Response kaybolursa sonuç unknown olabilir

ETag neyi kanıtlar?

2. Red · Güven ve etki

Eşleşen snapshot

Eski snapshot

Hangi state kararın girdisi oluyor?

Başarı metni de bir claim’dir

3. Blue · Güvenli geliştirme ve savunma

Response gözlendi

Response eksik

Owner ve başarı boundary’sini yaz

Koşulu commit ile birlikte uygula

Unknown response’u yeniden gözlemle

Server değişirken browser ne zaman bunu bilir?

İki yanlış kanı

Browser note-v2 ile PUT yapıyor; server’da note-v3 var. State değişir mi?

Response-lost branch’inde browser saved hakkında ne söyleyebilir?

Client draft, güncel server kaydı ve verilmiş authorization sonucu hangi üç sınırı temsil eder?

Kaynaklar ve kapsam