HTTP

Köprü Metni Aktarım Protokolü ⓘ

Uluslararası standart	RFC 1945 HTTP/1.0 (1996) RFC 2068 HTTP/1.1 (1997) RFC 2616 HTTP/1.1 (1999) RFC 7230 HTTP/1.1: Mesaj Sözdizimi ve Yönlendirme (2014) RFC 7231 HTTP/1.1: Anlambilim ve İçerik (2014) RFC 7232 HTTP/1.1: Koşullu İstekler (2014) RFC 7233 HTTP/1.1: Aralık İstekleri (2014) RFC 7234 HTTP/1.1: Önbellekleme (2014) RFC 7235 HTTP/1.1: Kimlik Doğrulama (2014) RFC 7540 HTTP/2 (2015) RFC 7541 HTTP/2: HPACK Başlık Sıkıştırma (2015) RFC 8164 HTTP/2: HTTP/2 için Fırsatçı Güvenlik (2017) RFC 8336 HTTP/2: ORIGIN HTTP/2 Çerçevesi (2018) RFC 8441 HTTP/2: HTTP/2 ile WebSocket'leri Önyükleme (2018) RFC 8740 HTTP/2: HTTP/2 ile TLS 1.3 Kullanımı (2020) RFC 9114 HTTP/3
Tarafından geliştirilmiştir	Başlangıçta CERN; IETF, W3C
Tanıtıldı	1991; 32 yıl önce

Köprü Metni Aktarım Protokolü (HTTP), dağıtılmış, işbirliğine dayalı, hipermedya bilgi sistemleri için İnternet protokol paketi modelinde bir uygulama katmanı protokolüdür. HTTP, hiper metin belgelerinin, kullanıcının örneğin bir fare tıklamasıyla veya bir web tarayıcısında ekrana dokunarak kolayca erişebileceği diğer kaynaklara köprüler içerdiği World Wide Web için veri iletişiminin temelidir. ⓘ

HTTP'nin geliştirilmesi 1989 yılında CERN'de Tim Berners-Lee tarafından başlatılmış ve 0.9 olarak adlandırılan ilk HTTP protokol sürümünü kullanan bir istemci ve sunucunun davranışını açıklayan basit bir belgede özetlenmiştir. ⓘ

HTTP/3, protokolün 2022'de yayınlanan en son sürümüdür; standardizasyon öncesinde web sitelerinin %25'i tarafından zaten kullanılmaktadır. HTTP/3, sunucuda etkinleştirilmişse gerçek dünya web sayfaları için daha düşük gecikme süresine sahiptir, HTTP/2'den daha hızlı yüklenir ve hatta HTTP/1.1'den daha hızlıdır, bazı durumlarda HTTP/1.1'den 3 kat daha hızlıdır (hala yaygın olarak yalnızca etkinleştirilmiştir). Bunun nedeni kısmen TCP'nin (TCP/IP'nin) eski standartlarda olduğu gibi artık kullanılmamasıdır. ⓘ

HTTP protokolünün bu ilk versiyonu çok geçmeden daha ayrıntılı bir versiyona dönüştü ve bu versiyon çok daha ilerideki 1.0 versiyonunun ilk taslağıydı. ⓘ

İlk HTTP Yorum İsteklerinin (RFC'ler) geliştirilmesi birkaç yıl sonra başladı ve İnternet Mühendisliği Görev Gücü (IETF) ve World Wide Web Konsorsiyumu (W3C) tarafından koordine edilen bir çabaydı ve çalışmalar daha sonra IETF'ye taşındı. ⓘ

HTTP/1 1996 yılında son haline getirilmiş ve tam olarak belgelenmiştir (sürüm 1.0 olarak). 1997'de (sürüm 1.1 olarak) geliştirildi ve daha sonra özellikleri 1999'da ve 2014'te güncellendi. ⓘ

HTTPS adlı güvenli varyantı web sitelerinin %79'undan fazlası tarafından kullanılmaktadır. ⓘ

HTTP/2, HTTP semantiğinin "kablo üzerinde" daha verimli bir ifadesidir ve 2015 yılında yayınlanmıştır; web sitelerinin %46'sından fazlası tarafından kullanılmaktadır, şu anda neredeyse tüm web tarayıcıları (kullanıcıların %96'sı) ve TLS 1.2 veya daha yenisinin gerekli olduğu durumlarda Uygulama Katmanı Protokolü Anlaşması (ALPN) uzantısı kullanan Aktarım Katmanı Güvenliği (TLS) üzerinden büyük web sunucuları tarafından desteklenmektedir. ⓘ

HTTP/3, 2022'de yayınlanan HTTP/2'nin halefidir; web sitelerinin %25'i tarafından kullanılmaktadır ve artık birçok web tarayıcısı (kullanıcıların %73'ü) tarafından desteklenmektedir. HTTP/3, temel taşıma protokolü için TCP yerine QUIC kullanır. HTTP/2 gibi, protokolün önceki ana sürümlerini eskitmez. HTTP/3 desteği ilk olarak Cloudflare ve Google Chrome'a eklenmiştir ve Firefox'ta da etkinleştirilmiştir. ⓘ

HTTP'nin logosu ⓘ

Teknik genel bakış

HTTP şeması ve WWW alan adı etiketi ile başlayan URL ⓘ

HTTP, istemci-sunucu modelinde bir istek-yanıt protokolü olarak işlev görür. Örneğin bir web tarayıcısı istemci olabilirken, bir veya daha fazla web sitesini barındıran bir bilgisayarda çalışan ve web sunucusu olarak adlandırılan bir işlem sunucu olabilir. İstemci sunucuya bir HTTP istek mesajı gönderir. HTML dosyaları ve diğer içerikler gibi kaynakları sağlayan veya istemci adına diğer işlevleri yerine getiren sunucu, istemciye bir yanıt mesajı döndürür. Yanıt, istekle ilgili tamamlanma durumu bilgilerini içerir ve mesaj gövdesinde istenen içeriği de içerebilir. ⓘ

Web tarayıcısı bir kullanıcı aracısı (UA) örneğidir. Diğer kullanıcı aracısı türleri arasında arama sağlayıcıları (web tarayıcıları) tarafından kullanılan indeksleme yazılımı, ses tarayıcıları, mobil uygulamalar ve web içeriğine erişen, bunları tüketen veya görüntüleyen diğer yazılımlar yer alır. ⓘ

HTTP, ara ağ öğelerinin istemciler ve sunucular arasındaki iletişimi iyileştirmesine veya etkinleştirmesine izin verecek şekilde tasarlanmıştır. Yüksek trafikli web siteleri genellikle yanıt süresini iyileştirmek için yukarı akış sunucuları adına içerik sağlayan web önbellek sunucularından yararlanır. Web tarayıcıları daha önce erişilen web kaynaklarını önbelleğe alır ve ağ trafiğini azaltmak için mümkün olduğunda bunları yeniden kullanır. Özel ağ sınırlarındaki HTTP proxy sunucuları, mesajları harici sunucularla aktararak küresel olarak yönlendirilebilir bir adresi olmayan istemciler için iletişimi kolaylaştırabilir. ⓘ

Ara HTTP düğümlerinin (vekil sunucular, web önbellekleri, vb.) işlevlerini yerine getirebilmeleri için HTTP başlıklarından bazıları (HTTP isteklerinde/cevaplarında bulunan) hop-by-hop yönetilirken, diğer HTTP başlıkları uçtan uca yönetilir (yalnızca kaynak istemci ve hedef web sunucusu tarafından yönetilir). ⓘ

HTTP, İnternet protokol paketi çerçevesinde tasarlanmış bir uygulama katmanı protokolüdür. Tanımı, altta yatan ve güvenilir bir aktarım katmanı protokolünü varsayar, bu nedenle İletim Kontrol Protokolü (TCP) yaygın olarak kullanılır. Ancak HTTP, örneğin HTTPU ve Basit Hizmet Keşif Protokolü (SSDP) gibi Kullanıcı Datagram Protokolü (UDP) gibi güvenilir olmayan protokolleri kullanmak üzere uyarlanabilir. ⓘ

HTTP kaynakları, http ve https Tekdüzen Kaynak Tanımlayıcıları (URI'ler) şemaları kullanılarak Tekdüzen Kaynak Konum Belirleyicileri (URL'ler) tarafından ağ üzerinde tanımlanır ve bulunur. RFC 3986'da tanımlandığı gibi, URI'ler HTML belgelerinde köprüler olarak kodlanır, böylece birbirine bağlı hiper metin belgeleri oluşturulur. ⓘ

HTTP/1.0'da her kaynak isteği için aynı sunucuya ayrı bir bağlantı yapılır. ⓘ

HTTP/1.1'de bunun yerine bir TCP bağlantısı birden fazla kaynak isteği (yani HTML sayfaları, çerçeveler, resimler, komut dosyaları, stil sayfaları, vb) yapmak için yeniden kullanılabilir. ⓘ

Bu nedenle HTTP/1.1 iletişimlerinde daha az gecikme yaşanır, çünkü TCP bağlantılarının kurulması özellikle yüksek trafik koşullarında önemli bir ek yük oluşturur. ⓘ

HTTP/2, aynı istemci-sunucu modelini ve aynı protokol yöntemlerini korumak için önceki HTTP/1.1'in bir revizyonudur, ancak sırayla bu farklılıklar vardır:

• meta verilerin (HTTP başlıkları) metin yerine sıkıştırılmış ikili gösterimini kullanmak, böylece başlıklar çok daha az yer kaplar;
• erişilen sunucu alanı başına 2 ila 8 TCP/IP bağlantısı yerine tek bir TCP/IP (genellikle şifrelenmiş) bağlantısı kullanmak;
• TCP/IP bağlantısı başına HTTP istek ve yanıtlarının parçalandığı ve HOLB (head of line blocking) sorununu neredeyse çözmek için küçük paketler halinde iletildiği bir veya daha fazla çift yönlü akış kullanmak.
• Sunucu uygulamasının yeni veriler mevcut olduğunda istemcilere veri göndermesine izin vermek için bir itme özelliği eklemek (istemcileri yoklama yöntemlerini kullanarak sunucuya periyodik olarak yeni veri talep etmeye zorlamadan). ⓘ

HTTP/2 iletişimleri bu nedenle HTTP/1.1 iletişimlerinden çok daha az gecikme ve çoğu durumda daha fazla hız elde eder. ⓘ

HTTP/3, TCP/IP bağlantıları yerine QUIC + UDP aktarım protokollerini kullanmak, ayrıca ortalama iletişim hızını biraz iyileştirmek ve tüm akışlarının veri akışını geçici olarak engelleyebilen veya yavaşlatabilen (başka bir "hat başı engelleme" biçimi) TCP/IP bağlantı tıkanıklığı sorununu önlemek için önceki HTTP/2'nin bir revizyonudur. ⓘ

Tarihçe

Tim Berners-Lee ⓘ

Hiper metin terimi 1965 yılında Ted Nelson tarafından Xanadu Projesi'nde ortaya atılmış ve Vannevar Bush'un 1930'larda 1945 tarihli "As We May Think" adlı makalesinde anlattığı mikrofilm tabanlı bilgi erişim ve yönetim sistemi "memex" vizyonundan esinlenilmiştir. Tim Berners-Lee ve CERN'deki ekibi, HTML ve bir web sunucusu ve web tarayıcısı adı verilen bir istemci kullanıcı arayüzü için ilgili teknoloji ile birlikte orijinal HTTP'yi icat etmekle tanınır. Berners-Lee, HTTP'yi başka bir fikrinin benimsenmesine yardımcı olmak için tasarladı: ilk olarak 1989'da önerilen ve şu anda World Wide Web olarak bilinen "WorldWideWeb" projesi. ⓘ

İlk web sunucusu 1990 yılında yayına girdi. Kullanılan protokolün tek bir yöntemi vardı: GET, yani sunucudan bir sayfa talep etmek. Sunucudan gelen yanıt her zaman bir HTML sayfasıydı. ⓘ

HTTP kilometre taşı sürümlerinin özeti

Versiyon	Tanıtıldığı yıl	Mevcut durum ⓘ
HTTP/0.9	1991	Geçersiz
HTTP/1.0	1996	Geçersiz
HTTP/1.1	1997	Standart
HTTP/2	2015	Standart
HTTP/3	2022	Standart

HTTP/0.9

1991 yılında HTTP'nin belgelenmiş ilk resmi sürümü 700 kelimeden daha kısa, düz bir belge olarak yazıldı ve bu sürüm HTTP/0.9 olarak adlandırıldı. HTTP/0.9 sadece GET yöntemini destekliyor, istemcilerin sunucudan sadece HTML belgelerini almasına izin veriyor, ancak diğer dosya formatlarını veya bilgi yüklemeyi desteklemiyordu.

HTTP/1.0-taslak

1992'den bu yana, temel protokolün bir sonraki tam sürümüne doğru evrimini belirtmek için yeni bir belge yazıldı. Hem 0.9 sürümünün basit istek yöntemini hem de istemci HTTP sürümünü içeren tam GET isteğini destekliyordu. Bu, HTTP/1.0 üzerindeki nihai çalışmadan önce gelen birçok resmi olmayan HTTP/1.0 taslağının ilkiydi.

W3C HTTP Çalışma Grubu

HTTP protokolünün yeni özelliklerinin gerekli olduğuna ve bunların resmi RFC'ler olarak tamamen belgelenmesi gerektiğine karar verdikten sonra, 1995'in başlarında HTTP Çalışma Grubu (HTTP WG, Dave Raggett liderliğinde), protokolü genişletilmiş işlemler, genişletilmiş müzakere, daha zengin meta bilgiler, ek yöntemler ve başlık alanları ekleyerek daha verimli hale gelen bir güvenlik protokolüne bağlı olarak standartlaştırmak ve genişletmek amacıyla kuruldu.

HTTP ÇG, protokolün yeni versiyonlarını 1995 yılı içerisinde HTTP/1.0 ve HTTP/1.1 olarak revize etmeyi ve yayınlamayı planladı, ancak birçok revizyon nedeniyle bu zaman çizelgesi bir yıldan çok daha fazla sürdü.

HTTP WG ayrıca HTTP'nin HTTP-NG (HTTP Next Generation) olarak adlandırılan ve önceki sürümlerin performans, düşük gecikmeli yanıtlar vb. ile ilgili kalan tüm sorunlarını çözecek olan uzak gelecekteki bir sürümünü belirlemeyi planladı, ancak bu çalışma yalnızca birkaç yıl sonra başladı ve hiçbir zaman tamamlanmadı.

HTTP/1.0

Mayıs 1996'da RFC 1945, önceki 4 yıl boyunca birçok web tarayıcısı ve web sunucusu tarafından kullanılmış olan standart öncesi HTTP/1.0 taslağının nihai HTTP/1.0 revizyonu olarak yayınlandı.

1996'nın başlarında geliştiriciler, yaklaşmakta olan HTTP/1.1 spesifikasyonlarının taslaklarını kullanarak HTTP/1.0 protokolünün resmi olmayan uzantılarını (örn. keep-alive bağlantıları, vb.) ürünlerine dahil etmeye başladılar.

HTTP/1.1

1996 yılının başlarından itibaren, büyük web tarayıcıları ve web sunucusu geliştiricileri de standart öncesi HTTP/1.1 taslak özellikleri tarafından belirtilen yeni özellikleri uygulamaya başladılar. Tarayıcıların ve sunucuların yeni sürümlerinin son kullanıcılar tarafından benimsenmesi hızlı oldu. Mart 1996'da bir web barındırma şirketi, internette kullanılan tarayıcıların %40'ından fazlasının sanal barındırmayı etkinleştirmek için yeni HTTP/1.1 başlığı "Host "u kullandığını bildirdi. Aynı web barındırma şirketi Haziran 1996'da sunucularına erişen tüm tarayıcıların %65'inin standart öncesi HTTP/1.1 uyumlu olduğunu bildirdi.

Ocak 1997'de RFC 2068, HTTP/1.1 spesifikasyonları olarak resmen yayınlandı.

Haziran 1999'da RFC 2616, önceki (eski) HTTP/1.1 spesifikasyonlarına dayanan tüm iyileştirmeleri ve güncellemeleri içerecek şekilde yayınlandı.

W3C HTTP-NG Çalışma Grubu

Önceki HTTP Çalışma Grubunun 1995 yılındaki planını devam ettirerek, 1997 yılında HTTP-NG (HTTP New Generation) adında yeni bir HTTP protokolü geliştirmek için bir HTTP-NG Çalışma Grubu kuruldu. Yeni protokolün tek bir TCP/IP bağlantısı içinde HTTP işlemlerinin çoğullanmasını kullanması için birkaç öneri / taslak üretildi, ancak 1999'da grup teknik sorunları IETF'ye aktararak faaliyetini durdurdu.

IETF HTTP Çalışma Grubu yeniden başlatıldı

2007 yılında, IETF HTTP Çalışma Grubu (HTTP WG bis veya HTTPbis) ilk olarak önceki HTTP/1.1 spesifikasyonlarını revize etmek ve netleştirmek ve ikinci olarak gelecekteki HTTP/2 spesifikasyonlarını (httpbis olarak adlandırılır) yazmak ve iyileştirmek için yeniden başlatıldı. ⓘ

HTTP/1.1 Son Güncelleme

Haziran 2014'te HTTP Çalışma Grubu, RFC 2616'yı yürürlükten kaldıran güncellenmiş altı bölümlü HTTP/1.1 spesifikasyonunu yayınladı:

• RFC 7230, HTTP/1.1: Mesaj Sözdizimi ve Yönlendirme
• RFC 7231, HTTP/1.1: Anlambilim ve İçerik
• RFC 7232, HTTP/1.1: Koşullu İstekler
• RFC 7233, HTTP/1.1: Aralık İstekleri
• RFC 7234, HTTP/1.1: Önbelleğe alma
• RFC 7235, HTTP/1.1: Kimlik Doğrulama

SPDY

Google tarafından geliştirilen resmi olmayan bir HTTP protokolü

2009 yılında özel bir şirket olan Google, SPDY adında yeni bir HTTP ikili protokolü geliştirdiğini ve test ettiğini duyurdu. Örtük amaç web trafiğini büyük ölçüde hızlandırmaktı (özellikle gelecekteki web tarayıcıları ve sunucuları arasında).

SPDY gerçekten de birçok testte HTTP/1.1'den çok daha hızlıydı ve bu nedenle Chromium ve ardından diğer büyük web tarayıcıları tarafından hızla benimsendi.

HTTP akışlarının tek bir TCP/IP bağlantısı üzerinden çoğullanmasıyla ilgili bazı fikirler, W3C HTTP-NG Çalışma Grubu'nun çalışmaları da dahil olmak üzere çeşitli kaynaklardan alınmıştır.

HTTP/2

Ocak-Mart 2012'de HTTP Çalışma Grubu (HTTPbis), belki de SPDY için yapılan fikirleri ve çalışmaları dikkate alarak yeni bir HTTP/2 protokolüne (HTTP/1.1 spesifikasyonlarının revizyonunu bitirirken) odaklanmaya başlama ihtiyacını duyurdu.

HTTP'nin yeni bir sürümünü geliştirmek için ne yapılması gerektiği konusunda birkaç ay tartışıldıktan sonra, bunun SPDY'den türetilmesine karar verildi.

Mayıs 2015'te HTTP/2, RFC 7540 olarak yayınlandı ve SPDY'yi zaten destekleyen tüm web tarayıcıları tarafından hızla ve web sunucuları tarafından daha yavaş bir şekilde benimsendi. ⓘ

HTTP/0.9 Kullanımdan Kaldırma

RFC 7230 Ek-A'da HTTP/0.9, HTTP/1.1 sürümünü (ve daha üstünü) destekleyen sunucular için kullanımdan kaldırılmıştır:

HTTP/0.9 bir istekte başlık alanlarını desteklemediğinden, isme dayalı sanal konakları (Host başlık alanının incelenmesiyle kaynak seçimi) desteklemesi için bir mekanizma yoktur. İsim tabanlı sanal konakları uygulayan herhangi bir sunucu HTTP/0.9 desteğini devre dışı bırakmalıdır. HTTP/0.9 gibi görünen çoğu istek, aslında istemcinin istek-hedefini düzgün bir şekilde kodlayamamasından kaynaklanan kötü yapılandırılmış HTTP/1.x istekleridir.

2016'dan bu yana birçok ürün yöneticisi ve kullanıcı aracıları (tarayıcılar vb.) ve web sunucuları geliştiricileri, temel olarak aşağıdaki nedenlerden dolayı HTTP/0.9 protokolünü kademeli olarak kullanımdan kaldırmayı ve desteğini kesmeyi planlamaya başlamıştır:

• o kadar basittir ki hiçbir zaman bir RFC belgesi yazılmamıştır (sadece orijinal belge vardır);
• HTTP başlıkları yoktur ve günümüzde asgari güvenlik nedenleriyle gerekli olan diğer birçok özellikten yoksundur;
• 1999/2000'den beri yaygın değildir (HTTP/1.0 ve HTTP/1.1 nedeniyle) ve yalnızca bazı çok eski ağ donanımları, yani yönlendiriciler vb. tarafından yaygın olarak kullanılmaktadır. ⓘ

HTTP/3

2020 yılında, HTTP/3 ilk taslakları yayınlandı ve büyük web tarayıcıları ve web sunucuları bunu benimsemeye başladı.

6 Haziran 2022'de IETF, HTTP/3'ü RFC 9114 olarak standartlaştırdı. ⓘ

Genel güncellemeler ve yeniden düzenleme

Haziran 2022'de, önceki belgelerin çoğunu kullanımdan kaldıran ve birkaç küçük değişiklik getiren ve HTTP semantiği açıklamasını ayrı bir belgeye yeniden düzenleyen bir RFC grubu yayınlandı.

• RFC 9110, HTTP Anlambilimi
• RFC 9111, HTTP Önbelleğe Alma
• RFC 9112, HTTP/1.1
• RFC 9113, HTTP/2
• RFC 9114, HTTP/3 (ayrıca yukarıdaki bölüme bakın)
• RFC 9204, QPACK: HTTP/3 için Alan Sıkıştırma
• RFC 9218, HTTP için Genişletilebilir Önceliklendirme Şeması ⓘ

HTTP veri alışverişi

HTTP durum bilgisi olmayan uygulama düzeyinde bir protokoldür ve istemci ile sunucu arasında veri alışverişi için güvenilir bir ağ aktarım bağlantısı gerektirir. HTTP uygulamalarında, TCP/IP bağlantıları iyi bilinen bağlantı noktaları kullanılarak kullanılır (bağlantı şifrelenmemişse tipik olarak bağlantı noktası 80 veya bağlantı şifrelenmişse bağlantı noktası 443, ayrıca TCP ve UDP bağlantı noktası numaraları listesine bakın). HTTP/2'de, bir TCP/IP bağlantısı artı çoklu protokol kanalları kullanılır. HTTP/3'te, UDP üzerinden uygulama aktarım protokolü QUIC kullanılır. ⓘ

Bağlantılar üzerinden istek ve yanıt mesajları

Veri alışverişi, bir oturum katmanı aktarım bağlantısı tarafından değiştirilen bir dizi istek-yanıt mesajı aracılığıyla gerçekleştirilir. Bir HTTP istemcisi başlangıçta bir bağlantı kurarak (gerçek veya sanal) bir sunucuya bağlanmaya çalışır. Bu bağlantı noktasını dinleyen bir HTTP(S) sunucusu bağlantıyı kabul eder ve ardından bir istemcinin istek mesajını bekler. İstemci isteğini sunucuya gönderir. İsteği aldıktan sonra, sunucu bir HTTP yanıt mesajı (başlık artı gerekliyse bir gövde) gönderir. Bu mesajın gövdesi genellikle istenen kaynaktır, ancak bir hata mesajı veya başka bilgiler de döndürülebilir. Herhangi bir zamanda (birçok nedenden dolayı) istemci veya sunucu bağlantıyı kapatabilir. Bir bağlantının kapatılması genellikle sunucuya veya istemciye gönderilen son istek/yanıt mesajında bir veya daha fazla HTTP başlığı kullanılarak önceden bildirilir. ⓘ

Kalıcı bağlantılar

HTTP/0.9'da, TCP/IP bağlantısı her zaman sunucu yanıtı gönderildikten sonra kapatılır, bu nedenle hiçbir zaman kalıcı değildir. ⓘ

HTTP/1.0'da, RFC 1945'te belirtildiği gibi, TCP/IP bağlantısı her zaman bir yanıt gönderildikten sonra sunucu tarafından kapatılmalıdır. ⓘ

HTTP/1.1'de bir bağlantının birden fazla istek/cevap için yeniden kullanılabilmesi için bir canlı tutma mekanizması resmi olarak tanıtılmıştır. Bu tür kalıcı bağlantılar, ilk istek gönderildikten sonra istemcinin TCP 3-Way-Handshake bağlantısını yeniden müzakere etmesi gerekmediğinden istek gecikmesini hissedilir derecede azaltır. Bir başka olumlu yan etki de, TCP'nin yavaş başlatma mekanizması nedeniyle genel olarak bağlantının zamanla daha hızlı hale gelmesidir. ⓘ

HTTP/1.1, istemcilerin her bir yanıtı beklemeden önce birden fazla istek göndermesine izin vererek kalıcı bağlantıları kullanırken gecikme süresini daha da azaltmak için HTTP pipelining özelliğini de ekledi. Bu optimizasyon hiçbir zaman gerçekten güvenli olarak görülmedi çünkü birkaç web sunucusu ve birçok proxy sunucusu, özellikle istemciler ve sunucular arasında İnternet / Intranet'lere yerleştirilen şeffaf proxy sunucuları, ardışık istekleri düzgün bir şekilde işlemedi (diğerlerini atarak yalnızca ilk isteği sundular, ilk istekten sonra daha fazla veri gördükleri için bağlantıyı kapattılar veya hatta bazı proxy'ler yanıtları sıra dışı olarak döndürdüler vb.) Bunun yanı sıra, yalnızca HEAD ve bazı GET istekleri (yani gerçek dosya istekleri ile sınırlıdır ve bu nedenle komut olarak kullanılan sorgu dizesi olmayan URL'ler vb. Ardışık sıralamayı etkinleştirmenin getirdiği sorunlarla uzun yıllar mücadele ettikten sonra, bu özellik önce devre dışı bırakıldı ve ardından HTTP/2'nin duyurulan benimsenmesi nedeniyle çoğu tarayıcıdan kaldırıldı. ⓘ

HTTP/2, tek bir TCP/IP bağlantısı üzerinden çok sayıda eş zamanlı istek/cevabı çoğullayarak kalıcı bağlantıların kullanımını genişletmiştir. ⓘ

HTTP/3 TCP/IP bağlantılarını değil QUIC + UDP'yi kullanır (ayrıca bkz: teknik genel bakış). ⓘ

İçerik alma optimizasyonları

HTTP/0.9

istenen bir kaynak her zaman tamamen gönderilirdi.

HTTP/1.0

HTTP/1.0, koşullu GET isteklerine izin vermek amacıyla istemci tarafından önbelleğe alınan kaynakları yönetmek için başlıklar ekledi; pratikte bir sunucu, yalnızca son değiştirilme zamanı istemci tarafından bilinmiyorsa veya GET isteğine verilen son tam yanıttan bu yana değişmişse, istenen kaynağın tüm içeriğini döndürmek zorundadır. Bu başlıklardan biri olan "Content-Encoding", bir kaynağın döndürülen içeriğinin sıkıştırılmış olup olmadığını belirtmek için eklenmiştir.

Bir kaynağın içeriğinin toplam uzunluğu önceden bilinmiyorsa (örneğin, dinamik olarak oluşturulduğu için vb.), HTTP başlıklarında "Content-Length: number" başlığı bulunmuyordu ve istemci, sunucu bağlantıyı kapattığında içeriğin tamamen gönderildiğini varsayıyordu. Bu mekanizma, başarıyla tamamlanan bir kaynak aktarımı ile kesintiye uğrayan bir kaynak aktarımı (sunucu / ağ hatası veya başka bir şey nedeniyle) arasında ayrım yapamıyordu.

HTTP/1.1

HTTP/1.1 tanıtıldı:

• Önbelleğe alınan kaynakların koşullu olarak alınmasını daha iyi yönetmek için yeni başlıklar.
• Sunucu içeriğin uzunluğunu önceden bilmese bile (yani dinamik olarak oluşturulduğu için vb.) güvenilir bir şekilde göndermek için içeriğin parçalar halinde akışına izin veren parçalı aktarım kodlaması.
• İstemcinin bir kaynağın yalnızca bir veya daha fazla bölümünü (bayt aralıkları) talep edebildiği (yani ilk bölüm, tüm içeriğin ortasında veya sonunda bir bölüm, vb.) ve sunucunun genellikle yalnızca istenen bölümleri gönderdiği bayt aralığı sunumu. Bu, kesintiye uğramış bir indirmeyi devam ettirmek (bir dosya gerçekten büyük olduğunda), bir içeriğin yalnızca bir kısmının gösterilmesi veya bir tarayıcı tarafından zaten görünür olan kısma dinamik olarak eklenmesi gerektiğinde (yani, bir web sayfasının yalnızca ilk veya sonraki n yorumu) zaman, bant genişliği ve sistem kaynaklarından tasarruf etmek için kullanışlıdır.

HTTP/2, HTTP/3

Hem HTTP/2 hem de HTTP/3, HTTP/1.1'in yukarıda belirtilen özelliklerini korumuştur. ⓘ

HTTP kimlik doğrulaması

HTTP, temel erişim kimlik doğrulaması ve özet erişim kimlik doğrulaması gibi, sunucunun istenen içeriği sunmadan önce bir meydan okuma tanımladığı ve yayınladığı bir meydan okuma-yanıt mekanizması aracılığıyla çalışan çoklu kimlik doğrulama şemaları sağlar. ⓘ

HTTP, bir sunucu tarafından bir istemci isteğine meydan okumak ve bir istemci tarafından kimlik doğrulama bilgilerini sağlamak için kullanılabilen genişletilebilir bir meydan okuma-yanıt kimlik doğrulama şemaları kümesi aracılığıyla erişim kontrolü ve kimlik doğrulama için genel bir çerçeve sağlar. ⓘ

Yukarıdaki mekanizma HTTP protokolüne aittir ve genellikle bir web uygulaması oturumu kullanan web uygulaması tarafından değil, istemci ve sunucu HTTP yazılımı (istemcinin bir veya daha fazla web kaynağına erişimine izin vermeden önce kimlik doğrulaması gerektirecek şekilde yapılandırılmışsa) tarafından yönetilir. ⓘ

Kimlik doğrulama alanları

HTTP Kimlik Doğrulama belirtimi ayrıca, belirli bir kök URI için ortak olan kaynakları daha da bölmek için isteğe bağlı, uygulamaya özel bir yapı sağlar. Realm değer dizesi, mevcutsa, meydan okumanın koruma alanı bileşenini oluşturmak için kanonik kök URI ile birleştirilir. Bu, sunucunun tek bir kök URI altında ayrı kimlik doğrulama kapsamları tanımlamasına olanak tanır. ⓘ

HTTP uygulama oturumu

HTTP durum bilgisi olmayan bir protokoldür. Durumsuz bir protokol, web sunucusunun birden fazla istek süresince her kullanıcı hakkında bilgi veya durum tutmasını gerektirmez. ⓘ

Bazı web uygulamalarının kullanıcı oturumlarını yönetmesi gerekir, bu nedenle örneğin HTTP çerezlerini veya web formlarındaki gizli değişkenleri kullanarak durumları veya sunucu tarafı oturumlarını uygularlar. ⓘ

Bir uygulama kullanıcı oturumunu başlatmak için, web uygulaması oturum açma yoluyla etkileşimli bir kimlik doğrulama gerçekleştirilmelidir. Bir kullanıcı oturumunu durdurmak için kullanıcı tarafından bir logout işlemi talep edilmelidir. Bu tür işlemler HTTP kimlik doğrulamasını değil, özel olarak yönetilen bir web uygulaması kimlik doğrulamasını kullanır. ⓘ

HTTP/1.1 istek mesajları

İstek mesajları bir istemci tarafından bir hedef sunucuya gönderilir. ⓘ

İstek sözdizimi

Bir istemci sunucuya istek mesajları gönderir ve bu mesajlar şunlardan oluşur:

• büyük/küçük harfe duyarlı istek yöntemi, bir boşluk, istenen URL, başka bir boşluk, protokol sürümü, satır başı ve satır beslemesinden oluşan bir istek satırı, örn:

GET /images/logo.png HTTP/1.1

• sıfır veya daha fazla istek başlığı alanı (HTTP/1.1 durumunda en az 1 veya daha fazla başlık), her biri büyük/küçük harfe duyarlı olmayan alan adı, iki nokta üst üste, isteğe bağlı baştaki boşluk, alan değeri, isteğe bağlı sondaki boşluktan oluşur ve satır başı ve satır beslemesiyle biter, örn:

Ana bilgisayar: www.example.com
Accept-Language: tr

• satır başı ve satır beslemesinden oluşan boş bir satır;
• isteğe bağlı bir mesaj gövdesi. ⓘ

HTTP/1.1 protokolünde, Host: ana bilgisayar adı dışındaki tüm başlık alanları isteğe bağlıdır. ⓘ

RFC 1945'teki HTTP/1.0 spesifikasyonundan önceki HTTP istemcileriyle uyumluluğu korumak için sunucular tarafından yalnızca yol adını içeren bir istek satırı kabul edilir. ⓘ

Talep yöntemleri

Telnet kullanılarak yapılan bir HTTP/1.1 isteği. İstek mesajı, yanıt başlığı bölümü ve yanıt gövdesi vurgulanmıştır. ⓘ

HTTP, tanımlanan kaynak üzerinde gerçekleştirilmesi istenen eylemi belirtmek için yöntemler (bazen fiil olarak adlandırılır, ancak spesifikasyonun hiçbir yerinde fiilden bahsedilmez) tanımlar. Bu kaynağın neyi temsil ettiği, önceden var olan veri mi yoksa dinamik olarak oluşturulan veri mi olduğu, sunucunun uygulamasına bağlıdır. Genellikle, kaynak bir dosyaya veya sunucuda bulunan bir yürütülebilir dosyanın çıktısına karşılık gelir. HTTP/1.0 spesifikasyonu GET, HEAD ve POST yöntemlerini tanımlamış ve HTTP/1.1 spesifikasyonu beş yeni yöntem eklemiştir: PUT, DELETE, CONNECT, OPTIONS ve TRACE. Herhangi bir istemci herhangi bir yöntemi kullanabilir ve sunucu herhangi bir yöntem kombinasyonunu destekleyecek şekilde yapılandırılabilir. Bir yöntem bir aracı tarafından bilinmiyorsa, güvenli olmayan ve örnek olmayan bir yöntem olarak ele alınacaktır. Tanımlanabilecek yöntem sayısında bir sınırlama yoktur, bu da mevcut altyapıyı bozmadan gelecekteki yöntemlerin belirlenmesine olanak tanır. Örneğin, WebDAV yedi yeni yöntem tanımlamış ve RFC 5789 PATCH yöntemini belirtmiştir. ⓘ

Yöntem adları büyük/küçük harfe duyarlıdır. Bu, büyük/küçük harfe duyarlı olmayan HTTP başlık alanı adlarının tersidir. ⓘ

GET

GET yöntemi, hedef kaynağın durumunun bir temsilini aktarmasını ister. GET istekleri yalnızca veri almalı ve başka hiçbir etkiye sahip olmamalıdır. (Bu, diğer bazı HTTP yöntemleri için de geçerlidir.) Değişiklik yapmadan kaynakları almak için, bir URL aracılığıyla adreslenebildiklerinden GET, POST'a tercih edilir. Bu, yer imlerine ekleme ve paylaşmayı mümkün kılar ve GET yanıtlarını bant genişliğinden tasarruf edebilecek şekilde önbelleğe almaya uygun hale getirir. W3C bu ayrımla ilgili rehber ilkeler yayınlamış ve "Web uygulama tasarımı yukarıdaki ilkelerin yanı sıra ilgili sınırlamalar tarafından da bilgilendirilmelidir" demiştir. Aşağıdaki güvenli yöntemlere bakın. ⓘ

KAFA

HEAD yöntemi, GET isteğinde olduğu gibi hedef kaynağın durumunun bir temsilini aktarmasını ister, ancak temsil verileri yanıt gövdesinde yer almaz. Bu, tüm temsili aktarmak zorunda kalmadan yanıt başlığındaki temsil meta verilerini almak için kullanışlıdır. Kullanım alanları arasında durum kodu aracılığıyla bir sayfanın kullanılabilir olup olmadığını kontrol etmek ve bir dosyanın boyutunu hızlı bir şekilde bulmak (Content-Length) yer alır. ⓘ

POSTA

POST yöntemi, hedef kaynağın, istekte yer alan gösterimi hedef kaynağın semantiğine göre işlemesini talep eder. Örneğin, bir İnternet forumuna mesaj göndermek, bir posta listesine abone olmak veya çevrimiçi bir alışveriş işlemini tamamlamak için kullanılır. ⓘ

PUT

PUT yöntemi, hedef kaynağın durumunu istekte yer alan temsil tarafından tanımlanan durumla oluşturmasını veya güncellemesini talep eder. POST'tan farkı, istemcinin sunucu üzerindeki hedef konumu belirtmesidir. ⓘ

SİL

DELETE yöntemi, hedef kaynağın durumunu silmesini ister. ⓘ

BAĞLAN

CONNECT yöntemi, aracının istek hedefi tarafından tanımlanan kaynak sunucuya bir TCP/IP tüneli kurmasını ister. Genellikle bir veya daha fazla HTTP proxy'si üzerinden TLS ile bağlantıları güvenli hale getirmek için kullanılır. HTTP CONNECT yöntemine bakın. ⓘ

SEÇENEKLER

OPTIONS yöntemi, hedef kaynağın desteklediği HTTP yöntemlerini aktarmasını ister. Bu, belirli bir kaynak yerine '*' isteyerek bir web sunucusunun işlevselliğini kontrol etmek için kullanılabilir. ⓘ

TRACE

TRACE yöntemi, hedef kaynağın alınan isteği yanıt gövdesinde aktarmasını ister. Bu şekilde bir istemci, aracılar tarafından hangi değişikliklerin veya eklemelerin yapıldığını (varsa) görebilir. ⓘ

YAMA

PATCH yöntemi, hedef kaynağın durumunu istekte yer alan gösterimde tanımlanan kısmi güncellemeye göre değiştirmesini ister. Bu, bir dosyanın veya belgenin tamamını aktarmak zorunda kalmadan bir kısmını güncelleyerek bant genişliğinden tasarruf sağlayabilir. ⓘ

Tüm genel amaçlı web sunucularının en azından GET ve HEAD yöntemlerini uygulaması gerekir ve diğer tüm yöntemler şartname tarafından isteğe bağlı olarak kabul edilir. ⓘ

İstek yöntemlerinin özellikleri ⓘ

Talep yöntemi	RFC	İstek yük gövdesine sahiptir	Yanıtın yük gövdesi vardır	Güvenli	Idempotent	Önbelleklenebilir
GET	RFC 7231	Opsiyonel	Evet	Evet	Evet	Evet
KAFA	RFC 7231	Opsiyonel	Hayır	Evet	Evet	Evet
POSTA	RFC 7231	Evet	Evet	Hayır	Hayır	Evet
PUT	RFC 7231	Evet	Evet	Hayır	Evet	Hayır
SİL	RFC 7231	Opsiyonel	Evet	Hayır	Evet	Hayır
BAĞLAN	RFC 7231	Opsiyonel	Evet	Hayır	Hayır	Hayır
SEÇENEKLER	RFC 7231	Opsiyonel	Evet	Evet	Evet	Hayır
TRACE	RFC 7231	Hayır	Evet	Evet	Evet	Hayır
YAMA	RFC 5789	Evet	Evet	Hayır	Hayır	Hayır

TRACE yöntemi, siteler arası izleme olarak bilinen bir saldırı sınıfının parçası olarak kullanılabilir; bu nedenle, genel güvenlik tavsiyesi, sunucu yapılandırmasında devre dışı bırakılmasıdır. Microsoft IIS, benzer şekilde davranan ve aynı şekilde devre dışı bırakılması önerilen tescilli bir "TRACK" yöntemini destekler. ⓘ

Güvenli yöntemler

Bir istek yöntemi, bu yöntemle yapılan bir isteğin sunucu üzerinde amaçlanan bir etkisi yoksa güvenlidir. GET, HEAD, OPTIONS ve TRACE yöntemleri güvenli olarak tanımlanır. Başka bir deyişle, güvenli yöntemlerin salt okunur olması amaçlanmıştır. Ancak, tanım gereği istemci tarafından talep edilmedikleri için, istek bilgilerinin bir günlük dosyasına eklenmesi veya bir reklam hesabının ücretlendirilmesi gibi yan etkileri hariç tutmazlar. ⓘ

Buna karşılık, POST, PUT, DELETE, CONNECT ve PATCH yöntemleri güvenli değildir. Sunucunun durumunu değiştirebilir veya e-posta göndermek gibi başka etkilere sahip olabilirler. Bu nedenle, bu tür yöntemler genellikle uyumlu web robotları veya web tarayıcıları tarafından kullanılmaz; uyumlu olmayan bazıları, bağlamı veya sonuçları dikkate almadan istekte bulunma eğilimindedir. ⓘ

GET isteklerinin öngörülen güvenliğine rağmen, uygulamada sunucu tarafından ele alınmaları teknik olarak herhangi bir şekilde sınırlandırılmamıştır. Dikkatsiz veya kasıtlı olarak düzensiz programlama, GET isteklerinin sunucuda önemsiz olmayan değişikliklere neden olmasına izin verebilir. Web önbellekleme, arama motorları ve diğer otomatik aracılar sunucuda istenmeyen değişiklikler yaptığında ortaya çıkabilecek sorunlar nedeniyle bu önerilmemektedir. Örneğin, bir web sitesi aşağıdaki gibi bir URL aracılığıyla bir kaynağın silinmesine izin verebilir https://example.com/article/1234/delete</nowiki>Bu, GET kullanılarak bile keyfi olarak getirilirse makaleyi silecektir. Düzgün kodlanmış bir web sitesinde bu işlem için DELETE veya POST yöntemi kullanılması gerekir ki kötü niyetli olmayan botlar bunu yapmaz. ⓘ

Bu durumun uygulamadaki örneklerinden biri, kısa ömürlü Google Web Accelerator beta sürecinde yaşanmış ve kullanıcının görüntülediği sayfadaki rastgele URL'leri önceden yükleyerek kayıtların otomatik olarak değiştirilmesine veya toplu olarak silinmesine neden olmuştur. Beta, yaygın eleştirilerin ardından ilk sürümünden yalnızca birkaç hafta sonra askıya alındı. ⓘ

Idempotent yöntemler

Bir istek yöntemi, bu yöntemle yapılan birden fazla aynı istek, bu tür tek bir istekle aynı etkiye sahipse idempotenttir. PUT ve DELETE yöntemleri ile güvenli yöntemler idempotent olarak tanımlanır. Güvenli yöntemler, sunucu üzerinde hiçbir etkiye sahip olmamaları amaçlandığından önemsiz bir şekilde idempotenttir; bu arada PUT ve DELETE yöntemleri, art arda gelen aynı istekler göz ardı edileceğinden idempotenttir. Örneğin bir web sitesi, bir kullanıcının kayıtlı e-posta adresini değiştirmek için bir PUT uç noktası oluşturabilir. Bu uç nokta doğru yapılandırılmışsa, bir kullanıcının e-posta adresini zaten kayıtlı olan aynı e-posta adresiyle değiştirmek isteyen herhangi bir isteğin (örneğin, başarılı bir isteğin ardından gelen yinelenen isteklerin) hiçbir etkisi olmayacaktır. Benzer şekilde, belirli bir kullanıcıyı SİLME isteği, bu kullanıcı zaten silinmişse hiçbir etkiye sahip olmayacaktır. ⓘ

Buna karşılık, POST, CONNECT ve PATCH yöntemleri mutlaka idempotent değildir ve bu nedenle aynı POST isteğinin birden fazla kez gönderilmesi sunucunun durumunu daha fazla değiştirebilir veya birden fazla e-posta göndermek gibi başka etkilere sahip olabilir. Bazı durumlarda bu istenen etkidir, ancak diğer durumlarda yanlışlıkla meydana gelebilir. Örneğin bir kullanıcı, ilk tıklamanın işleme alındığına dair kendisine net bir geri bildirim verilmemişse, bir düğmeye tekrar tıklayarak yanlışlıkla birden fazla POST isteği gönderebilir. Web tarayıcıları, sayfanın yeniden yüklenmesinin bir POST isteğini yeniden gönderebileceği bazı durumlarda kullanıcıları uyarmak için uyarı iletişim kutuları gösterebilirken, bir POST isteğinin birden fazla kez gönderilmemesi gereken durumları ele almak genellikle web uygulamasına bağlıdır. ⓘ

Bir yöntemin idempotent olup olmadığının protokol veya web sunucusu tarafından zorlanmadığını unutmayın. Bir GET veya başka bir istek tarafından tetiklenen (örneğin) bir veritabanı ekleme veya başka bir idempotent olmayan eylemi içeren bir web uygulaması yazmak tamamen mümkündür. Ancak bunu tavsiyelere aykırı olarak yapmak, bir kullanıcı aracısının aynı isteği tekrarlamanın güvenli olmadığı halde güvenli olduğunu varsayması durumunda istenmeyen sonuçlara yol açabilir. ⓘ

Önbelleğe alınabilir yöntemler

Bir istek yöntemi, bu yöntemle yapılan isteklere verilen yanıtlar gelecekte yeniden kullanılmak üzere saklanabiliyorsa önbelleklenebilirdir. GET, HEAD ve POST yöntemleri önbelleklenebilir olarak tanımlanır. ⓘ

Buna karşılık, PUT, DELETE, CONNECT, OPTIONS, TRACE ve PATCH yöntemleri önbelleğe alınamaz. ⓘ

İstek başlığı alanları

İstek başlığı alanları, istemcinin istek satırının ötesinde ek bilgiler iletmesine olanak tanır ve istek değiştiricileri olarak işlev görür (bir prosedürün parametrelerine benzer şekilde). İstemci hakkında, hedef kaynak hakkında veya isteğin beklenen işlenişi hakkında bilgi verirler. ⓘ

HTTP/1.1 yanıt mesajları

Bir yanıt mesajı, bir sunucu tarafından bir istemciye önceki istek mesajına yanıt olarak gönderilir. ⓘ

Yanıt sözdizimi

Bir sunucu istemciye aşağıdakilerden oluşan yanıt mesajları gönderir:

• protokol sürümü, bir boşluk, yanıt durum kodu, başka bir boşluk, muhtemelen boş bir neden cümlesi, satır başı ve satır beslemesinden oluşan bir durum satırı, örn:

HTTP/1.1 200 TAMAM

• Her biri büyük/küçük harfe duyarlı olmayan alan adı, iki nokta üst üste, isteğe bağlı baştaki boşluk, alan değeri, isteğe bağlı sondaki boşluktan oluşan ve satır başı ve satır besleme ile biten sıfır veya daha fazla yanıt başlığı alanı, örn:

İçerik-Türü: text/html

• satır başı ve satır beslemesinden oluşan boş bir satır;
• isteğe bağlı bir mesaj gövdesi. ⓘ

Yanıt durum kodları

HTTP/1.0 ve sonrasında, HTTP yanıtının ilk satırı durum satırı olarak adlandırılır ve sayısal bir durum kodu ("404" gibi) ve metinsel bir neden ifadesi ("Bulunamadı" gibi) içerir. Yanıt durum kodu, sunucunun istemcinin ilgili isteğini anlama ve karşılama girişiminin sonucunu temsil eden üç basamaklı bir tamsayı kodudur. İstemcinin yanıtı işleme şekli öncelikle durum koduna, ikincil olarak da diğer yanıt başlığı alanlarına bağlıdır. İstemciler tüm kayıtlı durum kodlarını anlamayabilir, ancak sınıflarını (durum kodunun ilk basamağı tarafından verilen) anlamalı ve tanınmayan bir durum kodunu o sınıfın x00 durum koduna eşdeğer olarak değerlendirmelidir. ⓘ

Standart neden ifadeleri yalnızca tavsiye niteliğindedir ve web geliştiricisinin takdirine bağlı olarak "yerel eşdeğerlerle" değiştirilebilir. Durum kodu bir soruna işaret ediyorsa, kullanıcı aracısı sorunun niteliği hakkında daha fazla bilgi sağlamak için kullanıcıya neden ifadesini görüntüleyebilir. Standart ayrıca kullanıcı aracısının neden ifadesini yorumlamaya çalışmasına da izin verir, ancak standart açıkça durum kodlarının makine tarafından okunabilir olduğunu ve neden ifadelerinin insan tarafından okunabilir olduğunu belirttiğinden bu akıllıca olmayabilir. ⓘ

Durum kodunun ilk rakamı sınıfını tanımlar:

1XX (bilgilendirme)

Talep alındı, işleme devam ediliyor. ⓘ

2XX (başarılı)

İstek başarıyla alındı, anlaşıldı ve kabul edildi. ⓘ

3XX (yeniden yönlendirme)

Talebin tamamlanması için daha fazla işlem yapılması gerekmektedir. ⓘ

4XX (istemci hatası)

İstek kötü sözdizimi içeriyor veya yerine getirilemiyor. ⓘ

5XX (sunucu hatası)

Sunucu görünüşte geçerli bir isteği yerine getiremedi. ⓘ

Yanıt başlığı alanları

Yanıt başlığı alanları, sunucunun durum satırının ötesinde yanıt değiştiricileri olarak hareket eden ek bilgiler iletmesine olanak tanır. Sunucu hakkında veya hedef kaynağa ya da ilgili kaynaklara daha fazla erişim hakkında bilgi verirler. ⓘ

Her yanıt başlığı alanının, istek yöntemi veya yanıt durum kodunun semantiği tarafından daha da geliştirilebilen tanımlanmış bir anlamı vardır. ⓘ

HTTP/1.1 istek / yanıt işlemi örneği

Aşağıda, bir HTTP/1.1 istemcisi ile www.example.com, port 80 üzerinde çalışan bir HTTP/1.1 sunucusu arasında gerçekleşen örnek bir HTTP işlemi yer almaktadır. ⓘ

İstemci isteği

GET / HTTP/1.1
Ana bilgisayar: www.example.com
Kullanıcı-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Bağlantı: keep-alive <span title="Kaynak: İngilizce Vikipedi, Bölüm &quot;Client request&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Client_request <span style="color:#dddddd">ⓘ</span>]</span>

ⓘ

Bir istemci isteğini (bu durumda istek satırı ve yalnızca "Host: hostname" başlığına indirgenebilen birkaç başlıktan oluşur) boş bir satır izler, böylece istek, her biri satır başı ve ardından satır beslemesi şeklinde çift satır sonu ile biter. "Host: hostname" başlık değeri, tek bir IP adresini paylaşan çeşitli DNS adları arasında ayrım yaparak ada dayalı sanal barındırmaya olanak tanır. HTTP/1.0'da isteğe bağlı iken, HTTP/1.1'de zorunludur. (Bir "/" (eğik çizgi) genellikle varsa bir /index.html dosyasını getirir.) ⓘ

Sunucu yanıtı

HTTP/1.1 200 TAMAM
Tarih Pzt, 23 Mayıs 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
İçerik-Uzunluğu: 155
Son Değiştirilen: Wed, 08 Jan 2003 23:11:55 GMT
Sunucu: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Kabul aralıkları: bayt
Bağlantı: kapat <span title="Kaynak: İngilizce Vikipedi, Bölüm &quot;Server response&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Server_response <span style="color:#dddddd">ⓘ</span>]</span>

Örnek Bir Sayfa <span title="Kaynak: İngilizce Vikipedi, Bölüm &quot;Server response&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Server_response <span style="color:#dddddd">ⓘ</span>]</span>

Merhaba Dünya, bu çok basit bir HTML belgesidir. <span title="Kaynak: İngilizce Vikipedi, Bölüm &quot;Server response&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Server_response <span style="color:#dddddd">ⓘ</span>]</span>

ⓘ

ETag (varlık etiketi) başlık alanı, istenen kaynağın önbelleğe alınmış bir sürümünün, kaynağın sunucudaki geçerli sürümüyle aynı olup olmadığını belirlemek için kullanılır. "Content-Type" HTTP mesajı tarafından iletilen verilerin İnternet ortam türünü belirtirken, "Content-Length" bayt cinsinden uzunluğunu gösterir. HTTP/1.1 web sunucusu, "Accept-Ranges: bytes" alanını ayarlayarak belgenin belirli bayt aralıkları için isteklere yanıt verme yeteneğini yayınlar. Bu, istemcinin sunucu tarafından gönderilen bir kaynağın yalnızca belirli bölümlerine sahip olması gerekiyorsa kullanışlıdır, buna bayt sunumu denir. "Connection: close" gönderildiğinde, web sunucusunun bu yanıtın aktarımının bitiminden hemen sonra TCP bağlantısını kapatacağı anlamına gelir. ⓘ

Başlık satırlarının çoğu isteğe bağlıdır ancak bazıları zorunludur. Bir varlık gövdesine sahip bir yanıtta "Content-Length: number" başlığı eksik olduğunda, bu HTTP/1.0'da bir hata olarak kabul edilmelidir, ancak "Transfer-Encoding: chunked" başlığı mevcutsa HTTP/1.1'de bir hata olmayabilir. Yığınlanmış aktarım kodlaması, içeriğin sonunu işaretlemek için 0'lık bir yığın boyutu kullanır. HTTP/1.0'ın bazı eski uygulamaları, yanıtın başında gövde varlığının uzunluğu bilinmediğinde "Content-Length" başlığını atlar ve böylece sunucu soketi kapatana kadar istemciye veri aktarımı devam eder. ⓘ

"Content-Encoding: gzip", iletilen verilerin gövde varlık kısmının gzip algoritması ile sıkıştırıldığını istemciye bildirmek için kullanılabilir. ⓘ

Şifrelenmiş bağlantılar

Şifrelenmiş bir HTTP bağlantısı kurmanın en popüler yolu HTTPS'dir. Şifreli HTTP bağlantısı kurmanın diğer iki yöntemi de mevcuttur: Güvenli Köprü Metni Aktarım Protokolü ve TLS'ye yükseltmeyi belirtmek için HTTP/1.1 Yükseltme başlığını kullanmak. Ancak bu ikisi için tarayıcı desteği neredeyse hiç yoktur. ⓘ

Benzer protokoller

• Gopher protokolü, 1990'ların başında HTTP tarafından yerinden edilen bir içerik dağıtım protokolüdür.
• SPDY protokolü, Google'da geliştirilen ve HTTP/2'nin yerini alan HTTP'ye bir alternatiftir.
• Gemini protokolü, gizlilikle ilgili özellikleri zorunlu kılan Gopher'dan esinlenen bir protokoldür. ⓘ