HTTP

HTTP (İngilizce Hyper-Text Transfer Protocol, Türkçe Hiper-Metin Transfer Protokolü) bir kaynaktan dağıtılan ve ortak kullanıma açık olan hiperortam bilgi sistemleri için uygulama seviyesinde bir iletişim protokolüdür.[1] HTTP, World Wide Web için veri iletişiminin temelidir; burada köprü metni belgeleri, örneğin bir fare tıklamasıyla veya bir web tarayıcısında ekrana dokunarak kullanıcının kolayca erişebileceği diğer kaynaklara köprüler içerir.

HTTP'nin logosu
İnternet iletişim kuralları dizisi

OSI modeli

Katman İletişim kuralları
7. Uygulama katmanı HTTP, DNS, SMTP, FTP, TFTP, UUCP, NNTP, SSL, SSH, IRC, SNMP, SIP, RTP, Telnet, ...
6. Sunum katmanı ISO 8822, ISO 8823, ISO 8824, ITU-T T.73, ITU-T X.409, ...
5. Oturum katmanı NFS, SMB, ISO 8326, ISO 8327, ITU-T T.6299, ...
4. Ulaşım katmanı TCP, UDP, SCTP, DCCP, ...
3. Ağ katmanı IP, IPv4, IPv6, ICMP, ARP, İnternet Grup Yönetim Protokolü, IPX,...
2. Veri bağlantısı katmanı Ethernet, HDLC, Wi-Fi, Token ring, FDDI, PPP, L2TP...
1. Donanım katmanı ISDN, RS-232, EIA-422, RS-449, EIA-485, ...

HTTP, 1989'da CERN'de Tim Berners-Lee tarafından geliştirilmeye başlandı. Yorumlara yönelik erken HTTP taleplerinin (RFC'ler) geliştirilmesi, İnternet Mühendisliği Görev Gücü (IETF) ve World Wide Web Consortium (W3C) tarafından koordine edilmiş bir çalışmadır. Daha sonra IETF'e taşınmıştır.

HTTP/1.1 ilk olarak 1997'de RFC 2068'de belgelendi. Bu şartname 1999'da RFC 2616'nın gelmesiyle iptal edildi ve aynı şekilde 2014'te, RFC 7230 ile değiştirildi.

HTTP/2, HTTP'nin "kablolu" semantiğinin daha verimli bir ifadesidir. 2015'te yayınlanmıştır; artık hemen hemen tüm web tarayıcıları[2] ve TLS 1.2 veya daha yenisinin gerekli olduğu bir Uygulama Katmanı Protokol Anlaşması (ALPN) uzantısı[3] kullanan Taşıma Katmanı Güvenliği (TLS) üzerinden büyük web sunucuları tarafından desteklenmektedir.[4]

HTTP/3, HTTP/2'nin[5][6] halihazırda web'de kullanımda olan ve temeldeki aktarım protokolü için TCP yerine UDP kullanan ardılıdır. HTTP/3, Eylül 2019'da Cloudflare ve Google Chrome tarafından desteklenmeye başladı[7][8] (Chrome ve Firefox'un kararlı sürümlerinde etkinleştirilebilir).[9]

Teknik genel bakış

HTTP, istemci-sunucu bilgi işlem modelinde bir istek-yanıt protokolü olarak işlev görür. Örneğin, bir web tarayıcısı istemci olabilir, veya bir web sitesini barındıran bir barındırma hizmetinde çalışan bir uygulama sunucu olabilir. İstemci, sunucuya bir HTTP istek mesajı gönderir. HTML dosyaları ve diğer içerik gibi kaynakları sağlayan, veya istemci adına diğer işlevleri gerçekleştiren sunucu, istemciye bir yanıt mesajı verir. Yanıt, istekle ilgili tamamlanma durumu bilgilerini içerir, ayrıca mesaj gövdesinde istenen içeriği gösterebilir.

HTTP, ara ağ ögelerinin istemciler ve sunucular arasındaki iletişimi iyileştirmesine veya etkinleştirmesine izin vermek için 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ı, önceden erişilen web kaynaklarını önbelleğe alır ve ağ trafiğini azaltmak için mümkün olduğunca bunları yeniden kullanır. Özel ağ sınırlarındaki HTTP vekil sunucuları, mesajları harici sunucularla aktararak, genel olarak yönlendirilebilir bir adrese sahip olmayan istemciler için iletişimi kolaylaştırabilir.

HTTP, İnternet iletişim kuralları dizisi paketi çerçevesinde tasarlanmış bir taşıma katmanı protokolüdür.[10] İletim Kontrol Protokolü (TCP) yaygın olarak kullanılmaktadır. Ancak HTTP, Kullanıcı Datagram Protokolü (UDP) gibi güvenilmez protokolleri, örneğin HTTPU ve Basit Hizmet Keşif Protokolü (SSDP) gibi kullanacak şekilde uyarlanabilir.

HTTP kaynakları, Tekdüzen Kaynak Tanımlayıcıları (URL'ler) şemaları http ve https kullanılarak, Tekdüzen Kaynak Konum Belirleyicileri (URL'ler) tarafından tanımlanır. RFC 3986'da tanımlandığı gibi, URL'ler HTML belgelerinde köprüler olarak kodlanır, böylece birbirine bağlı köprü belgeleri oluşturulur. HTTP/1.1, orijinal HTTP'nin (HTTP/1.0) bir revizyonudur. HTTP/1.0'da her kaynak isteği için aynı sunucuya ayrı bir bağlantı yapılır. Sayfa teslim edildikten sonra resimleri, komut dosyalarını, stil sayfalarını vb. indirmek için bir bağlantıyı birden çok kez yeniden kullanabilir. Bu nedenle HTTP/1.1 iletişimleri, TCP bağlantılarının kurulmasında önemli ölçüde ek yük oluşturduğundan daha az gecikme yaşar.

Tarihçe

Hiper metin terimi ilk kez, Ted Nelson tarafından 1965'te Xanadu Projesi'nde ortaya atıldı. Bu da Vannevar Bush'un 1930'lardaki mikrofilm temelli bilgi erişim ve yönetim sistemi "memex"in vizyonundan esinlenerek 1945 tarihli "Düşündüğümüz Gibi" adlı makalesinde anlatıldı. Tim Berners-Lee ve CERN'deki ekibi, orijinal HTTP'yi, HTML'i ve bir web sunucusu ve metin tabanlı bir web tarayıcı için ilgili teknolojiyi icat etmekle tanınır. Ayrıca Berners-Lee, ilk olarak 1989 yılında "WorldWideWeb" projesini önerdi - günümüzde World Wide Web olarak bilinmektedir. Protokolün ilk sürümünde, bir sunucudan bir sayfa talep edecek GET adında tek bir yöntem bulunuyordu.[11]

HTTP'nin belgelenen ilk sürümü 1991'de yayınlanan HTTP V0.9'du.[12] Dave Raggett, 1995 yılında HTTP Çalışma Grubunu (HTTP WG) yönetti ve protokolü, ek yöntemler ve başlık alanları ekleyerek daha verimli hale gelen bir güvenlik protokolüne bağlı genişletilmiş işlemler, genişletilmiş görüşme, daha zengin meta bilgilerle genişletmek istedi.[13][14] RFC 1945 ise, 1996'da resmi olarak HTTP V1.0'ı tanıttı.

HTTP WG, Aralık 1995'te yeni standartlar yayınlamayı planladı[15] ve daha sonra gelişmekte olan RFC 2068'e (HTTP-NG olarak adlandırılır) dayanan ön standart HTTP/1.1 desteği, 1996'nın başlarında büyük tarayıcı geliştiricileri tarafından hızla benimsendi. Yeni tarayıcıların 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 HTTP 1.1 uyumlu olduğunu bildirdi. Aynı web barındırma şirketi, Haziran 1996 itibarıyla, sunucularına erişen tüm tarayıcıların %65'inin HTTP/1.1 uyumlu olduğunu bildirdi.[16] RFC 2068'de tanımlanan HTTP/1.1 standardı resmi olarak Ocak 1997'de yayınlandı. Daha sonra yapılan iyileştirmeler ve güncellemeler, Haziran 1999'da RFC 2616 kapsamında yayınlandı.

2007'de, HTTP/1.1 spesifikasyonunu revize etmek ve açıklığa kavuşturmak için kısmen HTTP Çalışma Grubu oluşturuldu.[17] Haziran 2014'te WG, RFC 2616'yı geçersiz kılan güncellenmiş altı bölümlü bir spesifikasyon 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: Önbellek
  • RFC 7235, HTTP/1.1: Kimlik Doğrulama

HTTP/2 ise, Mayıs 2015'te RFC 7540 olarak yayınlandı.

Yıl HTTP versiyonu
1991 0.9
1996 1.0
1997 1.1
2015 2.0
2018 3.0

HTTP oturumu

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 vurgulanır.

Bir HTTP oturumu, bir ağ istek-yanıt işlemleri dizisidir. HTTP istemcisi, bir sunucudaki belirli bir bağlantı noktasına (tipik olarak 80 numaralı bağlantı noktası, bazen 8080 numaralı bağlantı noktası) bir İletim Kontrol Protokolü (TCP) bağlantısı kurarak bir istek başlatır. (TCP ve UDP port numaraları listesine bakınız). Bu port üzerinde dinleyen bir HTTP sunucusu, bir istemcinin istek mesajını bekler. İsteği aldıktan sonra sunucu, "HTTP / 1.1 200 OK" gibi bir durum satırı ve kendisine ait bir mesaj gönderir. Bu mesajın gövdesi tipik olarak talep edilen kaynaktır, ancak bir hata mesajı veya başka bilgiler de döndürülebilir.[10]

Kalıcı bağlantılar

HTTP/0.9 ve 1.0'da, bağlantı tek bir istek/yanıt çiftinden sonra kapatılır. HTTP/1.1'de, bir bağlantının birden fazla istek için yeniden kullanılabileceği bir canlı tutma mekanizması tanıtıldı. Bu tür kalıcı bağlantılar, istemcinin ilk istek gönderildikten sonra TCP 3 Yollu El Sıkışma bağlantısını yeniden iletmesi gerekmediğinden istek gecikmesini hissedilir şekilde azaltır. Diğer bir olumlu yan etki, genel olarak, TCP'nin yavaş başlatma mekanizması nedeniyle bağlantının zamanla daha hızlı hale gelmesidir. Protokolün 1.1 sürümü ayrıca HTTP/1.0 için bant genişliği optimizasyonu iyileştirmeleri yaptı. Örneğin, HTTP/1.1, kalıcı bağlantılardaki içeriğin ara belleğe alınmak yerine akışa alınmasına izin vermek için parçalı aktarım kodlaması getirmiştir. HTTP ardışık düzeni, gecikme süresini daha da azaltarak istemcilerin her yanıtı beklemeden önce birden çok istek göndermesine olanak tanır. Protokole bir başka ek, bir sunucunun bir istemci tarafından açıkça talep edilen bir kaynağın sadece bir kısmını ilettiği bayt hizmetiydi.

Oturum durumu

HTTP, durum bilgisiz bir protokoldür. Durum bilgisi olmayan bir protokol, HTTP sunucusunun birden çok istek süresi boyunca her bir kullanıcı hakkındaki bilgileri veya durumu saklamasını gerektirmez. Ancak, bazı web uygulamaları, örneğin HTTP tanımlama bilgilerini veya web formları içindeki gizli değişkenleri kullanarak durumlar veya sunucu tarafı oturumları uygular.

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 sınamayı tanımlayıp yayınladığı bir sınama-yanıt mekanizması aracılığıyla çalışan çoklu kimlik doğrulama şemaları sağlar.

HTTP, bir sunucu tarafından bir istemci isteğini sorgulamak için ve bir istemci tarafından kimlik doğrulama bilgilerini sağlamak için kullanılabilen, genişletilebilir bir dizi sınama-yanıt kimlik doğrulama şemaları aracılığıyla erişim kontrolü ve kimlik doğrulaması için genel bir çerçeve sağlar.[18]

Kimlik doğrulama

HTTP Kimlik Doğrulaması belirtimi ayrıca belirli bir kök URL'de ortak olan kaynakları daha fazla bölmek için rastgele, uygulamaya özgü bir yapı sağlar. Bölge değeri dizesi, varsa, meydan okumanın koruma alanı bileşenini oluşturmak için kurallı kök URL ile birleştirilir. Bu, sunucunun tek bir kök URL altında ayrı kimlik doğrulama kapsamları tanımlamasına izin verir.[18]

Mesaj biçimi

İstemci sunucuya istek gönderir ve sunucu yanıtlar gönderir.

Mesaj isteği

İstek mesajı aşağıdakilerden oluşur:

  • Bir istek satırı (örneğin, sunucudan /images/logo.png adlı bir kaynak isteyen GET /images/logo.png HTTP/1.1)
  • Başlık alanları (örneğin, Accept-Language: en)
  • Boş satır
  • İsteğe bağlı mesaj bölümü

İstek satırı ve diğer başlık alanlarının her biri <CR> <LF> ile bitmelidir. (Bir satır başı karakteri ve ardından bir satır besleme karakteri). Boş satır yalnızca <CR> <LF> içermeli ve başka bir boşluk olmamalıdır.[1] HTTP/1.1 protokolünde, ana bilgisayar dışındaki tüm başlık alanları isteğe bağlıdır. Yalnızca yol adını içeren bir istek satırı, RFC 1945'teki HTTP/1.0 belirtiminden önce, HTTP istemcileriyle uyumluluğu korumak için sunucular tarafından kabul edilir.[19]

İstek yöntemleri

HTTP, tanımlanan kaynakta gerçekleştirilmesi istenen eylemi belirtmek için yöntemleri tanımlar (bazen fiil olarak adlandırılır, ancak spesifikasyonun hiçbir yerinde fiilden bahsedilmez ve OPTIONS veya HEAD bir fiil değildir). Önceden var olan veriler veya dinamik olarak oluşturulan veriler olsun, bu kaynağın neyi temsil ettiği, sunucunun uygulanmasına bağlıdır. Çoğu zaman kaynak, bir dosyaya veya sunucuda bulunan bir yürütülebilir dosyanın çıktısına karşılık gelir. HTTP/1.0 spesifikasyonu[20] GET, HEAD ve POST yöntemlerini tanımladı ve HTTP/1.1 spesifikasyonu[1] beş yeni yöntem ekledi: OPTIONS, PUT, DELETE, TRACE ve CONNECT. Bu belgelerde belirtilerek, anlambilimleri iyi bilinir ve bunlara güvenilebilir. 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 ara madde tarafından bilinmiyorsa, güvenli olmayan ve etkisiz olmayan bir yöntem olarak ele alınacaktır. Tanımlanabilecek yöntem sayısında herhangi bir sınırlama yoktur ve bu, mevcut altyapıyı bozmadan gelecekteki yöntemlerin belirlenmesine olanak tanır. Örneğin, WebDAV yedi yeni yöntem tanımladı ve RFC 5789 PATCH yöntemini belirledi. Yöntem adları büyük/küçük harfe duyarlıdır.[21][22] Bu, büyük/küçük harfe duyarlı olmayan HTTP başlık alanı adlarının tersidir.[21]

GET

GET yöntemi, belirtilen kaynağın bir temsilini ister. GET kullanan istekler yalnızca verileri almalı ve başka bir etkisi olmamalıdır. (Bu, diğer bazı HTTP yöntemleri için de geçerlidir.)[1] W3C, bu ayrımla ilgili kılavuz ilkeler yayınladı ve "Web uygulaması tasarımı yukarıdaki ilkelerle ve aynı zamanda ilgili sınırlamalarla bilgilendirilmelidir." şeklinde açıklama yaptı.[23]

HEAD

HEAD yöntemi, GET isteğiyle aynı olan ancak yanıt gövdesi olmayan bir yanıt ister. Bu, tüm içeriği taşımak zorunda kalmadan yanıt başlıklarında yazılan meta bilgileri almak için kullanışlıdır.

POST

POST yöntemi, sunucunun, talepte yer alan varlığı URL tarafından tanımlanan web kaynağının yeni bir alt ögesi olarak kabul etmesini ister. POST edilen veriler, örneğin, mevcut kaynaklar için bir açıklama olabilir; bir bülten panosu, haber grubu, posta listesi veya yorum dizisi için bir mesaj; bir web formunun bir veri işleme sürecine gönderilmesinin sonucu olan bir veri bloğu; veya veritabanına eklenecek bir ögedir.[1]

PUT

PUT yöntemi, kapalı varlığın sağlanan URL altında depolanmasını ister. URL zaten var olan bir kaynağa başvuruyorsa, değiştirilir; URL mevcut bir kaynağa işaret etmiyorsa, sunucu bu URL ile kaynağı oluşturabilir.[1]

DELETE

DELETE yöntemi, belirtilen kaynağı siler.

TRACE

TRACE yöntemi, alınan isteği yansıtır, böylece bir istemci, ara sunucular tarafından (varsa) hangi değişikliklerin veya eklemelerin yapıldığını görebilir.

OPTIONS

OPTIONS yöntemi, sunucunun belirtilen URL için desteklediği HTTP yöntemlerini döndürür. Bu, belirli bir kaynak yerine '*' isteyerek bir web sunucusunun işlevselliğini kontrol etmek için kullanılabilir.

CONNECT

CONNECT yöntemi, istek bağlantısını şeffaf bir TCP/IP tüneline dönüştürür, genellikle şifrelenmemiş bir HTTP proxy'si aracılığıyla SSL şifreli iletişimi (HTTPS) kolaylaştırır.[24][25]

PATCH

PATCH yöntemi, bir kaynağa kısmi değişiklikler uygular.[26]

Tüm genel amaçlı HTTP sunucularının en azından GET ve HEAD yöntemlerini uygulaması gerekir ve diğer tüm yöntemler şartnameye göre isteğe bağlı kabul edilir.[1]

Güvenli yöntemler

Yöntemlerden bazıları (örneğin, GET, HEAD, OPTIONS ve TRACE), geleneksel olarak güvenli olarak tanımlanır, yani bunlar yalnızca bilgi alma amaçlıdır ve sunucunun durumunu değiştirmemelidir. Başka bir deyişle, günlük tutma, web önbelleğe alma, banner sunulması veya bir web sayacı artırma gibi nispeten zararsız etkilerin ötesinde yan etkileri olmamalıdır. Uygulamanın durumuna bakılmaksızın keyfi GET taleplerinde bulunmak bu nedenle güvenli kabul edilmelidir. Ancak, bu standart tarafından zorunlu kılınmamıştır ve garanti edilemeyeceği açıkça kabul edilmiştir.

Buna karşılık, POST, PUT, DELETE ve PATCH gibi yöntemler, sunucu üzerinde yan etkilere veya Elektronik ticaret veya e-posta iletimi gibi harici yan etkilere neden olabilecek eylemler için tasarlanmıştır. Bu nedenle, bu tür yöntemler genellikle uyumlu Arama robotları veya web tarayıcıları tarafından kullanılmaz; uymayanlar bağlam veya sonuçlara bakılmaksızın istekte bulunma eğilimindedir.

GET isteklerinin öngörülen güvenliğine rağmen, uygulamada bunların sunucu tarafından işlenmesi teknik olarak hiçbir şekilde sınırlı değildir. Bu nedenle, dikkatsiz veya kasıtlı programlama, sunucuda önemsiz olmayan değişikliklere neden olabilir. Bu tavsiye edilmez, çünkü web önbelleğine alma, arama motoru ve diğer otomatik aracılar için sorunlara neden olabilir ve bu da sunucuda istenmeyen değişiklikler yapabilir. Örneğin, bir web sitesi http://example.com/article/1234/delete gibi bir URL aracılığıyla bir kaynağın silinmesine izin verebilir; bu, GET kullanılarak bile keyfi olarak getirilirse, yalnızca makaleyi siler.[27] Pratikte bunun bir örneği, bir kullanıcının görüntülediği sayfadaki rastgele URL'leri önceden getirerek kayıtların toplu olarak otomatik olarak değiştirilmesine veya silinmesine neden olan kısa ömürlü Google Web Accelerator'ın beta sürümünde meydana geldi. Beta, yaygın eleştirilerin ardından ilk sürümünden sadece haftalar sonra askıya alındı.[27][28]

Etkisiz yöntemler ve web uygulamaları

PUT ve DELETE yöntemleri etkisiz olarak tanımlanır, yani birden çok özdeş isteğin tek bir istekle aynı etkiye sahip olması gerekir. GET, HEAD, OPTIONS ve TRACE yöntemleri, güvenli olarak tanımlanır ve HTTP durumsuz bir protokol olduğundan etkisiz olmalıdır.[10]

Bunun tersine, POST yöntemi etkisiz değildir ve bu nedenle, aynı POST isteğinin birden çok kez gönderilmesi durumu daha fazla etkileyebilir veya başka yan etkilere (e-ticaret gibi) neden olabilir. Bazı durumlarda bu arzu edilebilir, ancak diğer durumlarda bu, bir kullanıcının eyleminin başka bir istek göndermesiyle sonuçlanacağını fark etmemesi veya ilk talebinin yapıldığına dair yeterli geri bildirim almaması gibi bir kazadan kaynaklanıyor olabilir. Web tarayıcıları, bir sayfanın yeniden yüklenmesinin POST isteğini yeniden gönderebileceği bazı durumlarda kullanıcıları uyarmak için uyarı iletişim kutuları gösterebilirken, POST isteğinin birden fazla kez gönderilmemesi gereken durumları ele almak genellikle web uygulamasına bağlıdır.

Bir yöntemin etkisiz olup olmadığının protokol veya web sunucusu tarafından zorlanmadığını unutulmamalıdır. Örneğin, bir veritabanı girişinin veya etkisiz olmayan başka bir eylemin bir GET veya başka bir talep tarafından tetiklendiği bir web uygulaması yazmak tamamen mümkündür. Ancak, bir kullanıcı aracısı aynı isteği tekrar etmenin güvenli olmadığına karar verirse, bu tavsiyenin göz ardı edilmesi istenmeyen sonuçlara yol açabilir.

Güvenlik

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.[29]

Yöntem RFC İstek gövdesi Yanıt gövdesi Güvenli Etkisiz Bellekte tutulabilir
PATCH RFC 5789 Evet Evet Hayır Hayır Hayır
POST RFC 7231 Evet Evet Hayır Hayır Evet
PUT Evet Evet Hayır Evet Hayır
CONNECT Kısmen Evet Hayır Hayır Hayır
DELETE Kısmen Evet Hayır Evet Hayır
GET Kısmen Evet Evet Evet Evet
HEAD Kısmen Hayır Evet Evet Evet
OPTIONS Kısmen Evet Evet Evet Hayır
TRACE Hayır Evet Evet Evet Hayır

Yanıt mesajı

Yanıt mesajı aşağıdakilerden oluşur:

  • Durum kodunu ve neden mesajını içeren bir durum satırı (örneğin, istemcinin isteğinin başarılı olduğunu belirten HTTP/1.1 200 OK)
  • Yanıt başlığı alanları (örneğin, İçerik Türü: metin/html)
  • Boş satır
  • İsteğe bağlı mesaj bölümü

Durum satırı ve diğer başlık alanlarının tümü <CR> <LF> ile bitmelidir. Boş satır yalnızca <CR> <LF> içermeli ve başka bir boşluk olmamalıdır.[10] <CR> <LF> için bu katı gereksinim, yalnızca <CR> veya <LF> gibi diğer sistem satır kesmelerinin tutarlı kullanımı için ileti gövdeleri içinde biraz gevşetilir.[10]

Durum kodları

HTTP/1.0 ve sonraki sürümlerinde, HTTP yanıtının ilk satırı durum satırı olarak adlandırılır ve bir sayısal durum kodu ("404" gibi) ve metinsel bir neden cümlesi ("Bulunamadı" gibi) içerir. Kullanıcı aracısının yanıtı işleme biçimi, öncelikle koda ve ikinci olarak diğer yanıt başlığı alanlarına bağlıdır. Özel durum kodları kullanılabilir, çünkü kullanıcı aracısı tanımadığı bir kodla karşılaşırsa, yanıtın genel sınıfını belirlemek için kodun ilk hanesini kullanabilir.[10]

  • Bilgi 1XX
  • Başarılı 2XX
  • Yönlendirme 3XX
  • İstemci Hatası 4XX
  • Sunucu Hatası 5XX

Şifrelenmiş bağlantı

Şifreli bir HTTP bağlantısı kurmanın en popüler yolu HTTPS'dir.[30] Şifreli bir HTTP bağlantısı kurmak için iki başka yöntem de mevcuttur: Güvenli Köprü Metni Aktarım Protokolü ve TLS'ye yükseltme belirtmek için HTTP/1.1 Yükseltme başlığını kullanma. Ancak bu ikisi için tarayıcı desteği neredeyse yoktur.[31][32][33]

Örnek oturum

Aşağıda, bir HTTP istemcisi ile www.example.com, bağlantı noktası 80 üzerinde çalışan bir HTTP sunucusu arasındaki örnek bir konuşma bulunmaktadır.

İstemci isteği

GET / HTTP/1.1
Host: www.example.com

Bir istemci isteğini (bu durumda istek satırı ve yalnızca bir başlık alanından oluşur) boş bir satır izler, böylece istek, her biri satır başı şeklinde olan çift satır sonu ile biter. "Ana Bilgisayar" alanı, tek bir IP adresini paylaşan çeşitli DNS adları arasında ayrım yaparak isme dayalı sanal barındırmaya izin verir. HTTP / 1.0'da isteğe bağlı olsa da, HTTP / 1.1'de zorunludur. ("/", Varsa /index.html anlamına gelir.)

Sunucu yanıtı

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

ETag (varlık etiketi) başlık alanı, istenen kaynağın önbelleğe alınmış bir sürümünün sunucudaki kaynağın geçerli sürümüyle aynı olup olmadığını belirlemek için kullanılır. Content-Type, HTTP mesajı tarafından taşınan verinin İnternet ortam tipini belirtirken Content-Length, uzunluğunu bayt cinsinden belirtir. HTTP/1.1 web sunucusu, Accept-Ranges: bayt alanını ayarlayarak belgenin belirli bayt aralıklarına yönelik isteklere yanıt verme yeteneğini yayınlar. Bu, istemcinin, bayt hizmeti olarak adlandırılan, sunucu tarafından gönderilen bir kaynağın yalnızca belirli kısımlarına[34] sahip olması gerekiyorsa yararlıdır. Connection: close gönderildiğinde, web sunucusunun bu yanıtın aktarılmasından 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. İçerik Uzunluğu eksik olduğunda, uzunluk başka yollarla belirlenir. Parçalı aktarım kodlaması, içeriğin sonunu işaretlemek için yığın boyutu 0 kullanır. İçerik Uzunluğu olmadan kimlik kodlaması, soket kapanana kadar içeriği okur.

Gzip gibi bir sıkıştırma programı, iletilen verileri sıkıştırmak için kullanılabilir.

Benzer protokoller

  • Gopher protokolü, 1990'ların başlarında HTTP tarafından değiştirilen bir içerik teslim protokolüdür.
  • SPDY protokolü, Google'da geliştirilen ve HTTP/2'nin yerini alan HTTP'ye bir alternatiftir.

Ayrıca bakınız

Kaynakça

  1. Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T. (Haziran 1996). "Hypertext Transfer Protocol -- HTTP/1.1" (İngilizce): RFC2616. doi:10.17487/rfc2616.
  2. "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. 19 Şubat 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  3. Friedl, Stephan; Langley, Adam; Popov, Andrey. "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". tools.ietf.org (İngilizce). 10 Ekim 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  4. Belshe, M.; Peon, R.; Thomson, M. (30 Mayıs 2015). "Hypertext Transfer Protocol Version 2 (HTTP/2)". http2.github.io (İngilizce). 15 Temmuz 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  5. Bishop <mbishop@evequefou.be>, Mike. "Hypertext Transfer Protocol Version 3 (HTTP/3)". tools.ietf.org (İngilizce). 17 Temmuz 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  6. Cimpanu, Catalin. "HTTP-over-QUIC to be renamed HTTP/3". ZDNet (İngilizce). 13 Kasım 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  7. Cimpanu, Catalin. "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet (İngilizce). 26 Eylül 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  8. "HTTP/3: the past, the present, and the future". The Cloudflare Blog (İngilizce). 26 Eylül 2019. 26 Eylül 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  9. "Firefox Nightly supports HTTP 3". Cloudflare Community (İngilizce). 6 Kasım 2019. 6 Haziran 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  10. Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T. (Haziran 1999). "Hypertext Transfer Protocol -- HTTP/1.1" (İngilizce): RFC2616. doi:10.17487/rfc2616.
  11. "HyperText Transfer Protocol". www.w3.org. 7 Haziran 1997 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  12. "The HTTP Protocol As Implemented In W3". www.w3.org. 5 Haziran 1997 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  13. "Dave Raggett's Bio". www.w3.org. 3 Temmuz 1998 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  14. "HTTP Working Group". www.w3.org. 6 Ocak 2008 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  15. "HTTP Working Group". www.w3.org. 8 Ocak 2008 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  16. "WebCom Guide - Glossary - http 1.1 Compliant Browsers". webarchive.loc.gov. 26 Nisan 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  17. "IETF HTTP Working Group". IETF HTTP Working Group (İngilizce). 19 Şubat 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  18. Fielding, R.; Reschke, J., (Edl.) (Haziran 2014). "Hypertext Transfer Protocol (HTTP/1.1): Authentication" (İngilizce): RFC7235. doi:10.17487/rfc7235.
  19. "Apache Week. HTTP/1.1". www.apacheweek.com. 14 Mart 2006 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  20. Berners-Lee, T.; Fielding, R.; Frystyk, H. (Mayıs 1996). "Hypertext Transfer Protocol -- HTTP/1.0" (İngilizce): RFC1945. doi:10.17487/rfc1945.
  21. Fielding, Roy; Reschke, Julian. "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". tools.ietf.org (İngilizce). 14 Temmuz 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  22. Fielding, Roy; Reschke, Julian. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". tools.ietf.org (İngilizce). 14 Temmuz 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  23. "URIs, Addressability, and the use of HTTP GET and POST". www.w3.org. 17 Mayıs 2003 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  24. Khare, R.; Lawrence, S. (Mayıs 2000). "Upgrading to TLS Within HTTP/1.1" (İngilizce): RFC2817. doi:10.17487/rfc2817.
  25. "HTTP proxy default configurations allow arbitrary TCP connections". www.kb.cert.org. 15 Haziran 2002 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  26. Dusseault, L.; Snell, J. (Mart 2010). "PATCH Method for HTTP" (İngilizce): RFC5789. doi:10.17487/rfc5789.
  27. Ediger, Brad. (2008). Advanced Rails. Farnham: O'Reilly. ISBN 978-0-596-51972-8. OCLC 213482728.
  28. Cantrell, Christian (1 Haziran 2005). "What Have We Learned From the Google Web Accelerator?". Adobe. 19 Ağustos 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Ağustos 2020.
  29. "Cross Site Tracing Software Attack | OWASP Foundation". owasp.org (İngilizce). 28 Nisan 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  30. Canavan, John E. (2001). Fundamentals of network security. Boston: Artech House. ISBN 1-58053-176-8. OCLC 45172884.
  31. "Google Code Archive - Long-term storage for Google Code Project Hosting". code.google.com. 1 Mart 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  32. "4527 - chromium - An open-source project to help move the web forward. - Monorail". bugs.chromium.org. 8 Temmuz 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  33. "276813 - [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1". bugzilla.mozilla.org (İngilizce). 14 Mart 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
  34. Franks, John; Luotonen, Ari. "Byte Range Retrieval Extension to HTTP". tools.ietf.org (İngilizce). 30 Kasım 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ağustos 2020.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.