Web Programlama

Web programlama, yalnız HTML etiketi veya belirli bir sunucu çatısı öğrenmek değildir. Tarayıcı, DNS, URL, HTTP, TLS, HTML, CSS, JavaScript, erişilebilirlik, güvenlik, önbellekleme, istemci durumu ve sunucu tarafı uygulama modelinin birlikte nasıl davrandığını anlamayı gerektirir. Bu ders, tarihsel teknolojileri bugünkü yerleriyle ilişkilendirirken güncel Web platformunu standartlar üzerinden ele alır.

Web sürekli gelişen bir platformdur. HTML ve Fetch, yaşayan standartlar olarak güncellenir; JavaScript dili ECMAScript standardıyla sürümlenir; HTTP semantiği taşıma sürümünden ayrıdır. Bu nedenle dersin amacı tek bir editöre, tarayıcıya veya framework sürümüne bağımlı bilgi vermek değil, kalıcı protokol ve platform ilkelerini öğretmektir.

Ünite 1: Web Mimarisi, Adresleme ve HTTP Temelleri

Bir HTTP etkileşimini çözümlerken önce kaynak kimliği, istek yöntemi, önkoşullar ve beklenen yan etki belirlenir. Başarılı durum kodu uygulama düzeyindeki bütünlük kuralını tek başına garanti etmez; doğrulama ve yetkilendirme ayrı süreçlerdir. Tekrarlanan isteklerin davranışı seçilen yöntemin idempotent olup olmamasıyla ilişkilendirilir. İstemci ve sunucu sözleşmesi, ağ kopması veya yanıtın alınamaması halinde aynı işlemin nasıl güvenle ele alınacağını açıklamalıdır.

1.1. İnternet ile Web Aynı Şey Değildir

İnternet, IP tabanlı ağların birbirine bağlanmasını sağlayan küresel altyapıdır. Web ise bu altyapı üzerinde URL, HTTP, HTML ve tarayıcı API'leriyle çalışan uygulama katmanı ekosistemidir. E-posta, SSH, DNS ve başka protokoller İnternet'i kullanabilir fakat Web'in parçası olmak zorunda değildir.

Bu ayrım mimaride önemlidir. Bir web uygulamasının kullanıcı arayüzü HTTP üzerinden çalışırken arka plandaki servisler mesaj kuyruğu, veritabanı protokolü veya başka taşıma mekanizmaları kullanabilir.

1.2. İstemci-sunucu Modelinden Dağıtık Web Uygulamasına

En basit modelde tarayıcı istemci, uygulama ise sunucudur. Gerçek sistemde istek yolu daha uzundur:

browser
-> recursive DNS resolver
-> CDN / edge
-> load balancer / reverse proxy
-> web application
-> cache / database / message broker / downstream service

Her katman gecikme, hata, güvenlik ve önbellek davranışını değiştirir. Kullanıcının gördüğü tek bir sayfa çok sayıda origin'e ve hizmete istek gönderebilir.

1.3. DNS: Ad Çözümleme ve Yetki Zinciri

DNS alan adını yalnız bir IP adresine çeviren tablo değildir. Hiyerarşik ve dağıtık bir adlandırma sistemidir. A ve AAAA kayıtları adres, CNAME takma ad, MX posta, TXT çeşitli doğrulama/politika verileri için kullanılabilir.

tarayıcı
   |
   v
özyinelemeli çözümleyici
   |
   +--> kök
   |      |
   |      v
   +--> TLD
   |      |
   |      v
   +--> yetkili DNS
   |
   v
IP adresi + TTL

DNS yanıtları TTL ile önbelleğe alınabilir. Bu nedenle kayıt değişikliği her istemcide anında görünmeyebilir. DNSSEC, DNS verisinin özgünlük ve bütünlüğünü doğrulamaya yönelik imzalı bir zincir sağlar; TLS'in veya uygulama kimlik doğrulamasının yerine geçmez.

1.4. URL, URI, Origin ve Site Kavramları

Bir HTTP URL'si tipik olarak şema, host, isteğe bağlı port, path, query ve fragment bileşenlerinden oluşur:

https://api.example.org:8443/v1/items?id=42#details

origin, şema + host + port üçlüsüdür. Tarayıcı güvenlik modeli açısından https://a.example ile https://b.example farklı origin'lerdir. site kavramı ise cookie ve bazı güvenlik politikalarında registrable domain bağlamıyla kullanılır. Bu iki kavram aynı değildir.

Fragment (#...) normal HTTP isteğinde sunucuya gönderilmez; tarayıcı tarafı gezinme veya istemci durumu için kullanılır.

1.5. HTTP Semantiği Taşıma Sürümünden Ayrıdır

HTTP kaynaklara ilişkin istek-cevap semantiğini tanımlar. HTTP/1.1, HTTP/2 ve HTTP/3 aynı temel metot ve durum kodu semantiğini paylaşır; taşıma ve mesajlama biçimleri farklıdır. HTTP/2 bir bağlantı üzerinde çoklu akış ve başlık sıkıştırma getirir. HTTP/3 ise QUIC üzerinde çalışır ve TCP yerine UDP tabanlı güvenli çoklama kullanır.

Bir uygulamanın GET, POST, PUT, PATCH veya DELETE seçimi yalnız CRUD etiketi değildir. Güvenli ve idempotent metot semantiği retry, önbellek ve proxy davranışını etkiler.

HTTP yönteminin idempotent kabul edilmesi, belirli bir uygulama işleminin ağ tekrarlarında güvenli olduğu anlamına gelmez. Aynı ödeme oluşturma isteği bağlantı kopması yüzünden iki kez gönderildiğinde iki ayrı işlem kaydı oluşabilir. İstemci, ilk isteğin sunucuda tamamlanıp tamamlanmadığını yalnız zaman aşımı bilgisinden çıkaramaz. Tekrar denenebilir yazma işlemlerinde sunucu tarafında kapsamı tanımlanmış benzersiz istek anahtarı, sonuç saklama ve çakışma politikası tasarlanabilir. Anahtarın yaşam süresi ve aynı anahtarla farklı yük gönderildiğinde davranış da sözleşmede belirtilmelidir.

1.6. İstek ve Cevap Anatomisi

Bir HTTP mesajında başlangıç bilgisi, başlıklar ve isteğe bağlı gövde bulunur. Örnek bir istek:

GET /api/devices/42 HTTP/1.1
Host: example.org
Accept: application/json
If-None-Match: "v17"

Örnek cevap:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: private, max-age=60
ETag: "v17"

{"id":42,"state":"active"}

Başlıklar protokol üst verisidir. Uygulama verisini gelişigüzel özel başlıklara taşımak yerine HTTP semantiğine ve içerik modeline uygun tasarım yapılmalıdır.

1.7. Durum Kodlarını İş Mantığıyla Karıştırmamak

Durum kodu, HTTP seviyesindeki sonucu sınıflandırır. Genel aileler:

• 2xx: istek işlendi,
• 3xx: yönlendirme veya koşullu/önbellek sonucu,
• 4xx: istemci bağlamında düzeltilebilir istek/erişim sorunu,
• 5xx: sunucu isteği yerine getiremedi.

200 OK içinde {"success":false} döndürmek protokol bilgisini uygulama gövdesine saklar. Buna karşılık her iş kuralı ihlalini 500 yapmak da yanlıştır. API sözleşmesi HTTP durumu ile domain hata gövdesini birlikte tanımlamalıdır.

1.8. HTTPS ve TLS

HTTPS, HTTP'nin TLS ile korunmuş taşıma üzerinden kullanılmasını ifade eder. TLS üç temel hedef sağlar: uç nokta kimliğinin sertifika zinciriyle doğrulanması, aktarım gizliliği ve bütünlük.

TLS uygulama seviyesindeki yetkilendirme değildir. Geçerli sertifikaya sahip sunucu yine yanlış kullanıcıya veri verebilir. Benzer biçimde HTTPS, XSS veya SQL injection gibi uygulama açıklarını çözmez.

Üretimde HTTP'den HTTPS'ye yönlendirme, HSTS, modern TLS yapılandırması ve sertifika yaşam döngüsü birlikte yönetilmelidir.

Ünite 2: Tarayıcı Platformu, HTML, CSS ve JavaScript

2.1. HTML: İçerik ve Anlam Katmanı

HTML, programlama dili değil; belgenin semantik yapısını ve web uygulaması yüzeyini tanımlayan işaretleme dilidir. Güncel HTML yaşayan bir standarttır; eski "HTML5 sürümü" ezberinden çok, güncel uyumluluk ve semantik elemanlar önemlidir.

<main>
  <article>
    <header>
      <h1>Sistem Durumu</h1>
    </header>
    <p>Son güncelleme <time datetime="2026-09-16T09:30:00+03:00">09:30</time>.</p>
  </article>
</main>

div her şeyi kapsayabilir; ancak main, nav, article, section, button, label gibi doğru elemanlar erişilebilirlik, tarayıcı davranışı ve bakım açısından daha güçlü sözleşme sağlar.

2.2. HTML Ayrıştırıcılarının Hata İşleme Davranışı

text/html içeriği XML gibi katı bir ayrıştırıcı ile işlenmez. HTML standardı hata toleranslı ayrıntılı parsing algoritması tanımlar. Bu nedenle bozuk etiket dizisi tarayıcıda "çalışıyor" görünebilir; fakat üretilen DOM geliştiricinin metne bakarak tahmin ettiği ağaç olmayabilir.

Doğru yöntem, geçerli ve semantik HTML üretmek, validator ve tarayıcı geliştirme araçlarıyla gerçek DOM'u kontrol etmektir.

2.3. Formlar, Native Kontroller ve Doğrulama

HTML form kontrolleri erişilebilir klavye davranışı, form serialization ve yerleşik doğrulama mekanizmaları sağlar.

<form id="device-form">
  <label for="serial">Seri numarası</label>
  <input id="serial" name="serial" required minlength="6" autocomplete="off">
  <button type="submit">Kaydet</button>
</form>

İstemci doğrulaması kullanıcı deneyimidir; güvenlik sınırı değildir. Sunucu gelen her alanı yeniden doğrulamalıdır. disabled alanların gönderilmemesi, checkbox/radio serialization kuralları ve çok parçalı dosya yükleme gibi ayrıntılar API sözleşmesini etkiler.

2.4. CSS: Cascade, Layout ve Responsive Tasarım

CSS yalnız renk/font vermek değildir. Cascade, specificity, inheritance, box model ve formatting context davranışlarını tanımlar. Güncel layout için Flexbox ve Grid ana araçlardır; responsive davranış media query ve uygun olduğunda container query ile modellenebilir.

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(18rem, 1fr));
  gap: 1rem;
}

.card {
  container-type: inline-size;
}

Inline stil veya !important yığınları kısa vadeli düzeltme sağlayıp uzun vadede cascade yönetimini bozar. Tasarım token'ları, katmanlar ve sınırlı selector karmaşıklığı daha öngörülebilir sonuç verir.

2.5. Responsive Tasarım Çözünürlük Listesi Değildir

Responsive tasarım, sabit birkaç ekran genişliği için ayrı sayfa üretmek yerine içeriğin kullanılabilirliğini farklı viewport, zoom, yazı boyutu ve giriş yöntemlerinde korumaktır.

Sadece piksel breakpoint'lerine göre tasarım yapmak yeterli değildir. Uzun çeviriler, sistem font ölçeği, klavye odağı, dokunma hedefleri, prefers-reduced-motion, yüksek kontrast ve yatay/dikey kullanım test edilmelidir.

2.6. Web Erişilebilirliği

Erişilebilirlik sonradan ARIA eklemek değildir. Doğru HTML elemanı ilk tercihtir. Bir button, klavye, odak ve rol davranışını hazır sağlar; div onclick aynı sözleşmeyi sağlamaz.

Temel kontroller:

• anlamlı başlık hiyerarşisi,
• form alanı için programatik label,
• klavye ile tüm işlemler,
• görünür focus,
• yalnız renkle bilgi vermeme,
• görsellerde amaca uygun alternatif metin,
• yeterli kontrast,
• dinamik durumların gerektiğinde erişilebilir biçimde bildirilmesi.

WCAG 2.2 güncel W3C Recommendation'dır; erişilebilirlik testleri yalnız otomatik tarayıcıya bırakılmamalıdır.

2.7. JavaScript ve ECMAScript

JavaScript'in standart dili ECMAScript'tir. ECMAScript 2026, ECMA-262'nin 17. baskısıdır. Modern kodda let/const, modules, promises, async/await, iterators, classes ve typed arrays gibi dil/platform özellikleri doğrudan kullanılabilir; jQuery'nin tarihsel olarak çözdüğü birçok DOM ve ağ işlemi artık platform API'lerinde bulunur.

const state = Object.freeze({ retries: 3 });

export function normalize(value, min, max) {
  if (max <= min) throw new RangeError("invalid range");
  return (value - min) / (max - min);
}

JavaScript'in dinamik tür yapısı, bilinmeyen dış verinin doğrulanması gereğini ortadan kaldırmaz.

2.8. DOM ve Olay Modeli

Tarayıcı HTML'i DOM ağacına dönüştürür. JavaScript bu ağacı standart API'lerle okuyup değiştirebilir.

const button = document.querySelector("#refresh");
const output = document.querySelector("#status");

button.addEventListener("click", async () => {
  output.textContent = "Yükleniyor";
  const response = await fetch("/api/status");
  output.textContent = response.ok ? "Hazır" : `Hata ${response.status}`;
});

Inline onclick yerine addEventListener kullanmak içerik ile davranışı ayırır ve CSP ile daha uyumlu bir yapı sağlar.

Olaylar capture, target ve bubble aşamalarından geçebilir. Delegation, çok sayıda benzer elemanda tek üst dinleyiciyle daha düşük kayıt maliyeti sağlayabilir.

2.9. 16A. Tarayıcı İşleme ve Çizim Hattı ile Süreç Modeli

DOM değişikliği ekranda doğrudan piksel değişikliği değildir. Tarayıcı HTML, CSS ve JavaScript durumunu birden fazla aşamada görsel çıktıya dönüştürür.

2.9.1. Stil, Yerleşim, Boyama ve Birleştirme

Basitleştirilmiş işleme ve çizim zinciri:

DOM + CSSOM
    ↓
style calculation
    ↓
layout
    ↓
paint
    ↓
layer/composite
    ↓
ekran

Style calculation hangi CSS kurallarının hangi öğeye uygulanacağını belirler. Layout öğelerin geometri ve konumlarını hesaplar. Paint metin, arka plan, kenarlık ve diğer görsel komutları üretir. Compositing ise katmanları uygun sırayla birleştirir.

Her değişiklik bütün zinciri çalıştırmak zorunda değildir. Örneğin bazı transform/opacity animasyonları uygun katmanlaştırmada layout veya paint işini azaltabilir. Buna karşılık geometriyi etkileyen özellikler daha geniş yeniden hesaplama doğurabilir.

2.9.2. Layout Thrashing

JavaScript bir DOM yazımından hemen sonra geometri okursa tarayıcı bekleyen style/layout işini senkron tamamlamak zorunda kalabilir.

Kötü desen:

write DOM
read layout
write DOM
read layout
...

Daha iyi yaklaşım ilişkili okumaları ve yazmaları gruplamaktır. Performans kararı tahminle değil browser profiler ve gerçek kullanıcı iş yüküyle doğrulanmalıdır.

2.9.3. Ana İş Parçacığı ve Compositor

JavaScript, DOM işlemleri ve rendering işinin önemli bölümü main thread üzerinde rekabet edebilir. Uzun süren JavaScript görevi giriş olaylarının ve görsel güncellemenin gecikmesine yol açabilir.

Compositor thread belirli katman işlemlerini main thread'den bağımsız ilerletebilir; fakat bu "CSS animasyonları her zaman ucuzdur" anlamına gelmez. Katman sayısı, GPU belleği ve paint maliyeti ayrı sınırlardır.

2.9.4. Tarayıcı Process Modeli

Modern tarayıcılar güvenlik ve hata izolasyonu için tek bir işletim sistemi süreci olmak zorunda değildir. Browser process, renderer process, GPU ve yardımcı süreçler farklı sorumluluklara ayrılabilir. Site isolation gibi mekanizmalar kökenler arasındaki güvenlik sınırını process düzeyinde güçlendirebilir.

Bu mimari tarayıcıya göre değişebilir; web uygulaması belirli process sayısına bağımlı tasarlanmamalıdır.

2.9.5. Navigation ve Bfcache

Sayfadan ayrılmak her zaman önceki sayfanın tamamen yok edilmesi anlamına gelmez. Tarayıcı uygun sayfayı back/forward cache (bfcache) içinde dondurup geri dönüşte hızlı biçimde canlandırabilir.

Bu nedenle yaşam döngüsü yalnız:

load -> unload

olarak düşünülmemelidir. pageshow, pagehide, visibility durumu ve kalıcı bağlantılar gibi kaynaklar navigation davranışıyla birlikte test edilmelidir.

Rendering performansında temel ilke şudur: ağ süresi, JavaScript süresi, layout/paint ve kullanıcıya görünür gecikme ayrı ölçümlerdir. Birini azaltmak diğerlerinin otomatik olarak iyileştiği anlamına gelmez.

2.10. Modüller ve Yükleme Zamanı

Modern tarayıcı modülleri type="module" ile yükler. Module script'ler varsayılan olarak defer benzeri davranır, kendi scope'una sahiptir ve import/export kullanır.

<script type="module" src="/assets/app.js"></script>

Bundle aracı kullanmak zorunlu değildir. Bundling, minification, tree-shaking ve code-splitting ancak uygulamanın hedef tarayıcıları, önbellek stratejisi ve teslimat maliyetiyle birlikte seçilmelidir.

Ünite 3: İstemci Durumu, Kimlik ve Tarayıcı Güvenliği

Tarayıcıda kullanıcı durumu saklanırken hangi bilginin oturum boyunca gerekli olduğu ve hangi bilginin sunucu tarafında otoritatif kaldığı belirlenir. Sekmeler arasında değişebilen durum, geri gezinme ve süresi dolan oturum ayrı senaryolar olarak test edilmelidir. Güvenlik açısından arayüzde bir kontrolün gizlenmesi yetkilendirme yerine geçmez. İstemci, sunucu yanıtlarını kendi yetkisiyle yeniden doğrulamalı; hata durumunda eksik veriyi başarılı işlem gibi göstermemelidir.

3.1. Asenkron Model, Event Loop ve Microtask

JavaScript çalışma yığını
          |
          v
      event loop
       /
      v        v
microtask    task queue
 queue         |
             /
       v     v
     render fırsatı

Tarayıcı JavaScript'i event loop üzerinden çalıştırır. Promise continuation'ları microtask kuyruğuna girer; timer ve kullanıcı olayları farklı task kaynaklarından gelebilir. Uzun CPU işi ana iş parçacığını bloke ederek input ve rendering gecikmesine yol açar.

CPU yoğun işlem için parçalama, Web Worker veya uygun olduğunda WebAssembly değerlendirilebilir. async/await, işi otomatik olarak başka iş parçacığına taşımaz; promise tabanlı kontrol akışını daha okunabilir hale getirir.

3.1.1. Eski Asenkron Cevabın Yeni Kullanıcı Niyetini Ezmesini Önlemek

Tarayıcıda asenkron iş sırası, kullanıcı eylemi sırasıyla aynı olmak zorunda değildir. Kullanıcı A filtresini seçip hemen B filtresine geçtiğinde A isteği ağda daha geç tamamlanabilir. Sonuç doğrudan DOM'a yazılırsa ekranda B yerine A görünür; hata sunucuda değil istemci yaşam döngüsündedir.

İki temel çözüm vardır. Birincisi, önceki isteği AbortController ile iptal etmektir. İkincisi, her isteğe artan bir nesil numarası vermek ve yalnız son neslin sonucu uygulamasına izin vermektir. İptal ağ veya kütüphane katmanında her zaman kesin sonuç vermeyebileceği için kritik arayüzlerde nesil kontrolü ek bir güvence sağlayabilir.

A isteği ---- uzun -----\
                         X--> eski sonuç yok sayılır
B isteği -- kısa --> ekrana uygulanır

Bu desen arama, otomatik tamamlama, sekme değiştirme, tarih filtresi ve periyodik yenileme gibi alanlarda önemlidir. İstek iptal edildiğinde bunun hata bildirimi gibi sunulmaması gerekir; iptal çoğu zaman kullanıcının yeni bir karar verdiğini gösteren normal yaşam döngüsü olayıdır.

DOM güncellemesinin maliyeti de aynı akışın parçasıdır. Sık gelen küçük güncellemeler doğrudan layout tetikliyorsa rendering maliyeti büyüyebilir. Görsel güncellemeleri uygun durumda requestAnimationFrame ile bir sonraki paint çevrimine toplamak, veri akışı ile çizim zamanlamasını ayırır. Bu yaklaşım özellikle veri yoğun arayüzlerde UI/UX Mühendisliği ile birlikte değerlendirilmelidir.

3.2. Fetch API ve HTTP İstemcisi

Fetch Standard istek, cevap, redirect, CORS, credentials ve service worker etkileşimini ortak model altında tanımlar.

async function loadDevice(id, signal) {
  const response = await fetch(`/api/devices/${encodeURIComponent(id)}`, {
    headers: { Accept: "application/json" },
    signal
  });

  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }

  return response.json();
}

fetch yalnız ağ hatasında reject olabilir; 404 veya 500 otomatik exception değildir. response.ok veya durum kodu ayrıca kontrol edilmelidir.

3.3. Same-origin Policy ve CORS

Same-origin policy tarayıcıdaki bir origin'in başka origin kaynaklarına erişimini sınırlar. CORS, sunucunun belirli cross-origin okumalara izin vermesini sağlayan HTTP tabanlı opt-in protokolüdür.

CORS bir kimlik doğrulama veya sunucu tarafı erişim kontrolü değildir. Bir saldırgan sunucuya doğrudan HTTP isteği gönderebilir; CORS esas olarak tarayıcıdaki istemci kodunun yanıtı okuyup okuyamayacağını kontrol eder.

Credential kullanılan CORS yapılandırmasında wildcard ve origin yansıtma hataları özellikle dikkatle ele alınmalıdır.

3.4. Cookie, Session ve Tarayıcı Depolaması

Cookie HTTP istekleriyle otomatik gönderilebilir. Secure, HttpOnly ve SameSite güvenlik özellikleri kullanım amacına göre belirlenmelidir.

Set-Cookie: session=opaque-value; Path=/; Secure; HttpOnly; SameSite=Lax

localStorage ve sessionStorage JavaScript tarafından okunur; hassas oturum token'larını XSS'e açık depolamaya koymak riski büyütebilir. Büyük/yapısal istemci verisi için IndexedDB daha uygundur.

Sunucu session'ı cookie ile aynı şey değildir: cookie çoğu zaman yalnız session kimliğini taşır; asıl durum sunucuda tutulabilir.

3.5. Kimlik Doğrulama ve Yetkilendirme

Authentication "kim?", authorization "ne yapabilir?" sorusudur. Oturum cookie'si, bearer token, OAuth/OIDC veya passkey gibi mekanizmalar farklı güven sınırları oluşturur.

Her endpoint sunucu tarafında authorization yapmalıdır. UI'da butonu gizlemek erişim kontrolü değildir.

Yetki nesne seviyesinde de değerlendirilmelidir. Kullanıcı /api/orders/42 kaynağını tahmin edebiliyorsa yalnız oturum açmış olması o kaydı görmeye yetmemelidir.

3.6. CSRF, XSS ve İnjection

CSRF, tarayıcının otomatik credential gönderme davranışını kötüye kullanabilir. SameSite cookie politikası riski azaltabilir fakat mimariye göre CSRF token/Origin kontrolü gibi ek mekanizmalar gerekebilir.

XSS, güvenilmeyen verinin çalıştırılabilir HTML/JavaScript bağlamına girmesidir. Savunma bağlama uygun output encoding, güvenli DOM API'leri, template auto-escaping ve CSP katmanlarının birlikte kullanımıdır.

SQL/command/template injection ise veriyi komut veya kodla birleştirme problemidir. Parametreli sorgular ve güvenli API'ler temel kontroldür.

3.7. Content Security Policy

CSP, sayfanın hangi kaynakları yükleyip çalıştırabileceğini sınırlayarak XSS etkisini azaltan ek bir savunma katmanıdır.

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

CSP, output encoding veya güvenli kodun yerine geçmez. Inline script bağımlılığı ve geniş wildcard politikaları korumayı zayıflatır. Raporlama modları üretime geçişte politika ihlallerini gözlemlemek için kullanılabilir.

3.8. HTTPS ve Oturum Bağlamını Ayırmak

HTTPS, istemci ile sunucu arasındaki kanalı korurken tarayıcının oturum belirtecinin çalınmasını, istemci tarafında XSS oluşmasını veya uygulamanın hatalı yetkilendirme kararını tek başına önlemez. Güvenli bir oturumun kurulmasında sunucu kimliği TLS sertifikasıyla doğrulanır, oturum tanıtıcısı kriptografik rastgelelikle oluşturulur ve çerez politikası Secure, HttpOnly, SameSite ve uygun Path/Domain kapsamıyla yapılandırılır. Yetkilendirme her istekte sunucu tarafında yeniden uygulanır.

CSRF önlemi ile TLS şifrelemesi farklı tehditleri ele alır. Oturum yenileme, çıkış, süre aşımı ve kimlik düzeyi yükseltilmesi test edildiğinde tekrar oynatma ve oturum sabitleme riskleri görünür hale gelir. TLS 1.3 anahtar türetme ayrıntısı Kriptoloji dersindedir; burada web uygulamasının yanlış güven çıkarımları incelenir.

Ünite 4: Web API’leri, Gerçek Zaman ve Yeni Çalışma Modelleri

4.1. OWASP Top 10:2025'i Tasarım Kontrolü Olarak Kullanmak

OWASP Top 10:2025; broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software/data integrity failures, logging-alerting failures ve exceptional condition handling başlıklarını öne çıkarır.

Bu liste otomatik güvenlik standardı değildir; threat model, abuse case, dependency provenance, secret management, input/output sınırları ve güvenli hata davranışıyla birlikte kullanılmalıdır.

4.2. REST, Kaynak Modeli ve JSON

REST bir JSON formatı değildir. Kaynakları URI'larla tanımlamak, standart HTTP semantiğinden yararlanmak ve önbellek/stateless etkileşimleri doğru modellemek ana fikirdir.

POST /api/devices
Content-Type: application/json

{"serial":"A-1042","enabled":true}

JSON veri değişiminde yaygındır ancak tarih, para, büyük integer, binary veri ve polymorphic payload sözleşmeleri açıkça tanımlanmalıdır. API versioning yalnız URL'e /v1 eklemekten ibaret değildir; backward compatibility politika gerektirir.

4.2.1. Üretilen API Kodunun Sözleşme Denetimi

Ajan tarafından üretilen REST uç noktası yalnız başarılı HTTP yanıtı verdiği için tamamlanmış sayılmaz. Kaynak kimliği, giriş doğrulaması, hata kodları, yetki kontrolü, tekrar çağrı davranışı ve istemcinin beklediği yanıt şeması birlikte sınanır. 200 OK yanıtıyla dönen hatalı JSON veya içerik türü, istemci sözleşmesini bozabilir. Tekrarlanan POST isteğinde idempotency gerekip gerekmediği iş kuralına bağlıdır; yalnız HTTP yöntemi işlemin güvenli olduğunu garanti etmez.

Sözleşme testleri geçersiz istek, yetkisiz erişim, bulunamayan kaynak ve sunucu hatası gibi olumsuz durumları da kapsamalıdır. AçıkAPI gibi bir tanım, belge ve otomatik kontrol için yararlı olsa da gerçek davranışla tutarlılığı ayrıca doğrulanmalıdır. Frontend ve backend değişiklikleri aynı uçtan uca senaryoda sınanmadıkça tek taraflı test sonucu yeterli değildir.

4.3. XML Teknolojisinin Güncel Kullanım Alanları

XML; belge, entegrasyon, imzalı veri, bazı kurumsal protokoller ve yapılandırmalarda hâlâ kullanılır. HTML'in alternatifi değildir. XML namespace, schema, streaming ayrıştırıcı ve canonicalization gibi özellikleri nedeniyle belirli alanlarda güçlüdür.

Tarayıcı içeriği için text/html ana sözdizimidir. WHATWG, HTML'in XML sözdizimini yeni özelliklerin eklenmesinin beklenmemesi ve bakım sorunları nedeniyle yeni içerik için önermemektedir.

4.4. WebSocket, Server-Sent Events ve Gerçek Zamanlı İletişim

Polling her durumda doğru çözüm değildir. Tek yönlü sunucudan istemciye olay akışı için Server-Sent Events, çift yönlü uzun ömürlü bağlantı için WebSocket kullanılabilir.

Gerçek zamanlı kanal seçerken şu maliyetler düşünülmelidir:

• bağlantı sayısı,
• proxy/load-balancer timeout'ları,
• yeniden bağlanma,
• geri basınç,
• mesaj sırası ve tekrarları,
• authentication yenileme,
• yatay ölçeklemede fan-out.

"WebSocket daha hızlıdır" tek başına mimari gerekçe değildir.

4.5. Service Worker ve Progressive Web App Modeli

Service Worker ağ ile sayfa arasında çalışan event-driven bir tarayıcı bileşenidir. Offline önbellek, background davranışları ve özel fetch stratejileri sağlayabilir.

Cache-first stratejisi statik içerikte iyi çalışırken kullanıcıya özgü veya hızla değişen veride eski/yanlış içerik gösterebilir. Service worker önbelleği HTTP önbellekten ayrı bir katmandır; invalidation politikası açık olmalıdır.

4.6. İstemci İsteklerinde Yarış Durumu ve Geçersiz Yanıt

Bir kullanıcı aynı arama alanında art arda A ve B sorgularını çalıştırdığında, A'nın önce başlatılmış olması önce tamamlanacağı anlamına gelmez. A yanıtı B'den sonra ulaşırsa ekranda artık geçerli olmayan sorgunun sonuçları gösterilebilir. Bu durum sunucu verisindeki tutarsızlık değil, istemci durumunun yanıtların varış sırasına bağlanmasıdır.

Her sorguya artan bir kuşak numarası verildiğinde yanıt ancak kendi kuşağı güncel ise arayüze uygulanır. AbortController, artık gerekmeyen fetch çağrılarının iptali için kullanılabilir; ancak iptal, sunucunun işlemi kesinlikle durdurduğu veya yan etkilerin geri alındığı anlamına gelmez. Bu nedenle kuşak kontrolü, iptal işleminden bağımsız bir doğruluk koşuludur. finally bloğunda yükleme durumunu temizlerken bile eski kuşağın yeni isteğin göstergesini söndürmediği doğrulanır.

Arama alanı, seçili kayıt ve ayrıntı paneli aynı sorgu bağlamını paylaşmalıdır. Liste B sorgusuna aitken ayrıntı A'nın kaydını göstermeye devam ediyorsa kullanıcı birbiriyle ilgisiz kanıtları birlikte yorumlayabilir. Bu nedenle sorgu kimliği, sonuç, yükleme göstergesi, hata durumu ve seçim bir yaşam döngüsü altında yönetilir. Gizlenen sekmelerde ölçüm ve çizim döngülerinin durması, yalnız performans değil, eski bağlamın görünür hâle dönünce yeniden yazılmasını engelleme meselesidir.

Ünite 5: Önbellek, Performans, Medya ve Sunucu Tarafı

5.1. WebAssembly'nin Yeri

WebAssembly 3.0; güvenli, taşınabilir ve düşük seviyeli bir kod formatıdır. Tarayıcıda yüksek hesaplama yoğunluklu modüller, codec, simülasyon veya başka dillerdeki kütüphaneler için kullanılabilir; JavaScript'in veya DOM'un genel amaçlı yerine geçen bir dil değildir.

Wasm modülü web API'lerine doğrudan sınırsız erişmez; host tarafından verilen import'larla etkileşir. Bu sandbox sınırı güvenlik modelinin parçasıdır.

5.2. Önbellekleme ve Koşullu İstekler

Web performansının en düşük maliyetli optimizasyonlarından biri gereksiz veri transferini önlemektir. Cache-Control, ETag, Last-Modified, If-None-Match ve Vary doğru kullanıldığında tarayıcı ve ara önbellekler tekrar kullanabilir.

tarayıcı önbelleği
      |
      v
CDN / edge önbelleği
      |
      v
reverse proxy önbelleği
      |
      v
uygulama önbelleği
      |
      v
veritabanı / kaynak sistem

TTL / ETag / Last-Modified -> tazelik kararı

Hash içeren immutable statik dosyada uzun önbellek süresi mantıklıdır:

Cache-Control: public, max-age=31536000, immutable

Aynı yaklaşımı kullanıcıya özgü HTML veya authorization'a bağlı API cevabına körlemesine uygulamak veri sızıntısı oluşturabilir.

İki seviyeli cache için isabet sırası bir API sözleşmesidir. İki cache yöneticisinin sırayla kaydedilmesi, ilk önbellekte anahtar bulunmadığında otomatik olarak ikinci önbellekten değer okunduğu anlamına gelmez. Örneğin bir cache-manager bileşimi önce ilgili cache nesnesini bulur; anahtar bazındaki L1 miss ve L2 fallback davranışı uygulama veya özel bir cache gerçeklenimi tarafından tasarlanmalıdır. L2'de bulunan değerin L1'e taşınması, negative caching, TTL uyuşmazlığı ve invalidation sırası ayrıca tanımlanmalıdır.

HTTP ETag veya Last-Modified ile koşullu yanıt, sunucu içi verinin tutarlı olduğunu kendiliğinden garanti etmez. Kimliğe veya yetkiye bağlı cevapların yanlış cache key ile paylaşılması performans değil veri sızıntısı doğurur. Testlerde bir kullanıcının kaydını diğer kullanıcının görmemesi, güncellemeden sonra stale içeriğin kabul edilen süreyi aşmaması ve koşullu isteğin doğru temsil sürümünü doğrulaması birlikte ele alınmalıdır.

5.3. Performans: Ağ, Ana İş Parçacığı ve Rendering Birlikte Ölçülür

Web gecikmesi yalnız backend süresi değildir. DNS, TCP/QUIC/TLS kurulumu, server think time, payload büyüklüğü, parsing, JavaScript yürütme, style/layout ve paint kullanıcı algısını etkiler.

İyi optimizasyon sırası genellikle ölçümle başlar:

• gereksiz ağ çağrısını kaldır,
• payload ve image boyutunu azalt,
• önbelleği düzelt,
• blocking script/style yolunu azalt,
• uzun main-iş parçacığı task'larını parçala,
• DOM boyutunu ve layout thrashing'i kontrol et.

Mikro-optimizasyon, ölçülmemiş network waterfall veya büyük görsel maliyetini telafi etmez.

Yanıtın hızlı gelmesi arayüzün hızlı olduğu anlamına gelmez. Sunucu TTFB süresi iyileşirken istemcinin JSON ayrıştırma, DOM güncelleme veya ana iş parçacığında uzun görev yürütme maliyeti sabit kalabilir. Tersine büyük yanıtı sıkıştırmak ağdan aktarılan byte sayısını azaltırken hem sunucuda hem tarayıcıda CPU tüketimini artırabilir. Dolayısıyla uçtan uca deneyde TTFB, transfer süresi, PerformanceObserver ile uygun uzun görev gözlemleri ve kullanıcı eyleminden kullanılabilir arayüze kadar geçen süre ayrı kaydedilmelidir.

Bir REST endpoint'i yeni JSON serileştirme ayarıyla test ediliyorsa sonuç bütünlüğü, alan adları, karakter kodlaması ve sayısal hassasiyet regresyon testinden geçmelidir. Daha küçük payload yalnız doğru bilginin korunması şartıyla kazanımdır. İstemcinin önbellek durumunu ve ağ profilini açıkça belirtmeden masaüstü yerel ağ sonucunu mobil bağlantı deneyimi yerine sunmak genellenebilir bir kanıt değildir.

5.4. Görsel Varlıklar ve Medya

Modern web'de görsel format seçimi içeriğe bağlıdır. Responsive image için srcset ve sizes, lazy loading için loading="lazy" uygun yerlerde kullanılabilir.

<img
  src="/img/device-800.webp"
  srcset="/img/device-400.webp 400w, /img/device-800.webp 800w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800"
  height="450"
  alt="Cihaz telemetri paneli">

width/height oranının verilmesi layout shift'i azaltır. Kritik üst bölüm görselini indiscriminately lazy-load etmek ise ters etki yapabilir.

5.5. Sunucu Tarafı Programlama: Framework'ten Bağımsız Model

Sunucu tarafında dil değişse de ana sorumluluklar benzerdir:

request parsing
-> authentication/authorization
-> validation
-> domain logic
-> transaction / external calls
-> response mapping

Java/Spring Boot, C#/.NET, Go, Python, PHP, JavaScript/Node.js ve başka platformlar bu akışı farklı API'lerle uygular.

Framework'ün request/session nesnelerini domain katmanına taşımak uzun vadeli bağımlılığı artırır. HTTP katmanı ile iş kuralı ayrılmalıdır.

5.6. CGI, Klasik ASP ve Web Forms Teknolojilerinin Tarihsel Dersleri

CGI, klasik ASP, VBScript ve ASP.NET Web Forms güncel genel web geliştirme varsayılanı değildir; ancak web'in evrimini anlamak açısından önemlidir.

CGI her istek için süreç/program çağırma modelinin maliyetlerini görünür hale getirdi. Klasik ASP sunucu tarafı script yaklaşımını yaygınlaştırdı. Web Forms, masaüstü olay modelini ViewState, server controls ve postback ile web'in stateless HTTP yapısı üzerinde emüle etmeye çalıştı.

Bugünkü server-rendered framework'ler ve API tabanlı uygulamalar HTTP semantiğini daha doğrudan görünür kılar. Eski Request, Response, Session, form GET/POST ve XML konuları ise kavramsal olarak yaşamaya devam eder.

5.7. jQuery, VBScript, Flash ve Eski Editörler

jQuery'nin selector, DOM normalization, AJAX ve event API'leri tarayıcılar arası farkların büyük olduğu dönemde önemliydi. Modern DOM, querySelector, fetch, classList ve standart event API'leri birçok temel kullanımda harici bağımlılık gereksinimini azalttı. jQuery mevcut sistemlerde hâlâ kullanılabilir; yeni projede gereksinim bazlı değerlendirilmelidir.

Tarayıcı VBScript'i modern platform standardı değildir. Flash plugin modeli de modern web platformundan çıkarılmıştır. Bu teknolojiler yalnız tarihsel migration bağlamında anlatılmalıdır.

FrontPage, HomeSite, Visual InterDev gibi editör adları kalıcı web bilgisi değildir. Güncel ders açısından önemli olan editor değil; standards-compliant çıktı, version control, build pipeline, test ve dağıtım sürecidir.

5.8. E-posta, FTP ve Telnet'in Web Bağlamındaki Yeri

SMTP, IMAP ve POP e-posta protokolleridir; web protokolleri değildir. Web uygulaması e-posta gönderdiğinde çoğu zaman bir SMTP servisine veya HTTP tabanlı mail API'sine bağlanır.

FTP dosya aktarımı için tarihsel olarak yaygındır; credential ve transport gereksinimine göre SFTP/SSH veya HTTPS tabanlı dağıtım mekanizmaları tercih edilir. Telnet şifrelenmemiş uzak terminal/protokol test aracı olarak güvenli yönetim kanalı değildir; SSH onun genel güvenli operasyonel karşılığıdır.

Bu protokollerin adlarını bilmek yerine güvenlik ve taşıma özelliklerini anlamak daha kalıcı bilgidir.

5.9. Sunucu Çalışma Zamanında Yerel Uzantı ve Ayrıştırıcı Güvenliği

Sunucu tarafında kullanılan programlama dili bellek yönetimi sağlasa da dosya yükleme, sıkıştırma, görsel çözümleme ve ağ protokolü ayrıştırma süreçleri yerel kod bağımlılıklarına dayanabilir. HTTP istek gövdesi ve çok parçalı form verisi, içerik türü denetiminden başlayarak parser ve dosya sistemi erişimine uzanan bir güven sınırından geçer. Güvenlik tasarımı, yalnız kullanıcının sağladığı dosya uzantısını denetlemekle sınırlı kalmaz; boyut sınırları, içerik çözümlemesi, kaynak tüketimi ve hata yolları birlikte ele alınır.

Yerel kütüphane ve uzantı sürümleri uygulama bağımlılık envanterine dahil edilir. İstek boyutu limitinin varlığı, ayrıştırıcının her ara işleminde aynı bellek sınırının korunduğu anlamına gelmez. Güvenli dağıtım; çalışma zamanı yamaları, asgari yetki, izole geçici dosya alanı, işleme süresi sınırı ve hatalı girdilerle regresyon testlerini içerir.

Ünite 6: Dağıtım, Keşfedilebilirlik, Test ve Üretim Güvenilirliği

6.1. Deployment: Hosting'den Delivery Pipeline'a

Bir web uygulamasını yayımlamak yalnız dosyayı FTP ile sunucuya kopyalamak değildir. Modern dağıtım şu bileşenleri içerebilir:

• artifact/image üretimi,
• immutable sürüm etiketi,
• configuration/secret ayrımı,
• migration sırası,
• health/readiness kontrolü,
• reverse proxy ve TLS,
• DNS/CDN ayarı,
• canary/blue-green veya kontrollü rollout,
• rollback planı.

Statik site, monolith ve dağıtık servis aynı dağıtım stratejisine zorlanmamalıdır.

6.1.1. Ajan Tarafından Üretilen Değişikliğin Dağıtım Sınırı

Web uygulamasında otomatik üretilen kodun derlenmesi, dağıtım için tek başına kabul koşulu değildir. Derleme çıktısı ile kaynağın aynı revizyona ait olduğu, gerekli ortam yapılandırmasının gizli bilgi içermeden yönetildiği ve var olan API tüketicilerinin etkilendiği davranışların sınandığı doğrulanmalıdır. Bağımlılık veya oluşturma aracı sürümünün değişmesi, dağıtılacak paketin kökeninde önemli bir değişikliktir.

Dağıtım öncesinde izin verilen kapsam, kontrol edilen yollar, başarısızlık halinde önceki sürüme dönüş ve kullanıcıya görünen hata davranışı açıkça belirlenir. Otomatik ajan, hazırlık ve testleri hızlandırabilir; nihai yayına alma yetkisi ise sistemin güvenlik ve değişiklik yönetimi politikasına tabidir. İzlenebilir dağıtım, doğrulanmış değişiklik ile dağıtılan eser arasında bağ kurar.

6.2. SEO, Üst Veri ve Makine Tarafından Keşfedilebilirlik

title, meta description, canonical, robots yönergeleri, yapılandırılmış veri ve sitemap; arama motorlarının sayfayı keşfetmesi ve yorumlamasında farklı rollere sahiptir.

meta keywords gibi tarihsel yaklaşımlar modern SEO'nun merkezi değildir. robots yönergesi erişim kontrolü değildir; gizli içeriği arama motorundan saklamaya çalışmak authentication yerine geçmez.

Semantik HTML, gerçek içerik kalitesi, kararlı URL ve doğru HTTP durum kodları teknik SEO'nun temelidir.

6.3. Test Stratejisi

Web testleri katmanlara ayrılmalıdır:

• saf iş mantığı için unit test,
• HTTP sözleşmesi için integration/contract test,
• veri katmanı için gerçekçi integration test,
• browser davranışı için end-to-end test,
• erişilebilirlik için otomatik + manuel kontrol,
• güvenlik için SAST/DAST/dependency ve hedefli testler,
• performans için üretime benzer yük ve tarayıcı profili.

E2E testini her ayrıntı için kullanmak yavaş ve kırılgan suite üretir. En düşük maliyetli katmanda deterministik doğrulama tercih edilmelidir.

6.4. Üretim Güvenilirliği

Tarayıcı ve ağ güvenilmez bileşenlerdir. İstek iptal olabilir, kullanıcı iki kez tıklayabilir, reverse proxy timeout verebilir, cevap gecikmişken retry yapılabilir.

Bu nedenle kritik endpoint'lerde idempotency, timeout, cancellation, bounded retry ve duplicate işleme politikası düşünülmelidir. UI da optimistic update yapıyorsa rollback ve reconciliation davranışı tanımlanmalıdır.

6.5. İlgili Dersler

Web'in sunucu tarafındaki Java uygulaması için Spring Boot, C#/.NET uygulamaları için C# Programlama, dil semantiği için Programlama Dilleri, ağ katmanları için Bilgisayar Ağları, veri kalıcılığı için Veri Tabanı Yönetim Sistemleri ve hukuki sınırlar için Bilişim Hukuku birlikte okunabilir.

6.6. İdempotency, Yeniden Deneme ve HTTP Sınırı

Dağıtık web uygulamasında istemcinin cevap alamaması, sunucunun isteği işlemediği anlamına gelmez. Ağ kopması cevap yoldayken gerçekleşmiş olabilir. Bu nedenle yeniden deneme politikası HTTP yönteminin semantiği ve iş işleminin idempotent olup olmadığıyla birlikte tasarlanmalıdır.

GET, PUT ve DELETE protokol semantiğinde idempotent kabul edilse de uygulama yan etkileri yine dikkat ister. POST ile ödeme veya sipariş oluşturma gibi işlemlerde istemci tarafından üretilen idempotency key, aynı mantıksal komutun tekrarında ikinci yan etkiyi engelleyebilir.

Retry yalnız "3 kez tekrar dene" değildir. Exponential backoff, jitter, toplam son tarih ve hangi hata sınıflarında yeniden deneme yapılacağı belirlenmelidir. Aksi halde çok sayıda istemci aynı anda retry yaparak zaten zorlanan servisi daha fazla yükleyebilir.

6.7. Web Davranışını Uçtan Uca Doğrulamak

Tarayıcı, CDN/proxy, uygulama sunucusu ve veritabanı aynı isteğin farklı bölümlerini etkiler. Bir hata yalnız istemci konsoluna veya yalnız sunucu loguna bakılarak her zaman açıklanamaz; istek kimliği ve zaman çizelgesi katmanları birleştirmeye yardım eder.

HTTP semantiği testte korunmalıdır. Cache header, idempotency, redirect, CORS, cookie niteliği ve içerik türü; yalnız “sayfa açılıyor” kontrolünden daha geniş sözleşmelerdir.

Tarayıcı davranışı sürüme bağlı olabileceği için platform özelliği kullanılırken MDN/WHATWG/W3C gibi birincil veya standart kaynaklar ile destek matrisi birlikte kontrol edilmelidir. Progressive enhancement, desteklenmeyen özellikte temel işlevin korunmasına yardım eder.

6.8. Web Sisteminde Backpressure ve Veri Evrimi

Veri yoğun sistemlerde güvenilirlik, ölçeklenebilirlik ve bakım yapılabilirlik aynı tasarım kararının farklı sonuçlarıdır. Bir web isteğinin veri katmanındaki gecikmesi yalnız endpoint kodundan kaynaklanmaz; indeksleme, veri kodlama ve serialization, connection/transaction sınırı, cache ve replikasyon davranışı ile stream veya pagination stratejisi birlikte değerlendirildiğinde uçtan uca sorgu yolunun neden kırılganlaştığı görülebilir. Özellikle türetilmiş verinin kaynağı, yeniden üretilebilirliği ve gecikme bütçesi açık tanımlanmalıdır.

• API sürümlemesi ile veri şeması evriminin bağımsız ama koordineli yönetilmesi.
• İstek kabul hızının downstream servis kapasitesini aşması halinde bounded queue/load shedding uygulanması.
• Cache invalidation politikasının source-of-truth ve tutarlılık beklentisiyle bağlanması.

Kaynakça

• Brendan Gregg. Systems Performance: Enterprise and the Cloud. Pearson Education, 2014.

• Ecma International, ECMA-262 — ECMAScript 2026 Language Specification. https://ecma-international.org/publications-and-standards/standards/ecma-262/

• Eric, Mihail. The Modern Software Developer (CS146S). Stanford University, course materials, 2025–2026. https://themodernsoftware.dev/

• IETF, RFC 9110 — HTTP Semantics. https://www.rfc-editor.org/rfc/rfc9110

• IETF, RFC 9113 — HTTP/2. https://www.rfc-editor.org/rfc/rfc9113

• IETF, RFC 9114 — HTTP/3. https://www.rfc-editor.org/rfc/rfc9114

• Martin Kleppmann. Designing Data-Intensive Applications. 1st ed. O’Reilly Media, 2016.

• MDN Web Docs, Web platform documentation. https://developer.mozilla.org/

• OWASP, OWASP Top 10:2025. https://top10.owasp.org/2025/

• W3C WebAssembly Working Group, WebAssembly Core Specification 3.0. https://www.w3.org/TR/wasm-core/

• W3C, Content Security Policy Level 3. https://www.w3.org/TR/CSP3/

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/

• WHATWG, Fetch Living Standard. https://fetch.spec.whatwg.org/

• WHATWG, HTML Living Standard. https://html.spec.whatwg.org/
• IETF. RFC 9846, TLS 1.3, 2026. https://www.rfc-editor.org/info/rfc9846