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, 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'nin56 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ı78 (Chrome ve Firefox'un kararlı sürümlerinde etkinleştirilebilir).9
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.
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.1314 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ı:
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 |
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.18
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.
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, 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.19
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.20
İstemci sunucuya istek gönderir ve sunucu yanıtlar gönderir.
İstek mesajı aşağıdakilerden oluşur:
İ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.21 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.22
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 spesifikasyonu23 GET, HEAD ve POST yöntemlerini tanımladı ve HTTP/1.1 spesifikasyonu24 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.2526 Bu, büyük/küçük harfe duyarlı olmayan HTTP başlık alanı adlarının tersidir.27
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.)28 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ı.29
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.30
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.31
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.3233
PATCH
PATCH yöntemi, bir kaynağa kısmi değişiklikler uygular.34
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.35
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.36 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ı.3738
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.39
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.
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.40
<table> <thead> <tr class="header"> <th><p>Yöntem</p></th> <th><p>RFC</p></th> <th><p>İstek gövdesi</p></th> <th><p>Yanıt gövdesi</p></th> <th><p>Güvenli</p></th> <th><p>Etkisiz</p></th> <th><p>Bellekte tutulabilir</p></th> </tr> </thead> <tbody> <tr class="odd"> <td><p><strong>PATCH</strong></p></td> <td><p>RFC 5789</p></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="even"> <td><p><strong>POST</strong></p></td> <td><p>RFC 7231</p></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="odd"> <td><p><strong>PUT</strong></p></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="even"> <td><p><strong>CONNECT</strong></p></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="odd"> <td><p><strong>DELETE</strong></p></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="even"> <td><p><strong>GET</strong></p></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="odd"> <td><p><strong>HEAD</strong></p></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="even"> <td><p><strong>OPTIONS</strong></p></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr class="odd"> <td><p><strong>TRACE</strong></p></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> </tbody> </table>Yanıt mesajı aşağıdakilerden oluşur:
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.41 <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.42
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.43
1XX2XX3XX4XX5XXŞifreli bir HTTP bağlantısı kurmanın en popüler yolu HTTPS'dir.44 Ş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.454647
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.
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.)
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ına48 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.
Orijinal kaynak: http. Creative Commons Atıf-BenzerPaylaşım Lisansı ile paylaşılmıştır.
OWASP Foundation | erişimtarihi = 7 Ağustos 2020 | dil = İngilizce | çalışma = owasp.org | arşivurl = https://web.archive.org/web/20200428023557/https://owasp.org/www-community/attacks/Cross_Site_Tracing | arşivtarihi = 28 Nisan 2020 | ölüurl = evet }} ↩
Ne Demek sitesindeki bilgiler kullanıcılar vasıtasıyla veya otomatik oluşturulmuştur. Buradaki bilgilerin doğru olduğu garanti edilmez. Düzeltilmesi gereken bilgi olduğunu düşünüyorsanız bizimle iletişime geçiniz. Her türlü görüş, destek ve önerileriniz için iletisim@nedemek.page