HTTP

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 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]

İ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]

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]

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]

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.

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]

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]

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

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