Dersler ile ilgili yazılarımın genel kategorisi.

HTTP Dersleri – Sözlük

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

Bu sözlük, HTTP dersleri serisi için gerekli terimleri içerir. HTTP durum kodlarının ne anlama geldiğini çabucak bulmanız gerekiyorsa, bu sözlük yararlı olabilir.

HTTP sözlüğünde aşağıdakilerini bulabilirsiniz;

  • İstek Yöntemleri
  • Durum Kodları
  • Başlıklar
  • MIME Türleri

İstek Yöntemleri

Yöntem Açıklama İstek Gövdesi Var mı?
CONNECT HTTP CONNECT yöntemi, istenen kaynakla çift yönlü iletişim başlatır. Bir tünel açmak için kullanılabilir. Hayır
DELETE DELETE yöntemi, kaynak sunucunun Request-URI tarafından tanımlanan kaynağı silmesini talep eder. Hayır
GET HTTP GET yöntemi, belirtilen kaynağın gösterimini ister. GET’i kullanarak yapılan istekler yalnızca veri alır. Hayır
HEAD HTTP HEAD yöntemi, belirtilen kaynak bir HTTP GET yöntemiyle istenirse, döndürülen üstbilgileri ister. Örneğin, bant genişliğini korumak için büyük bir kaynak indirmeye karar vermeden önce böyle bir istek yapılabilir. Hayır
OPTIONS HTTP OPTIONS yöntemi, hedef kaynak için iletişim seçeneklerini tanımlamak için kullanılır. İstemci, OPTIONS yöntemi için belirli bir URL’yi veya tüm sunucuya atıf yapmak için bir yıldız (*) belirtebilir. Hayır
POST HTTP POST yöntemi sunucuya veri gönderir. İstek gövdesinin türü İçerik Türü başlığı ile gösterilir. Evet
PUT HTTP PUT istek yöntemi, yeni bir kaynak oluşturur veya istek yüküyle hedef kaynağın gösterimini değiştirir. Evet
TRACE TRACE yöntemi, istek iletisinin uzaktaki bir uygulama katmanı döngüsünü çağırmak için kullanılır. Hayır

Durum Kodları

Bu iki tablo durum kod aralıklarını ve tüm durum kodlarını tanımlar.

Durum Kodu Aralıkları;

Aralık Tanımlanmış Aralık Kategori
100-199 100-101 Bilgilendirme
200–299 200–206 Başarılı
300–399 300–305 Yönlendirme
400–499 400–415 İstemci hatası
500–599 500–505 Sunucu Hatası

Durum Kodları

Status code Reason phrase Meaning
100 Continue Bu geçici yanıt, şu ana kadar olan her şeyin iyi olduğunu ve istemcinin isteği yerine getirmesi gerektiğini veya tamamlanmış halde yok sayacağını gösterir.
101 Switching Protocols Bu kod, istemci tarafından bir yükseltme isteği üstbilgisine yanıt olarak gönderilir ve sunucunun da değiştiği protokolü gösterir.der.
200 OK İstek başarılı.
201 Created Talep başarılı olmuş ve sonucunda yeni bir kaynak yaratılmıştır. Bu genellikle bir PUT isteğinden sonra gönderilen yanıttır.
202 Accepted Talep alındı ancak henüz işleme konmadı. İstekte bulunulmaması, HTTP’de daha sonra isteğin işlenişinin sonucunu gösteren asenkron bir yanıt göndermesinin imkânsız olduğu anlamına gelir. Başka bir işlemin veya sunucunun isteği işlediği durumlar veya toplu işlemler için tasarlanmıştır.
203 Non-Authoritative Information Bu yanıt kodu, gönderilen meta bilgi kümesinin orijin sunucusundan geldiği şekliyle tam olarak ayarlanmadığı, ancak yerel veya üçüncü bir tarafın kopyasından toplandığı anlamına gelir. Bu durum dışında, bu yanıt yerine 200 OK yanıtı tercih edilmelidir.
204 No Content Bu istek için gönderilecek herhangi bir içerik yok, ancak başlıklar yararlı olabilir. Kullanıcı aracı, önbellekte saklanan üstbilgilerini bu kaynak için yenileri ile yeniler.
205 Reset Content Bu yanıt kodu, bu talebi gönderen kullanıcı aracısı sıfırlama belge görüntüsünü bildirmek için istekte bulunulduktan sonra gönderilir.
206 Partial Content Bu yanıt kodu, istemci tarafından indirmeyi birden fazla akışa gönderen menzil başlığı nedeniyle kullanılır.
300 Multiple Choices İsteğin birden fazla olası yanıtı var. Kullanıcı aracısı veya kullanıcı bunlardan birini seçmelidir. Yanıtlardan birini seçmenin standart bir yolu yok.
301 Moved Permanently Bu yanıt kodu, istenen kaynağın URI’sinin değiştirildiği anlamına gelir. Muhtemelen, yanıtta yeni URI verilecektir.
302 Found Bu yanıt kodu, istenen kaynağın URI’sinin geçici olarak değiştirildiği anlamına gelir.
303 See Other İstemciye, kaynağın farklı bir URL kullanılarak getirileceğini söyler. Bu yeni URL, yanıt mesajının Konum başlığında yer almaktadır.
304 Not Modified İstemciler, isteklerini, içerdikleri istek başlıklarına göre koşullu yapabilir. Bu kod, kaynağın değişmediğini gösterir.
305 Use Proxy Kaynağa bir proxy vasıtasıyla erişilmelidir; vekilin konumu Konum başlığında verilmiştir.
306 (Unused) Bu durum kodu şu anda kullanılmıyor. HTTP 1.1 spesifikasyonunun önceki bir sürümünde kullanılmıştır.
307 Temporary Redirect 301 durum kodu gibi; Ancak, müşteri, kaynağı geçici olarak bulmak için Konum başlığında verilen URL’yi kullanmalıdır.
400 Bad Request İstemciye hatalı biçimlendirilmiş bir istek gönderdiğini bildirir.
401 Unauthorized İstemciye kaynağa erişmeden önce kendini doğrulamasını isteyen uygun üstbilgilerle birlikte geri gönderilir.
402 Payment Required Şu anda bu durum kodu kullanılmıyor, ancak ileride kullanılmak üzere bir kenara ayırıldı. Bu durum kodu dijital ödeme yöntemleri düşünülerek oluşturuldu ama hiç kullanılmadı.
403 Forbidden İstek sunucu tarafından reddedildi. Yetkisiz istekler için kullanılır genelde.
404 Not Found Sunucu istenen URL’yi bulamıyor.
405 Method Not Allowed İstenen URL için desteklenmeyen bir yöntemle bir istek yapıldı. İstenilen kaynakta hangi yöntemlerin izin verildiğini istemciye söylemek için Allow üstbilgisi yanıtta bulunmalıdır.
406 Not Acceptable İstemciler hangi tür gövde içeriklerini kabul etmeye istekli oldukları konusunda parametreleri belirleyebilir. Bu kod, sunucuda istemci için kabul edilebilir URL ile eşleşen hiçbir kaynak yoksa kullanılır.
407 Proxy Authentication Required 401 durum kodu gibi, ancak bir kaynak için kimlik doğrulaması gerektiren proxy sunucuları için kullanılır.
408 Request Timeout Bir istemcinin isteğini tamamlamak çok uzun sürerse, sunucu bu durum kodunu geri gönderebilir ve bağlantıyı kapatabilir.
409 Conflict İstek, kaynakta bazı çakışmalara neden oluyor.
410 Gone Bu yanıt, istenen içerik sunucudan kalıcı olarak silindiğinde gönderilen adres olmaksızın oluşturulur.
411 Length Required Sunucular, istek iletisinde bir Content-Length üstbilgi gerektirdiğinde bu kodu kullanır. Sunucu, İçerik Uzunluğu başlığı olmadan kaynak isteklerini kabul etmeyecektir.
412 Precondition Failed Bir istemci koşullu bir istekte bulunur ve koşullardan biri başarısız olursa, bu yanıt kodu döndürülür.
413 Request Entity Too Large İstemci, sunucu tarafından tanımlanan sınırlardan daha büyük; Sunucu bağlantıyı kapatabilir veya bir Rety-After başlık alanını döndürebilir.
414 Request URI Too Long İstemci tarafından talep edilen URI, sunucunun yorumlayabileceğinden daha uzun.
415 Unsupported Media Type İstemci, sunucunun anlamadığı veya desteklemediği bir içerik türünün bir varlığını gönderdi.
416 Requested Range Not Satisfiable İstek iletisi belirli bir aralıktaki bir kaynağı istedi ve bu aralık geçersiz veya karşılanamadı.
417 Expectation Failed Bu yanıt kodu, Bekleme isteği üstbilgisi alanı tarafından belirtilen beklentinin sunucu tarafından karşılanamadığı anlamına gelir.
500 Internal Server Error Sunucu, isteğin yerine getirilmesini engelleyen bir hata ile karşılaştı.
501 Not Implemented İstemci, sunucunun yeteneklerinin ötesinde bir istekte bulundu.
502 Bad Gateway Proxy veya ağ geçidi gibi çalışan bir sunucu, istek yanıt zincirindeki bir sonraki bağlantıdan sahte bir yanıtla karşılaştı.
503 Service Unavailable Sunucu şu anda isteği hizmet edemez, ancak ileride mümkün olacaktır.
504 Gateway Timeout Yanıt 408 durum koduna benzer, başka bir sunucudan gelen isteği yanıtlamayı bekleyen zaman aşımına uğramış bir ağ geçidi veya proxy’den gelen yanıt.
505 HTTP Version Not Supported Sunucu protokolün destekleyemediği veya desteklemeyeceği bir sürümünde bir istek aldı.

Referans: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Başlıklar (Headers)

Hem HTTP isteği hem de HTTP yanıtı, başlık alanları içerebilir. Bu iki tablo alanları açıklamakta ve basit örnekler vermektedir.

İstek Başlıkları

Başlık Açıklama Örnek
Accept Yanıt için kabul edilebilir olan bazı ortam türlerini belirtmek için kullanılabilir Accept: text/plain
Accept-Charset Yanıt için hangi karakter setlerinin kabul edilebilir olduğunu gösterir. Accept-Charset: utf-8
Accept-Encoding Accept’e benzer şekilde, ancak yanıtta kabul edilebilir içerik kodlamalarını da kısıtlıyor. Accept-Encoding: gzip, deflate
Accept-Language Accept’e benzer şekilde, ancak yanıt olarak tercih edilen doğal dil kümesini kısıtlar. Accept-Language: en-US
Authorization HTTP kimlik doğrulaması için kimlik doğrulama kimlik bilgileri. Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control İstek-yanıt zinciri boyunca tüm önbellekleme mekanizmalarının uyması gereken yönergeleri belirtmek için kullanılır. Cache-Control: no-cache
Connection Gönderenin belirli bağlantı için istenen seçenekleri belirtmesine ve daha fazla bağlantı üzerinden proxy vasıtasıyla iletilmesine izin verilmemesine izin verir. Connection: keep-alive
Content-Encoding Content-Encoding bir dokümanın temel medya türünün kimliğini kaybetmeden sıkıştırılmasına izin vermek için kullanılır. Content-Encoding: gzip
Cookie Daha önce Set-Cookie ile sunucu tarafından gönderilen bir HTTP tanımlama bilgisi. Cookie: $Version=1;
Content-Length İstek gövdesinin sekizli uzunluğu (8-bit bayt). Content-Length: 1024
Content-MD5 İstek gövdesinin içeriğinin Base64 ile kodlanmış bir ikili MD5 toplamı. Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type İsteğin gövdesinin MIME türü (POST ve PUT istekleriyle kullanılır). Content-Type: application/ x-www-form-urlencoded
Date Mesajın gönderildiği tarih ve saat. Date: Tue, 19 Jun 2012 10:10:10 GMT
Expect Belirli sunucu davranışlarının istemci tarafından gerekli olduğunu gösterir. Expect: 100-continue
From İsteği yapan kullanıcının e-posta adresi. From: codemazeblog@gmail.com
Host Sunucunun etki alanı adı (sanal barındırma için) ve sunucunun dinlediği TCP bağlantı noktası numarası. Bağlantı noktası talep edilen hizmet için standart bağlantı noktası ise, bağlantı noktası numarası atlanabilir. HTTP / 1.1’den beri zorunludur. Host: code-maze.com
If-Match If-Match HTTP isteği üstbilgisi, isteği koşullu yapar. GET ve HEAD yöntemleri için, sunucu, yalnızca listelenen ETags’lerden biriyle eşleştiğinde istenen kaynağı geri gönderir. PUT ve diğer güvenli olmayan yöntemler için, bu durumda kaynağı yalnızca yükleyecektir. If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified- Since If-Modified-Since isteği HTTP başlığı, isteği koşullu hale getirir: sunucu, belirtilen tarihten sonra son değiştirildiğinde, 200 durumu olan istenen kaynağı geri gönderir. Talep o zamandan bu yana değiştirilmemişse, yanıt herhangi bir gövde olmaksızın 304 olacak; Last-Modified başlığı son değişiklik tarihini içerir. If-Modified-Since’ın aksine, If-Modified-Since, yalnızca GET veya HEAD ile kullanılabilir. If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match If-None-Match HTTP isteği üstbilgisi, isteği koşullu yapar. GET ve HEAD yöntemleri için, sunucu yalnızca istenen kaynağı 200 statüsünde geri gönderir, ancak yalnızca belirtilen ETAG ile eşleşen bir ETag yoksa. Diğer yöntemler için, talep, yalnızca var olan kaynağın ETag’si listelenen herhangi bir değerle eşleşmiyorsa işleme koyulur. If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range If-Aralığı HTTP isteği üstbilgisi istenilen aralıkta ise yapar: koşul karşılandığı takdirde istenilen aralık verilecek ve sunucu, uygun gövdeyle birlikte 206 Partial Content yanıtını geri gönderir. Durum tamamlanmazsa, tüm kaynak 200 OK durumu ile geri gönderilir. If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified- Since If-Unmodified-Since isteği HTTP üstbilgisi, isteği koşullu hale getirir: Sunucu, yalnızca verilen tarihten sonra değiştirilmemişse istenen kaynağı geri gönderir. İstek, belirtilen tarihten sonra değiştirildiyse, yanıt 412 (Precondition Failed) hatası olacaktır. If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Forwards İletinin proxy’ler veya ağ geçitleri ne kadar süreyle iletilebileceği sınırlar. Max-Forwards: 10
Origin İsteğin kaynağının neresi olduğunu belirtir. Herhang ibir yolu değil, sadece sunucu ismini belirtir. Origin: http://www.code-maze.com
Pragma İstek-yanıt zincirinin herhangi bir yerine çeşitli etkileri olabilen, uygulamaya özgü üstbilgiler. Pragma: no-cache
Proxy- Authorization Bir proxy’ye bağlanmak için yetkilendirme kimlik bilgileri. Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range Kaynağın yalnızca bir bölümünü istediğini belirtir. Baytlar 0’dan başlayarak numaralandırılır. Range: bytes=500-999
Referer Şu anda bulunan istekten bir önceki isteğin yolunu belirtir. Referer: http://www.code-maze.com
TE TE istek başlığı, kullanıcı aracısının kabul etmeye istekli olduğu kodlamaları belirtir. (Bi başlık için daha mantıklı bir isimlendirme olabilecek Accept-Transfer-Encoding ile karıştırılabilir). TE: trailers, deflate
Upgrade Sunucunun başka bir protokole yükseltmesini isteyin. Upgrade: HTTPS/1.3, IRC/6.9, RTA/x11, websocket
User-Agent İsteği yapan kullanıcı ile ilgili istemci bilgilerini (Hangi tarayıcı gibi) içerir. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Via Sunucuyu, isteğin gönderildiği vekiller hakkında bilgilendirir. Via: 1.0 fred, 1.1 example.com(Apache/1.1)
Warning Gövde ile ilgili olası problemleri içerir. Warning: 199 Miscellaneous warning

Yanıt Başlıkları

Başlık Açıklama Örnek
Access-Control-Allow-Origin Cross-origin kaynak paylaşımına hangi web sitelerinin katılabileceğini belirtir. Access-Control-Allow- Origin: *
Accept-Ranges Sunucunun bir kaynak için hangi aralıkları kabul ettiğini belirtmesine izin verir. Accept-Ranges: bytes
Age Age üstbilgisi, nesnenin bir proxy önbelleğinde olduğu saniye cinsinden süreyi içerir. Age: 24
Allow İstek-URI tarafından tanımlanan kaynak tarafından desteklenen yöntemler kümesini listeler. Bu alanın amacı, alıcının kaynağıyla ilişkili geçerli yöntemleri kesinlikle bilgilendirmektir. Allow: GET, HEAD, PUT
Cache-Control Cache-Control genel üstbilgi alanı hem isteklerde hem de yanıtlarda önbelleğe alma mekanizmaları için yönergeler belirtmek için kullanılır. Cache-Control: max-age=3600
Connection Geçerli işlem tamamlandıktan sonra ağ bağlantısının açık kalıp sürdürülmeyeceğini denetler. Connection: close
Content-Encoding Verilerde kullanılan kodlamanın türü. HTTP sıkıştırma konusuna bakın. Content-Encoding: gzip
Content-Language Sunulan içeriğin dilini belirtir. Content-Language: en
Content-Length Yanıt gövdesinin sekizli uzunluğu (8-bit bayt) Content-Length: 1024
Content-Location Döndürülen veriler için alternatif yer. Content-Location: /index.htm
Content-MD5 Yanıt içeriğinin Base64 ile kodlanmış bir ikili MD5 toplamı. Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Disposition Bilinen bir MIME türü için ikili biçimde “Dosya İndirme” diyalog kutusunu yükseltme veya dinamik içerik için bir dosya adı önermek için bir fırsat oluşturur. Tırnak işaretleri özel karakterlerle girilmesi gereklidir. Content-Disposition: attachment; filename=”fname.ext”
Content-Range Content-Range üstbilgisi, kısmi bir mesajın, tüm içerikte nereye ait olduğunu gösterir. Content-Range: bytes 21010-47021/47022
Content-Type İçeriğin MIME türü Content-Type: text/html; charset=utf-8
Date Mesajın gönderildiği tarih. Date: Sun, 17 Jun 2017 10:11:12 GMT
ETag İçeriği belirli bir sürümü için tanımlayıcı başlıktır, genellikle bir ileti özetidir. ETag: “737060cd8c284d8af7ad3082f209582d”
Expires Yanıtın geçerli olduğu tarihi / zamanı verir. Expires: Date: Sun, 17 Jun 2017 10:11:12 GMT
Last-Modified İstenilen içeriği, sunucuda son değiştirilme olduğu tarihi ve saati içerir. Last-Modified: Date: Sun, 17 Jun 2017 10:11:12 GMT
Link İlişki türü RFC 5988 tarafından tanımlanan başka bir kaynakla yazılan ilişkiyi ifade etmek için kullanılır Link: ; rel=”alternate”
Location Yeniden yönlendirmede veya yeni bir kaynak oluşturulduğunda kullanılır. Location: http://www.code-maze.com/index.html
P3P Bu üstbilgi, P3P: CP = “your_compact_policy” şeklinde Gizlilik Tercihleri İçin Platform (Platform for Privacy Preferences Project – P3P) politikası belirler. Bununla birlikte, P3P hiç bir zaman çıkmadı, çoğu tarayıcı bunu hiç bir zaman tam olarak uygulamadı. P3P: CP=”This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info.”
Pragma İstek-yanıt zincirinin herhangi bir yerinde çeşitli etkiler oluşturabilen, uygulamaya özgü üstbilgiler. Pragma: no-cache
Proxy-Authenticate Proxy’ye erişmek için kimlik doğrulama isteği. Proxy-Authenticate: Basic
Refresh Yeniden yönlendirmede veya yeni bir kaynak oluşturulduğunda kullanılır. Bu yönlendirme 5 saniye sonra gerçekleşir. Bu, Netscape tarafından tanıtılan ve çoğu web tarayıcısı tarafından desteklenen, tescilli, standart olmayan bir başlık uzantısıdır. Refresh: 5; url=http://www.code-maze.com/index.html
Retry-After Bir kaynak geçici olarak kullanılamıyorsa, bu, istemciye belirli bir süre sonra tekrar denemesini sağlar (saniye). Retry-After: 240
Server Sunucu ismi Server: Apache/2.4 (Unix)
Set-Cookie HTTP çerezi (Cookie) oluşşturur Set-Cookie: UserID=1; Max-Age=3600; Version=1
Strict-transfer-Security HTTP istemcisine HTTPS ilkesini ne kadar süreyle önbelleğe alacağını ve HSTS İlkesi ve bunun alt alanlar için geçerli olup olmadığını bildirir. Strict-transfer-Security: max-age=16070400; includeSubDomains
Trailer Trailer yanıt başlığı, gönderenin, ileti gövdesi gönderilirken dinamik olarak oluşturulabilecek meta verileri sağlamak için, mesaj bütünlüğü denetimi, dijital imza veya post-processing durumu gibi parçalanmış mesajların sonuna ek alanlar koymasına olanak tanır. Trailer: Max-Forwards
Transfer-Encoding Kaynağı kullanıcıya güvenli bir şekilde aktarmak için kullanılan kodlama biçimi. Şu anda tanımlanmış yöntemler şunlardır: chunked, compress, deflate, gzip, identity. Transfer-Encoding: chunked
Vary Orijinal sunucudan yeni bir istek istemek yerine önbelleğe alınmış bir yanıtın kullanılabilir olup olmayacağına karar vermek için gelecekteki istek üstbilgileriyle nasıl eşleşeceğini belirler. Vary: *
Via İstemciye, cevabın gönderildiği vekiller hakkında bilgi verir. Via: 1.0 mick, 1.1 baselogic.com(Apache/2.4)
Warning Gövdedeki sorunlar hakkında genel bilgidir. A general warning about possible problems with the entity body.
WWW-Authenticate İstenen kaynağa erişmek için kullanılması gereken kimlik doğrulama şemasını belirtir. WWW-Authenticate: Basic

Referans: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

MIME Türleri

İnternet Medya Türleri’nin miktarı nedeniyle, en sık kullanılanlar burada listelenmiştir.

Genel MIME Türleri

Tür Açıklama
application Uygulama tanımlı format (discrete)
audio Ses formatı (discrete)
chemical Kimyasal veri seti (discrete IETF extension)
image Resim formatı (discrete)
message Mesaj biçimi (composite)
model 3 boyutlu model biçimi (discrete IETF extension)
multipart Birden çok nesne koleksiyonu (composite)
text Metin biçimi (discrete)
video Video filmi biçimi (discrete)

Referans: https://www.iana.org/assignments/media-types/media-types.xhtml

Bu sözlükte bahsedilen herşey HTTP 1.1 spesifikasyon belgesinde daha ayrıntılı olarak bulunabilir: http://www.ietf.org/rfc/rfc2616.txt

HTTP Dersleri – Ders 5 – Güvenlik

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

HTTP serisini takip ettiyseniz, artık HTTP güvenliği yolculuğuna çıkmaya hazırsınız demektir. Güzel bir yolculuk olacak, söz veriyorum.

Birçok şirket güvenlik ihlallerine maruz kalmıştır. Sadece birkaç önemli özelliği belirtmek için: Dropbox, Linkedin, MySpace, Adobe, Sony, Forbes ve daha birçokları kötü niyetli saldırıların son noktalarında. Birçok hesap ele geçirildi ve en azından birisinde hesabınız vardır.

Aslında şuradan kontrol edebilirsiniz, Have I Been Pwned.

E-posta adresim, güvenlik ihlalinin kurbanı olan 4 farklı web sitesinde bulundu.

Web uygulaması güvenliğinin pek çok özelliği vardır, bir makalede ele alınacak çok şey var, ancak en başından başlayalım. Önce HTTP iletişimimizi nasıl güvenli yapacağımızı öğrenelim.

Bu makalede, hakkında daha fazla bilgi edineceksiniz:

  • Gerçekten HTTPS’ye ihtiyacınız var mı?
  • HTTPS’nin temel kavramları
  • SSL-TLS
  • TLS el sıkışma
  • Sertifika ve Sertifika Yetkilileri
  • Sertifika zincirleri
  • HTTPS zayıf yönleri

Üzerinden geçilecek çok şey var, o yüzden hemen başlayalım.

Gerçekten HTTPS’ye ihtiyacınız var mı?

Düşünüyor olabilirsiniz: “Elbette bütün web sitelerinin korunması gerekmez”. Bir web sitesi hassas verilere hizmet etmiyorsa veya herhangi bir form gönderiminde bulunmuyorsa, yalnızca “Güvenli” yazan URL çubuğunda küçük yeşil işareti almak için sertifikalar satın almak ve web sitesini yavaşlatmak aşırı olacaktır.

Bir web siteniz varsa, mümkün olduğunca hızlı yüklenmesi çok önemlidir, dolayısıyla gereksiz şeyler yüklememeye çalışın.

İlk etapta korunması gerekmeyen web sitesinizi güvence altına almak için neden acımasızca HTTPS’ye taşıma sürecine girdiniz? Üstelik bunun parasını ödemeniz de gerekiyor.

Buna gerçekten değer mi bakalım.

HTTPS iletilerinizi şifreler ve MITM sorununu çözer

HTTP serisinin önceki bölümünde farklı HTTP kimlik doğrulama mekanizmaları ve güvenlik kusurları hakkında konuştuk. Hem temel hem de Digest kimlik doğrulamasının çözemediği sorun man-in-the-middle (ortadaki adam) saldırısıdır. Ortadaki adam, sizinle iletişim kurduğunuz web sitesi arasına kendisini yerleştiren kötü amaçlı bir programı temsil eder. Amacı orijinal mesajları her iki yönden de çevirmek ve değiştirilen mesajları tekrar iletmek suretiyle kendisini gizlemektir.

İletişimin orijinal katılımcıları, mesajlarının dinlendiğinden haberdar olmayabilir.

HTTPS, iletişimi şifreleyerek MITM saldırı sorununu çözer. Şimdi, bu, trafiğinizin artık dinlenemeyeceği anlamına gelmiyor. Bu, iletilerinizi dinleyen ve kesen herkesin içeriğini göremeyeceği anlamına gelir. Mesajın şifresini çözmek için anahtara ihtiyacı vardır. Bunun nasıl olduğunu tam olarak biraz sonra öğreneceğiz.

Hadi devam edelim.

Sıralama sinyali olarak HTTPS

Yakın zamanda Google, HTTPS’yi bir sıralama sinyali yaptı.

Bu ne anlama geliyor?

Bu, bir web yöneticisiyseniz ve Google sıralamanızı önemsiyorsanız, HTTPS’yi web sitenizde kesinlikle uygulamalısınız. Bazılarının kalite içeriği ve geri dönüş gibi işaretleri kadar güçlü olmasa da, kesinlikle önemlidir.

Bunu yaparak, Google, web yöneticilerine mümkün olan en kısa sürede HTTPS’ye geçme ve internetin genel güvenliğini artırma konusunda teşvik sağlar.

Tamamen ücretsizdir

Bir web sitesi için HTTPS’yi (SSL / TLS) etkinleştirmek için bir Sertifika Otoritesi tarafından verilen bir sertifikaya ihtiyacınız vardır. Yakın geçmişe kadar sertifikalar pahalıydı ve her yıl yenilenirdi.

Let’s Encrypt geliştiricilerine teşekkürler ki sertifikayı ücretsiz alabilmekteyiz. Cidden, onlar tamamen ücretsizdir.

Şifreleme sertifikalarının kolayca yüklenip, büyük bir şirket desteğinin verildiği harika bir topluluktur. Ana sponsorlarına bir göz atın ve onlara destek veren şirketlerin listesine göz atın. Birkaç tanesini tanıyabilirsiniz.

Let’s Encrypt, DV (Domain Doğrulama) ile çalışır. Her sertifikanın ömrü 90 gündür ve otomatik olarak yenilenir.

Her harika teknoloji gibi, kötü tarafı da var. Sertifika artık kolaylıkla bulunabildiğinden, Kimlik Avı web siteleri tarafından istismar ediliyor.

Her Şey Hızla İlgilidir

HTTPS kullanan siteler çok daha hızlı çalışmaktadır. httpvshttps.com‘ye bir göz atın.

Peki orada ne oldu? Neden HTTPS çok daha hızlıdır? Bu nasıl mümkün olabilir?

HTTPS, HTTP 2.0 protokolünü kullanmak için şarttır.

Ağ sekmesine bakarsak, HTTPS durumunda görüntülerin h2 protokolü üzerinden yüklendiğini göreceğiz. Ve akış çok farklı görünüyor.

HTTP 2.0 şu anda yaygın olan HTTP / 1.1’in halefidir.

HTTP / 1.1’e göre pek çok avantajı vardır:

  • Metinsel değil, ikili.
  • Tek bir TCP bağlantısı üzerinden birden fazla isteği paralel olarak gönderebileceği anlamına gelen tam çoğullama
  • HPACK sıkıştırmasını kullanarak yükü azaltır
  • Daha hızlı şifrelenmiş bağlantılar sağlayan yeni ALPN uzantısını kullanır
  • Ek gidiş dönüş sürelerini (RTT) azaltır, böylece web siteniz daha hızlı yüklenir

ve daha bir çoğu.

Şimdilik ikna olmadıysanız, muhtemelen bazı tarayıcıların şifrelenmemiş içeriğe karşı savaş başlattığını bilmelisiniz. Google, Chrome’un güvensiz web sitelerine nasıl davranacağını net bir şekilde açıklayan bir blog yayınladı.

Chrome sürüm 56’dan önce ve sonra nasıl göründüğü aşağıda belirtilmiştir.

Şimdi ise bu şekilde gözükmektedir;

Halen ikna olmadınız mı?

HTTPS’ye Geçmek Karmaşıktır

Bu aynı zamanda geçmiş zamanların kalıntılarıdır. HTTPS’ye geçmek, HTTP üzerinden yüklenen kaynakların yoğunluğu nedeniyle uzun süredir var olan web siteleri için daha zor olabiliyor olsa da, barındırma sağlayıcıları genellikle bu işlemi daha kolay hale getirmeye çalışmaktadır.

Birçok barındırma sağlayıcıları, HTTPS’ye otomatik geçiş sunar. Seçenekler panelinde bir düğmeyi tıklamak kadar kolay olabilir.

Web sitenizi HTTPS üzerinden kurmayı planlıyorsanız, barındırma sağlayıcısının önce HTTPS geçişi sunup sunmadığını kontrol edin. Veya kabuk erişimine sahipse, şifrelemek ve biraz sunucu yapılandırması ile kolayca kendiniz yapabilirsiniz.

Bu nedenle, HTTPS’ye geçmek için sebepler bunlar. Herhangi bir sebep yok mu?

Umarım, şimdiye kadar sizi HTTPS değerinden ikna etmiştimdir.

HTTPS’nin temel kavramları

HTTPS, Köprü Metni Aktarım Protokolü Güvenli (Hypertext Transfer Protocol Secure) anlamına gelir. Etkili bir şekilde istemci ve sunucu HTTP üzerinden ancak güvenli SSL / TLS bağlantısı üzerinden iletişim kurar.

Serinin önceki bölümlerinde, HTTP iletişiminin nasıl çalıştığını öğrendik, ancak SSL / TLS bölümü neydi ve hem SSL hem de TLS’yi neden kullanıyoruz?

Onunla başlayalım.

SSL-TLS

SSL (Güvenli Yuva Katmanı) ve TLS (Aktarım Katmanı Güvenliği) terimleri birbirlerinin yerine kullanılılabilirdi, ancak aslında, bugün birileri SSL sözü ettiğinde muhtemelen TLS demek istiyordur. TLS daha yeni bir teknolojidir.

SSL aslında Netscape tarafından geliştirildi, ancak sürüm 1.0 bugünün ışığını hiç görmedi. Sürüm 2.0 1995’te, 1996’da da 3.0 sürümünde tanıtıldı ve daha sonradan ne kadar uzun süre kullanıldılarsa da, halef TLS zaten yol almaya başlamıştı. Bu durum 2014’e kadar devam etti. TLS’den SSL’ye düşüş, sunucular tarafından desteklendi ve POODLE saldırısının bu kadar başarılı olmasının başlıca nedeni oldu.

Bundan sonra, SSL’ye geçiş tamamen devre dışı bırakıldı.

Sizinkini veya Qualys SSL Labs aracıyla başka bir web sitesini kontrol ederseniz, muhtemelen böyle bir şey göreceksiniz:

Gördüğünüz gibi, SSL 2 ve 3 hiç desteklenmiyor ve TLS 1.3 hala kapalı değil.

Ancak, SSL çok uzun süredir bu kadar yaygın olduğundan, çoğu insanın aşina olduğu ve şimdi hemen hemen her şey için kullanılan bir terim haline geldi. Dolayısıyla, TLS yerine SSL kullanan birisini duyduğunuzda, yalnızca tarihsel nedenlerden ötürü, SSL olduklarından değil.

Şimdi bunu bir kenara bıraktık, artık daha uygun olduğundan TLS’i kullanacağım.

Peki, istemci ve sunucu nasıl güvenli bir bağlantı kuruyor?

TLS El Sıkışması

İstemci ve sunucu arasındaki gerçek şifreli iletişim başlamadan önce, “TLS el sıkışması” adlı işlemi gerçekleştirirler.

Aşağıdaki gibi işler (çok basitleştirilmiştir, ek bilgiler için bağlantılar aşağıdadır).

Bağlantı kurulduktan sonra şifreli iletişim başlar.

Gerçek mekanizma bundan çok daha karmaşıktır, ancak HTTPS’yi uygulamak için el sıkışma uygulamasının tüm gerçek ayrıntılarını bilmeniz gerekmez.

Bilmeniz gereken şey, istemci ile sunucu arasında anahtarlar ve sertifikalar değiştiren ilk bir el sıkışması olmasıdır. Bu el sıkışma sonrasında, şifrelenmiş iletişim başlamaya hazırdır.

Tam olarak nasıl çalıştığını bilmek isterseniz, RFC 2246‘a bakabilirsiniz.

TLS el sıkışma görüntüsünde sertifikalar gönderiliyor, bu nedenle bir sertifikanın neyi temsil ettiğini ve nasıl verildiğini görelim.

Sertifika ve Sertifika Yetkilileri (CA’lar)

Sertifikalar, HTTPS üzerinden güvenli iletişimin çok önemli bir parçasıdır. Bunlar, güvenilir Sertifika Yetkililerinden biri tarafından verilir.

Dijital sertifika, bir web sitesini kullanırken web sitesinin kullanıcılarının güvenli bir şekilde iletişim kurmalarını sağlar.

Örneğin, blogumda gezinirken kullandığınız sertifika şöyle görünür:

Örneğin, Chrome kullanıyorsanız, Sertifikaları kendiniz incelemek için Geliştirici Araçları’ndaki (F12) Güvenlik sekmesine gidin.

İki şeyi işaret etmek istiyorum. İlki kırmızı kutuda, sertifikanın gerçek amacının ne olduğunu görebilirsiniz. Sadece doğru web sitesiyle konuştuğunuzdan emin olabilirsiniz. Birisi, örneğin iletişim kurduğunuzu düşündüğünüz web sitesini kimliğine bürünmüşse, kesinlikle tarayıcınız tarafından bilgilendirilirsiniz.

Meşru bir sertifika ile meşru bir siteye girmişseniz, kimlik bilgileriniz çalınmayacağı anlamına gelmez. Yani dikkatli olmalısınız. Sol üstteki Yeşil “Güvenli”, doğru web sitesi ile iletişim kurduğunuz anlamına gelir. Bu web sitesinin sahibinin dürüstlüğü konusunda hiçbir şey söylemez.

Genişletilmiş doğrulama sertifikaları, tüzel kişinin web sitesini denetlediğini kanıtlamaktadır. EV (Extended Validation) sertifikaların, internetin tipik kullanıcısı için faydalı olup olmadığı konusunda devam etmekte olan bir tartışma var. Bunları, URL çubuğunuzun sol tarafındaki özel metin ile tanıyabilirsiniz. Örneğin, twitter.com’a göz attığınızda şunları görebilirsiniz:

Bu, şirketlerinin web sitelerinin arkasındaki olduğunu kanıtlamak için EV (Extended Validation) sertifikası kullandıkları anlamına geliyor.

Sertifika zincirleri

Öyleyse neden tarayıcınız sunucunun geri gönderdiği sertifikaya güvenmeli? Herhangi bir sunucu bir parça dijital dokümantasyon gönderebilir ve bunun ne olmasını istediğinizi iddia edebilir.

Burada kök sertifikalar gelir. Genellikle sertifikalar zincirlenir ve kök sertifika makinenizin örtük olarak güvendiği belgedir.

Code-maze.com için şu şekildedir:

En düşük olan alan sertifika, üstündeki sertifika tarafından imzalanmış ve benzeri … Kök sertifikaya ulaşılıncaya kadar.

Ama kök sertifikayı kim imzalar?

Şey, kendisi imzalar.

Yayınlanan: AddTrust External CA Root, Yayınlayan: AddTrust External CA Root.

Makineniz ve tarayıcılarınız, göz attığınız alanın güvenilir olduğuna güvenmek için güvenilen kök sertifikaların bir listesine sahiptir. Sertifika zinciri herhangi bir nedenden dolayı kırılmışsa, siteniz bazı makinelerde güvensiz olarak görüntülenir.

Windows’ta güvenilen kök sertifikaların listesini kontrol etmek için windows ® düğmesini + R tuşlarına basarak ve certmgr.msc yazarak sertifika yöneticisini çalıştırın. Daha sonra güvenilen sertifikaları Güvenilen Kök Sertifika Yetkilileri bölümünde bulabilirsiniz. Bu liste Windows, IE ve Chrome tarafından kullanılır. Öte yandan Firefox, kendi listesini yönetiyor.

Sertifika değişimi yaparak, istemci ve sunucu, doğru tarafla konuştıklarını bildiklerini ve şifreli mesaj aktarmaya başlamasını isteyebilir.

HTTPS’in Zayıf Yönleri

HTTPS, site arkasında düzgün bir şekilde uygulanmadığında yanlış bir güvenlik hissi sağlayabilir. Müşteri bilgilerini ayıklamak için birçok farklı yol var ve birçok site HTTPS kullanıyor olsa bile veri sızdırıyor olabilir. Web sitesinden hassas bilgi almak için MITM dışında birçok başka mekanizma bulunmaktadır.

Web sitelerinin HTTPS üzerinden çalışmasına rağmen HTTP bağlantılarına sahip olabilmesi bir başka potansiyel sorunu. Bu MITM saldırısı için bir şans olabilir. Web sitelerini HTTPS’ye taşırken bu fark edilmeyebilir.

Ve bir de bonus olarak bir tane daha var: Güvensiz bir sayfadan erişilen oturum açma formları, güvenli bir sayfaya yüklenmiş olsalar bile potansiyel olarak tehlikeye girebilirler. Bu nedenle, bir websiteyi önlemek için tüm web sitesini güvende tutmak en iyisidir.

Referanslar;

Orijinali: https://www.code-maze.com/http-series-part-5/

HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

Önceki bölümde, web sitelerinin ziyaret eden kullanıcıyı tanımlamak için kullanabilecek farklı yollardan bahsettik.

Fakat tanımlama sadece bir iddiayı temsil eder. Kendinizi tanımlarken, birisi olduğunuzu iddia ediyorsunuz. Fakat bunun kanıtı yok.

Kişisel id’nizi göstermek veya şifrenizi girmek gibi kimlik doğrulama ile iddia ettiğiniz kişi olduğunuza dair bir kanıt gösteriyorsunuz.

Çoğu zaman, web sitelerini hassas kaynaklarını sunmak için bu kanıta ihtiyacı vardır.

HTTP, sunucuların zorluklar çıkarmalarına ve ihtiyaç duydukları kanıtları elde etmelerine olanak tanıyan kendi kimlik doğrulama mekanizmalarına sahiptir. Ne olduklarını ve nasıl çalıştıklarını öğreneceksiniz. Ayrıca, her birinin artılarını ve eksilerini de ele alacağız ve kendi başlarına kullanılabilecek kadar iyi olup olmadığını keşfedeceğiz (spoyler: iyi değiller).

Bu makalede, aşağıdaki konular hakkında bilgi edineceksiniz:

  • HTTP kimlik doğrulaması nasıl çalışır?
  • Temel kimlik doğrulama
  • Özet kimlik doğrulaması

HTTP kimlik doğrulama mekanizmalarına derinlemesine girmeden önce, HTTP kimlik doğrulamasının ne olduğundan bahsedelim.

HTTP kimlik doğrulaması nasıl çalışır?

Kimlik doğrulama, kendinizi Web sunucusuna tanıtmanın bir yoludur. İstenen kaynaklara erişme hakkına sahip olduğunuzu gösteren bir kanıt göstermeniz gerekiyor. Genellikle, sunucu tarafından doğrulanan ve sonra kaynağa erişip erişemeyeceğinize karar veren kullanıcı adı ve parola (anahtar ve gizli) kombinasyonunu kullanarak yapılır.

HTTP, iki kimlik doğrulama protokolü sunar:

  • Temel kimlik doğrulama
  • Özet kimlik doğrulaması

Her biri hakkında daha fazla bilgi edinmeden önce, bazı temel kavramları inceleyelim.

1. HTTP, bir zorlama / yanıt kimlik doğrulama çerçevesi kullanır

Ne anlama geliyor?

Birisi bir istek gönderdiğinde, ona hemen yanıt vermek yerine, sunucu kimlik doğrulama talebi gönderir. Gizli bilgileri (kullanıcı adı ve parola) girerek kimliğini kanıtlamak için kullanıcıyı zorlar.

Bundan sonra, verilen kimlik bilgileri kullanılarak istek tekrar edilir ve doğruysa, kullanıcı beklenen yanıtı alır. Kimlik bilgilerinin yanlış olması durumunda, sunucu zorluğu tekrar gönderir veya yalnızca hata iletisini gönderir.

2. Kimlik doğrulama ile ilgili istek / yanıt başlıkları

Sunucu, WWW-Authenticate yanıt başlığını kullanarak sorunu çözer. Kimlik doğrulama protokolü ve güvenlik bölgesi ile ilgili bilgileri içerir.

İstemci kimlik bilgilerini girdikten sonra istek tekrar gönderilir. Bu sefer kimlik doğrulama algoritması ve kullanıcı adı / şifre kombinasyonu içeren Yetkilendirme başlığı ile.

Kimlik bilgileri doğruysa, sunucu isteğe bağlı bir Kimlik Doğrulama-Bilgisi yanıt başlığında yanıt ve ek bilgi verir.

3. Güvenlik alanları

Güvenlik alanları, farklı erişim kaynaklarını sunucu üzerindeki farklı kaynak gruplarıyla ilişkilendirmenin yolunu sağlar. Bunlara koruma alanları denir.

Bunun etkili olduğu, erişmek istediğiniz kaynağa bağlı olarak farklı kimlik bilgileri girmeniz gerekebilir.

Sunucu, birden çok alandan oluşabilir. Örneğin, yalnızca web sitesi yöneticilerinin erişebileceği web sitesi istatistik bilgileri ve diğer kullanıcıların resimlere erişebilecekleri ve indirebilecekleri web sitesi görüntüleri için bir tane olması gerekir.

/admin/statistics/financials.txt -> Alan = “Yönetici İstatistikleri”

/images/img1.jpg -> Alan = “Resimler”

Financials.txt dosyasına erişmeye çalıştığınızda, sunucu tarafından itiraz edileceksiniz ve yanıt aşağıdaki gibi görünecektir:

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="Admin Statistics"

Güvenlik alanlarıyla ilgili daha fazla bilgi: https://tools.ietf.org/html/rfc7235#section-2.2

Basit HTTP kimlik doğrulama örneği

Şimdi noktaları, en basit HTTP kimlik doğrulama örneğine (Temel kimlik doğrulama, aşağıda açıklanmıştır) bakarak bağlayalım:

1. User Agent -> Sunucu

Kullanıcı, sunucudaki bazı resimlere erişim isteğinde bulunur.

GET /gallery/personal/images/image1.jpg HTTP/1.1
Host: www.somedomain.com

2. Sunucu -> User Agent

Sunucu, kimlik doğrulama sorununu kullanıcıya gönderir.

HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="gallery"

3. User Agent -> Sunucu

Kullanıcı kendisini form girişi yoluyla tanımlar.

GET /gallery/personal/images/image1.jpg HTTP/1.1
Authorization: Basic Zm9vOmJhcg==

4. Sunucu -> User Agent

Sunucu, kimlik bilgilerini denetler ve 200 OK durum kodunu ve resim verisini gönderir.

HTTP/1.1 200 OK
Content-type: image/jpeg
...<image data>

O kadar da karışık değil, değil mi?

Şimdi aşağıya detaylı inceleme yapalım ve temel kimlik doğrulamaya bakalım.

Temel kimlik doğrulama

En yaygın ve desteklenen kimlik doğrulama protokolüdür. HTTP / 1.0’dan beri var olmuştur ve her büyük istemci onu uygular.

Yukarıdaki örnek, Temel kimlik doğrulamasını kullanarak kimlik doğrulamasının nasıl yapılacağını göstermektedir. Uygulamak ve kullanmak oldukça basit, ancak bazı güvenlik kusurları var.

Güvenlik sorunlarına başlamadan önce, Temel kimlik doğrulamasının kullanıcı adı ve şifre ile nasıl ilgilendiğini görelim.

Temel kimlik doğrulama, kullanıcı adını ve parolasını bir dizede paketler ve bunları iki nokta üst üste (:) kullanarak ayırır. Bundan sonra, bunları Base64 kodlaması kullanarak kodlar. Karmaşık gözükmesine rağmen, karıştırılmış karakter dizisi güvenli değildir ve kolayca çözülür. Base64 kodlamanın amacı şifrelemek değil, HTTP başlıklarında uluslararası karakterlere izin verilmemesi nedeniyle kullanıcı adı ve parolasını uyumlu hale getirmektir.

GET /gallery/personal/images/image1.jpg HTTP/1.1
Authorization: Basic Zm9vOmJhcg==

Bu örnekten “Zm9vOmJhcg ==”, Base64 tarafından kodlanmış “foo: bar” dizesinden başka bir şey değildir.

Bu nedenle, istekleri dinleyen herkes kolayca kimlik bilgilerini çözebilir ve kullanabilir.

Bundan daha da kötüsü, kullanıcı adı ve şifreyi kodlamak yardımcı olmayacaktır. Kötü niyetli bir üçüncü taraf, aynı etkiyi elde etmek için şifreli diziyi yine de gönderebilir.

Ayrıca, istek gövdesini değiştiren ve istek başlıklarını sağlam bırakan proxy’lere veya başka herhangi bir saldırıya karşı koruma yoktur.

Gördüğünüz gibi, Temel kimlik doğrulama mükemmel bir yöntem değildir.

Yine de buna rağmen, korunan kaynaklara kazayla erişilmesini önlemek ve bir miktar kişiselleştirme teklif etmek için kullanılabilir.

Daha güvenli ve kullanışlı hale getirmek için, temel kimlik doğrulama, serinin 5. bölümünde bahsettiğimiz SSL üzerinden HTTPS kullanılarak gerçekleştirilebilir.

Bazıları, sisteminizin güvenliği, transfer mekanizmanızın güvenliği kadardır der.

Digest kimlik doğrulaması

Digest kimlik doğrulaması, basit ama güvensiz Temel kimlik doğrulamaya daha güvenli ve güvenilir bir alternatif olarak yapıldı.

Peki, nasıl işliyor?

Digest kimlik doğrulama, şifre bilgilerini gizlemek ve farklı türlerde kötü amaçlı saldırıları önlemek için nonces kullanımı ile birlikte MD5 şifreleme karma yöntemini kullanır.

Bu biraz karışık gelebilir, ancak basit bir örnekte nasıl çalıştığını gördüğünüzde daha net görülecektir.

1. User Agent -> Server

GET /dir/index.html HTTP/1.0
Host: localhost

İstemci, kimliği doğrulanmamış bir istek gönderir.

2. Server -> User Agent

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="shire@middleearth.com",
                        qop="auth,auth-int",
                        nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ",
                        opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw"
Content-Type: text/html
Content-Length: 153
 
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>

Sunucu, Digest kimlik doğrulamasını kullanarak istemciyi kimlik doğrulaması yapmaya zorlar ve gerekli bilgileri istemciye gönderir.

3. User Agent -> Server

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Gandalf",
                     realm="shire@middleearth.com",
                     nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="5a1c3bb349cf6986abf985257d968d86",
                     opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw"

İstemci, yanıt değerini hesaplar ve kullanıcı adı, bölge, URI, nonce, opque, qop, nc ve cnonce ile birlikte gönderir. Bir sürü şey.

Bunları tanımlayalım:

  • nonce ve opaque – istemci tarafından alındığı şekilde döndürülmesi gereken sunucu tarafından tanımlanan dizeler
  • qop (koruma kalitesi) – önceden tanımlanmış değerlerden bir veya daha fazlası (“auth” | “auth-int” | belirteci). Bu değerler özet hesaplamasını etkiler.
  • cnonce – client nonce, qop ayarlanmışsa üretilmelidir. Seçilen düz metin saldırılarından kaçınmak ve ileti bütünlüğünü koruma sağlamak için kullanılır.
  • nc – Qcp ayarlanırsa, nonce sayısı gönderilmelidir. Bu yönergenin amacı, sunucunun, bu sayının kendi kopyasını koruyarak istek tekrarlarını algılamasını sağlamaktır – aynı nc değeri iki kez görüldüyse, istek yeniden yürütülür.

Yanıt özniteliği aşağıdaki şekilde hesaplanır:

HA1 = MD5("Gandalf:shire@middleearth.com:Lord Of The Rings")
       = 681028410e804a5b60f69e894701d4b4
 
HA2 = MD5("GET:/dir/index.html")
       = 39aff3a2bab6126f332b942af96d3366
 
Response = MD5( "681028410e804a5b60f69e894701d4b4:
                 cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ:
                 00000001:0a4f113b:auth:
                 39aff3a2bab6126f332b942af96d3366" )
         = 5a1c3bb349cf6986abf985257d968d86

Qop’a bağlı olarak cevabı nasıl hesaplayacağınızı merak ediyorsanız, RFC 2617‘de bulabilirsiniz.

4. Server -> User Agent

HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 2345
... <content data>

Sunucu, karmayı tek başına hesaplar ve ikisini karşılaştırır. Eşleşirlerse, istenen verilerle istemciye hizmet eder.

Gördüğünüz gibi, Digest kimlik doğrulamasının anlaşılması ve uygulanması daha karmaşıktır.

Ayrıca, Temel kimlik doğrulamadan daha güvenlidir; ancak, man-in-the-middle saldırısına karşı halen savunmasızdır. RFC 2617, bazı zayıf yönlerini giderdiği için Temel kimlik doğrulama yerine Digest kimlik doğrulamasının kullanılmasını önerir. Ayrıca, Digest kimlik doğrulamasının modern şifreleme standartlarına göre halen zayıf olduğunu ve gücünün büyük oranda uygulanmasına bağlı olduğunu gizlemez.

Yani Digest kimlik doğrulamasının özeti:

  • Ağ üzerinden düz metin parolalar göndermez
  • Tekrar çalma saldırılarını önler
  • Mesaj müdahalesine karşı korucular

Bazı zayıf yönler:

  • Man-in-the-middle saldırı için güvenlik açığı
  • Güvenlik seçeneklerinin birçoğu gerekli değildir ve böylece ayarlanmazsa Digest kimlik doğrulama işlevi daha az güvenli bir şekilde yapılır
  • Şifreleri saklarken güçlü şifre karma algoritmalarının kullanılmasını engeller

Bu gerçekler nedeniyle, Digest kimlik doğrulama hala büyük bir itici güç kazanamadı. Temel kimlik doğrulaması çok basit ve Digest kimlik doğrulamasından daha güvenli SSL ile birleştirildi.

Sonuç

Bu sonuç, HTTP serisinin bu kısmı içindir.

HTTP’nin varsayılan olarak sunduğu farklı kimlik doğrulama mekanizmalarına geçtik ve avantajları ve dezavantajları hakkında konuştuk.

Bu kavramlar sizin için artık ekrandaki harflerden ibaret değildir umarım, bir sonraki seferinde ne olduklarını ve ne zaman uygulayacaklarını bilirsiniz.

Bu mekanizmalarla çözülmeyen güvenlik risklerinin bulunduğunun farkındasınız ve bu yüzden HTTPS ve SSL / TLS gibi kavramlar var. Güvenlik riskleri ve bunları serimizin bir sonraki bölümünde nasıl çözeceğimiz hakkında daha fazla konuşuruz.

Bu bölümdeki kavramlardan bazılarını belirsiz buluyorsanız, HTTP serisinin 1. bölümü 2. bölümüne ve 3. bölümüne bakın.

Sonraki Ders: HTTP Dersleri – Ders 5 – Güvenlik

Referanslar;

Orijinal Yazı: https://www.code-maze.com/http-series-part-4/

HTTP Dersleri – Ders 3 – İstemci Kimliği

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

Şimdiye kadar, HTTP’nin mimari yönlerinin temel kavramlarını ve bazılarını öğrendiniz. Bu, bizi HTTP için bir sonraki önemli konuya götürür: istemci tanımlama.

Bu makalede, istemci tanımlamasının neden önemli olduğunu ve Web sunucularının sizi (Web istemcinizi) nasıl tanımlayabileceğini öğreneceksiniz. Ayrıca, bu bilgilerin nasıl kullanıldığını ve saklandığını göreceksiniz.

Bu makalede, aşağıdakiler hakkında daha fazla bilgi edineceksiniz:

  • İstemci kimliği ve neden son derece önemli
  • İstemciyi tanımlamak için farklı yollar
  • Tanımlama için kullanılan HTTP istek üstbilgileri
  • IP adresi
  • Uzun (fat) URL’ler
  • Çerezler (Cookie)

Öncelikle, neden web sitelerinin sizi tanıması gerektiğini görelim.

İstemci Kimliği ve Neden Son Derece Önemli

Farkında olduğunuz gibi, her web sitesi, en azından sizin ve eylemleriniz hakkında yeterince ilgilenenler, bazı içerik kişiselleştirmeler içerir.

Bununla ne demek istiyorum?

Bu kişiselleştirmeler, e-ticaret sitelerine girdiğinizde tavsiye edilen ürünler, sosyal medyada “tanıyabileceğiniz/eklemek isteyebileceğiniz kişiler” tavsiyeleri, tavsiye edilen videolar, neye ihtiyacınız olduğunuzu bilen reklamlar, ilginizi çekebilecek makaleler gibi şeylerdir.

Bu durum kendini iki kenarlı bir kılıç gibi hissettirir. Bir taraftan, kişiselleştirilmiş, özel içeriğin size teslim edilmesi oldukça güzel. Öte yandan, her çeşit kilişe ve önyargıya yol açabilir.

Ancak, en sevdiğim takımın dün gece nasıl gol attığını veya geçen gece hangi ünlülerin yaptıklarını bilmeden nasıl yaşayabiliriz?

Her iki durumda da, içerik kişiselleştirme günlük yaşantımızın bir parçası haline geldi ve muhtemelen bu konuda herhangi bir şey yapmak istemiyoruz.

Web sunucularının bu etkiyi elde etmek için sizi nasıl tanımlayabileceğini görelim.

İstemciyi Tanımlamak İçin Farklı Yöntemler


Bir Web sunucusunun sizi tanımlayabileceği çeşitli yollar vardır:

  • HTTP istek üstbilgileri
  • IP adresi
  • Uzun URL’ler
  • Çerezler (Cookie)
  • Giriş bilgileri (kimlik doğrulama)

Hepsinin üzerinden geçelim. HTTP kimlik doğrulaması, HTTP Dersleri 4. bölümünde daha ayrıntılı olarak açıklanmaktadır.

Tanımlama İçin Kullanılan HTTP İstek Üstbilgileri

Web sunucularının sizin hakkınızdaki bilgileri doğrudan HTTP istek üstbilgilerinden ayıklamanın birkaç yolu vardır.

Bu başlıklar şunlar:

  • From – kullanıcının e-posta adresini içeriyorsa içeriyor
  • User-Agent – Web istemcisi hakkında bilgi içerir
  • Referer – Kullanıcının geldiği kaynağı içeriyor
  • Authorization – kullanıcı adı ve şifre içeriyor
  • Client-ip – kullanıcının IP adresini içerir
  • X-Forwarded-For – kullanıcının IP adresini içerir (proxy sunucusuna giderken)
  • Cookie – sunucu tarafından üretilen kimlik etiketi içeren çerezlerdir

Teorik olarak, From başlığı kullanıcının benzersiz şekilde tanımlanması için ideal olacaktır, ancak uygulamada, e-posta toplamanın güvenlik kaygısı nedeniyle bu başlık çok nadiren kullanılır.

User-Agent üstbilgisi, tarayıcı sürümü, işletim sistemi gibi bilgileri içerir. Bu, içeriği özelleştirmek için önemli olsa da, kullanıcıyı daha alakalı bir şekilde tanımlamaz.

Referer başlığı, sunucuya kullanıcının nereden geldiğini bildirir. Bu bilgi, kullanıcı davranışını anlamayı artırmak için kullanılır, ancak bunu tanımlamak için daha az kullanılır.

Bu üstbilgiler istemci hakkında bazı yararlı bilgiler sağlarken, içeriği anlamlı bir şekilde kişiselleştirmek yeterli değildir.

Geriye kalan başlıklar daha kesin tanımlama mekanizmaları sunar.

IP adresi

IP adresleri tarafından istemci tanımlama yöntemi, IP adreslerinin o kadar kolayca sahte/takas üretilmediği zamanlarda çokca kullanılmıştır. Ek bir güvenlik kontrolü olarak kullanılabilse de, kendi başına kullanılacak kadar güvenilir değildir.

İşte nedenlerinden bazıları:

  • Kullanıcıyı değil, makineyi tanımlıyor
  • NAT güvenlik duvarları – Birçok ISS (İnternet servis sağlayıcı), güvenliği artırmak ve IP adresi yetersizliği ile uğraşmak için NAT güvenlik duvarlarını kullanıyor
  • Dinamik IP adresleri – kullanıcılar genellikle ISP’den dinamik IP adresini alırlar
  • HTTP vekilleri ve ağ geçitleri – bunlar orijinal IP adresini gizleyebilir. Bazı proxy’ler, orijinal IP adresini korumak için Client-ip veya X-Forwarded-For’u kullanır

Uzun (fat) URL’ler

Kullanıcı deneyimini iyileştirmek için web sitelerinin URL’leri kullandığını görmek nadir değildir. Kullanıcı web sitesine göz atarken, URL’ler karmaşık ve okunamaz olana kadar bilgi ekliyorlar.

Amazon mağazasına göz atarak uzun URL’nin nasıl göründüğünü görebilirsiniz.

https://www.amazon.com/gp/product/1942788002/ref=s9u_psimh_gw_i2?ie=UTF8&fpl=fresh&pd_rd_i=1942788002&pd_rd_r=70BRSEN2K19345MWASF0&pd_rd_w=KpLza&pd_rd_wg=gTIeL&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=&pf_rd_r=RWRKQXA6PBHQG52JTRW2&pf_rd_t=36701&pf_rd_p=1cf9d009-399c-49e1-901a-7b8786e59436&pf_rd_i=desktop

Bu yaklaşımı kullanırken çeşitli sorunlar var.

  • Çirkin
  • Paylaşılamaz
  • Önbelleği keser
  • Bulunan oturumla sınırlı
  • Sunucu üzerindeki yükü artırır

Çerezler (Cookie)

Kimlik doğrulama hariç, en güncel istemci tanımlama yöntemi. Netscape tarafından geliştirilmiştir, ancak şimdi her tarayıcı bunları destekliyor.

İki çerez türü vardır: oturum çerezleri ve kalıcı çerezler. Oturum çerezleri, oturum tanımlama bilgisi tarayıcıdan çıktığında silinir fakat kalıcı çerezler diske kaydedilir ve daha uzun kullanılabilir. Oturum çerezinin kalıcı çerez olarak ele alınabilmesi için, Max-Age veya Expiry parametrelerinin ayarlanması gerekir.

Chrome ve Firefox gibi modern tarayıcılar, kapattığınızda arka plan süreçlerini çalışmaya devam ettirebilir, böylece kaldığınız yerden devam edebilirsiniz. Bu, oturum çerezlerinin korunmasına neden olabilir, bu yüzden dikkatli olun.

Peki çerezler nasıl çalışır?

Çerezler, sunucu tarafından Set-Cookie veya Set-Cookie2 yanıt başlığını kullanarak ayarlanan isim = değer çiftlerinin bir listesini içerir. Genellikle, çerezde saklanan bilgiler bir tür istemci kimliğidir, ancak bazı web sitelerinde başka bilgiler de depolanır.

Tarayıcı, bu bilgileri çerez veritabanında saklar ve bir dahaki sefer kullanıcı sayfayı / web sitesini ziyaret ettiğinde onu döndürür. Tarayıcı binlerce farklı çerezleri işleyebilir ve her birine ne zaman hizmet vereceklerini bilir.

İşte örnek bir akış.

1. User-Agent -> Sunucu

POST /acme/login HTTP/1.1
[form data]

2. Sunucu -> User-Agent

HTTP/1.1 200 OK
Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"

Sunucu, User-Agent’ına (tarayıcı), kullanıcı hakkında bir tanımlama bilgisini ayarlamasını söylemek için Set-Cookie yanıt başlığını gönderir.

3. User-Agent -> Sunucu

POST /acme/pickitem HTTP/1.1
Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
[form data]

Kullanıcı öğeyi dükkan sepetine seçer.

4. Sunucu -> User-Agent

HTTP/1.1 200 OK
Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1"; Path="/acme"

Alışveriş sepeti artık bir ürün içeriyor.

5. User-Agent -> Sunucu

POST /acme/shipping HTTP/1.1
Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme";
        Part_Number="Rocket_Launcher_0001";
[form data]

Kullanıcı kargo yöntemini seçiyor.

6. Sunucu -> User-Agent

HTTP/1.1 200 OK
Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme"

Yeni çerez, gönderim yöntemini yansıtıyor.

7. User-Agent -> Sunucu

POST /acme/process HTTP/1.1
Cookie: $Version="1";
        Customer="WILE_E_COYOTE"; $Path="/acme";
        Part_Number="Rocket_Launcher_0001"; $Path="/acme";
        Shipping="FedEx"; $Path="/acme"
[form data]

İşte bu kadar.

Farkında olmanızı istediğim bir şey daha var. Çerez de mükemmel değildir. Güvenlik kaygılarının yanı sıra, çerezlerin REST mimari stili ile çalışmasında bir sorun var. (Çerezleri kötüye kullanmakla ilgili bölüm).

Çerezler hakkında RFC 2965‘de daha fazla bilgi bulabilirsiniz.

Sonuç

İçeriğin kişiselleştirilmesinin güçlü yanları ve potansiyel tuzaklardan öğrendiniz. Ayrıca, sunucuların sizi tanımak için kullanabileceği farklı yöntemlerin farkındasınız. Serinin 4. bölümünde, istemci tanımlamasının en önemli türü hakkında konuşacağız: kimlik doğrulama.

Bu bölümdeki kavramlardan bazılarını belirsiz buluyorsanız, HTTP serisinin 1. ve 2. bölümlerine bakın.

Okuduğunuz için teşekkür ederiz ve yorum yazmaktan çekinmeyin.

Sonraki Ders: HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları

Referanslar;

Orijinal Yazı:

https://www.code-maze.com/http-series-part-3/

HTTP Dersleri – Ders 2 – Mimari Yönleri

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

Serinin ilk yazısında, HTTP’nin temel kavramlarından bahsettik. Artık üzerine inşa etmek için bir temelimiz var, HTTP’nin mimari yönlerinden bazıları hakkında konuşabiliriz. HTTP’ye sadece veri göndermek ve almaktan daha fazla şey var.

HTTP kendiliğinden bir uygulama protokolü olarak işlev göremez. Farklı servisler sağlayan ve World Wide Web üzerinden iletişimin mümkün ve verimli olmasını sağlayan bir donanım ve yazılım çözümü biçiminde altyapıya ihtiyaç duyuyor.

Bu makalede, aşağıdakiler hakkında bilgi edineceksiniz:

  • Web Sunucuları
  • Proxy Sunucuları
  • Caching
  • Ağ geçitleri, Tüneller ve Relaysler
  • Web Tarayıcılar

Bunlar İnternet hayatımızın ayrılmaz bir parçasıdır ve bunların her birinin amacı nedir ve nasıl çalıştığını tam olarak öğreneceksiniz. Bu bilgi, ilk makaledeki noktaları birbirine bağlamanıza ve HTTP iletişim akışını daha da iyi anlamanıza yardımcı olacaktır.

Haydi başlayalım.

Web Sunucuları

İlk makalede açıklandığı gibi, bir Web sunucusunun temel işlevi, kaynakları depolamak ve istekleri alır almaz bunları sunmaktır. Web sunucusuna bir Web istemcisi (başka bir deyişle Web tarayıcısı) kullanarak erişirsiniz ve bunun karşılığında istenen kaynağı alır veya varolanların durumunu değiştirirsiniz. Web sunucularına, Web tarayıcılarını kullanarak otomatik olarak da erişilebilir; bu konuda daha sonra bahsedeceğiz.

En popüler Web sunucularından bazıları ve muhtemelen duyduğunuz olanlar Apache HTTP Sunucusu, Nginx, IIS, Glassfish’tir …

Web sunucuları çok basit ve kullanımı kolay olandan sofistike ve karmaşık yazılım parçaları arasında değişenlik gösterebilir. Modern Web sunucuları, çok farklı görevleri yerine getirebilirler. Web sunucusunun yapabileceği temel görevler:

  • Bağlantı kurma – müşteri bağlantısını kabul etme veya kapatma
  • Alma isteği – bir HTTP istek mesajını okuma
  • İşlem isteği – istek mesajını yorumlayın ve harekete geçin
  • Erişim kaynağı – mesajda belirtilen kaynağa erişin
  • Yanıt oluştur – HTTP yanıt mesajını yarat
  • Yanıt gönder – cevabı istemciye geri gönderin.
  • İşlemi kaydet – tamamlanan işlemi hakkında bir günlük dosyasına yaz

Web sunucusunun temel akışını birkaç farklı aşamada anlatacağım. Bu aşamalar, Web sunucusu akışının çok basitleştirilmiş bir sürümünü temsil eder.

Aşama 1: Bağlantı kurma

Web istemcisi Web sunucusuna erişmek istediğinde, yeni bir TCP bağlantısı açmaya çalışır. Diğer taraftan, sunucu istemcinin IP adresini bulur. Bundan sonra, bu istemciye TCP bağlantısını açmaya veya kapatmaya karar vermek sunucuya kalmış.

Sunucu bağlantıyı kabul ederse, onu mevcut bağlantıların listesine ekler ve o bağlantıdaki verileri izler.

İstemci yetkili değilse veya kara listeye alınmışsa (kötü niyetli) bağlantıyı da kapatabilir.

Sunucu ayrıca “ters DNS” kullanarak istemcinin ana bilgisayar adını belirlemeyi deneyebilir. Bu bilgiler, iletileri günlüğe kaydederken yardımcı olabilir ancak ana makine ad aramaları biraz zaman alabilir ve işlemleri yavaşlatabilir.

Aşama 2: İsteklerin Alınması / İşlenmesi

Gelen istekleri ayrıştırırken, Web sunucuları, bilgi isteği satırından, üstbilgilerinden ve gövdesinden (varsa) bilgi ayrıştırır. Dikkat edilmesi gereken bir husus, bağlantıyı istediğiniz zaman duraklatabilmesidir ve bu durumda, sunucunun verileri geri kalan kısmı alana kadar geçici olarak depolaması gerekir.

Üst düzey Web sunucuları, birçok eş zamanlı bağlantı açabilmelidir. Bu, aynı istemciden gelen birden çok eşzamanlı bağlantıyı içerir. Tipik bir web sayfası sunucudan birçok farklı kaynak isteyebilir.

Aşama 3: Kaynağa erişme

Web sunucuları öncelikli olarak kaynak sağlayıcıları olduklarından, kaynakları eşlemek ve erişmek için birden çok yolları vardır.

En basit yolu, kaynağı eşlemek için Web sunucusunun dosya sistemindeki dosyayı bulmak için istek URI’sini kullanmaktır. Genellikle, kaynaklar docroot adı verilen sunucu üzerindeki özel bir klasöre yerleştirilir. Örneğin, Windows sunucusundaki docroot, F:\WebResources\ üzerinde bulunabilir. Bir GET isteği, /images/codemazeblog.txt dosyasındaki dosyaya erişmek istiyorsa, sunucu bunu F:\WebResources\images\codemazeblog.txt dosyasına çevirir ve bu dosyayı yanıt mesajında ​​döndürür. Web sunucusunda birden fazla web sitesi barındırıldığında, her biri ayrı bir docroot’a sahip olabilir.

Bir Web sunucusu, bir dosya yerine bir dizin için bir istek alırsa, birkaç yolu ile çözebilir. Bir hata mesajı döndürebilir, dizin yerine varsayılan dizin dosyasını döndürür veya dizini tarar ve içeriği HTML dosyasına döndürebilir.

Sunucu ayrıca, istek URI’sini dinamik kaynağa – dinamik sonuç üreten bir yazılım uygulaması – eşleştirir. Web sunucularını karmaşık yazılım çözümlerine bağlamak ve dinamik içeriği sunmak için kullanılan uygulama sunucuları denilen bir sunucu sınıfı vardır.

Aşama 4: Yanıt üretme ve gönderme

Sunucu, sunması gereken kaynağını belirledikten sonra yanıt mesajını oluşturur. Yanıt mesajında durum kodu, yanıt başlıkları ve gerekirse yanıt gövdesi bulunur.

Yanıt içinde gövde varsa, mesaj genellikle gövdenin boyutunu açıklayan Content-Length üstbilgisini ve döndürülen kaynağın MIME türünü açıklayan Content-Type üstbilgisini içerir.

Yanıt üretildikten sonra, sunucu yanıt göndermek için ihtiyaç duyduğu istemciyi seçer. Sürekli olmayan bağlantılar için, sunucunun tüm yanıt mesajı gönderildiğinde bağlantıyı kapatması gerekir.

Aşama 4: Günlüğe kaydetme

İşlem tamamlandığında, sunucu tüm işlem bilgilerini dosyaya kaydeder. Birçok sunucu, özelleştirilmiş günlükleme sağlar.

Proxy Sunucuları

Proxy sunucuları (proxies) aracı sunuculardır. Genellikle Web sunucusu ile Web istemcisi arasında bulunurlar. Proxy sunucularının nitelikleri gereği hem Web istemcisi hem de Web sunucusu gibi davranmaları gerekir.

Ama neden Proxy sunucularına ihtiyacımız var? Neden sadece Web istemcileri ve Web sunucuları arasında doğrudan iletişim kurmuyoruz? Bu çok daha basit ve daha hızlı değil mi?

Basit olabilir, ama daha hızlı? Daha hızlı değil gerçekten. Ama buna geleceğiz.

Proxy sunucuların hangi vekil için kullanıldığını açıklamadan önce, birşeyden bahsetmem lazım. Anlatacağım şey ters proxy kavramı veya ileri proxy ile ters proxy arasındaki farktır.

Yönlendirmeli proxy, bir Web sunucusundan kaynak isteyen istemci için bir vekil görevi görür. İstemciyi güvenlik duvarından filtreleyerek veya istemciyle ilgili bilgileri gizleyerek korur. Ters proxy tam tersi şekilde çalışır. Genellikle güvenlik duvarının arkasına yerleştirilir ve Web sunucularını korur. Tüm istemcilerin bildiği gibi, gerçek Web sunucusuyla konuşurlar ve ters proxy’nin arkasındaki ağdan habersiz kalırlar.

Proxy Sunucu

Proxy Sunucu

Ters Proxy Sunucu

Ters Proxy Sunucu

Proksiler çok faydalıdır ve uygulamaları oldukça geniştir. Şimdi, proxy sunucuların bazı yollarını inceleyelim.

  • Sıkıştırma – İçeriğin sıkıştırılması iletişim hızını doğrudan arttırır. Bu kadar basit.
  • İzleme ve filtreleme – İlkokuldaki çocuklara yetişkinlere yönelik web sitelerine erişimi reddetmek ister misiniz? Proxy sizin için doğru çözüm.
  • Güvenlik – Proksiler, tüm ağa tek bir giriş noktası olarak hizmet edebilir. Kötü amaçlı uygulamaları tespit edebilir ve uygulama düzeyindeki protokolleri kısıtlayabilirler.
  • Anonimlik – Daha geniş bir anonimlik elde etmek için istekler proxy tarafından değiştirilebilir. Hassas bilgileri isteğinden çıkarabilir ve sadece önemli şeyleri bırakabilir. Sunucuya daha az bilgi gönderirken kullanıcı deneyimi de düşebilir, ancak bazen anonimlik daha önemli faktördür.
  • Erişim kontrolü – Oldukça basit, birçok sunucunun erişim denetimini tek bir proxy sunucu üzerinde merkezileştirebilirsiniz.
  • Önbelleğe alma – Popüler içeriği önbelleğe almak için proxy sunucusunu kullanabilirsiniz ve böylece yükleme hızlarını önemli ölçüde düşürebilirsiniz.
  • Yük dengeleme – “Pik trafiği” çok alan bir hizmetiniz varsa, iş yükünü daha fazla hesaplama kaynağına veya Web sunucularına dağıtmak için bir proxy kullanabilirsiniz. Zirve gerçekleştiğinde tek sunucunun aşırı yüklenmesini önlemek için yük dengeleyicileri trafiği yönlendirir.
  • Transcoding – İleti gövdesinin içeriğini değiştirme, proxy’nin sorumluluğu da olabilir

Görebildiğiniz gibi, vekiller çok yönlü ve esnek olabilir.

Caching

Web önbellekleri, istenen verilerin kopyalarını otomatik olarak üreten ve bunları yerel olarak saklayan aygıtlardır.

Bunu yaparak şunları yapabilirsiniz:

  • Trafiği azaltır
  • Ağ darboğazlarını ortadan kaldırır
  • Sunucu aşırı yüklenmesini önler
  • Uzun mesafelerde tepki gecikmesini azaltır

Dolayısıyla, Web ön belleklerinin hem kullanıcı deneyimini hem de Web sunucusu performansını iyileştirdiğini söyleyebilirsiniz. Ve elbette, potansiyel olarak daha çok para kazanabilirsiniz.

Önbellekten sunulan isteklerin bir kısmına Hız Oranı denir. 0’dan 1’e değişebilir, burada 0,% 0’dır ve 1,% 100 istekte bulunur. İdeal amaç elbette% 100 elde etmektir, ancak gerçek sayı genellikle% 40’a yakındır.

İşte temel Web önbellek iş akışının görünüşü:

İşte temel Web önbellek iş akışının görünüşü

Ağ geçitleri, Tüneller ve Relay

Zamanla, HTTP olgunlaştıkça insanlar onu kullanmanın birçok farklı yolunu buldular. HTTP, farklı uygulamalar ve protokolleri bağlamak için bir çerçeve olarak kullanışlı hale geldi.

Nasıl olduğunu görelim.

Ağ geçitleri

Ağ geçitleri, HTTP’nin bir kaynak almanın bir yolunu özetleyerek farklı protokoller ve uygulamalarla iletişim kurmasını sağlayabilecek donanım parçaları anlamına gelir. Bunlara protokol dönüştürücüleri denir ve çoklu protokollerin kullanılması nedeniyle yönlendiricilerden veya anahtarlardan çok daha karmaşıktır.

Örneğin, bir HTTP isteği göndererek dosyayı FTP üzerinden almak için bir ağ geçidi kullanabilirsiniz. Veya SSL üzerinden şifreli bir mesaj alabilir ve HTTP (Client-Side Security Accelerator Ağ Geçitleri) haline getirebilir veya HTTP’yi daha güvenli HTTP mesajlarına (Sunucu Taraflı Güvenlik Ağ Geçitleri) dönüştürebilirsiniz.

Tüneller

Tüneller CONNECT istek yöntemini kullanır. Tüneller, HTTP üzerinden HTTP olmayan verileri göndermeyi mümkün kılar. CONNECT yöntemi, tünelin hedef sunucuya bir bağlantı açmasını ve verileri istemci ile sunucu arasında geçirmeyi ister.

CONNECT istek örneği;

CONNECT api.github.com:443 HTTP/1.0
User-Agent: Chrome/58.0.3029.110
Accept: text/html,application/xhtml+xml,application/xml

CONNECT yanıtı;

HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1

CONNECT yanıtının normal bir HTTP yanıtının aksine Content-Type’ı belirtmesi gerekmez.

Bağlantı kurulduktan sonra, veriler doğrudan istemci ve sunucu arasında gönderilebilir.

Relay

Relay’ler, HTTP dünyasının kanunlarına aykırıdır ve HTTP yasalarına uymak zorunda değildirler. Bunlar, istek mesajlarındaki asgari bilgileri kullanarak bir bağlantı kurabildikleri sürece almış oldukları bilgiyi ileten vekillerin dumb-down versiyonlarıdır.

Tek amacı, olabildiğince az sorunla bir vekil uygulama ihtiyacını karşılamaktır. Bu aynı zamanda potansiyel olarak belaya da yol açabilir, ancak kullanımı çok kullanışlıdır ve Relay’ler kullanılırken dikkate alması gereken bir yarar oranı kesinlikle vardır.

Örümcekler (Web Crawler)

Arama Motorları - Web Crawler)

Yaygın olarak örümcek diye adlandırılan, World Wide Web üzerinde gezinen ve içeriğini dizine alan botlardır. Örümcekler, Arama motorlarının ve diğer birçok web sitesinin temel aracıdır.

Örümcekler tamamen otomatikleştirilmiş bir yazılım parçasıdır ve çalışması için insan etkileşimine gereksinim duymaz. Örümceklerin karmaşıklığı çok çeşitlilik gösterebilir ve bazı örümcekler oldukça karmaşık yazılım parçalarıdır (arama motorlarının yaptığı gibi).

Örümcekler, ziyaret ettikleri web sitesinin kaynaklarını tüketir. Bu nedenle, genel web siteleri, tarayıcılara web sitesinin hangi bölümlerini tarayacaklarını veya hiçbir şey taramayacaklarını söyleyecek bir mekanizmaya sahiptir. Bu, robots.txt (robot hariç tutma standardı) kullanılarak yapılabilir.

Tabii ki, bu sadece bir standart olduğundan, robots.txt, davetsiz örümceklerin web sitesini taramasını engelleyemez. Kötü niyetli robotlardan bazıları e-posta biçerdöverleri, spambotlar ve zararlı yazılımları içerir.

Robots.txt dosyalarının birkaç örneği:

User-agent: *
Disallow: /

Bu, tüm örümceklere dışarıda kalmalarını söyler.

User-agent: *
Disallow: /somefolder/
Disallow: /notinterestingstuff/
Disallow: /directory/file.html

Bu sadece belirli dizinlere ve tek bir dosyaya atıfta bulunur.

User-agent: Googlebot
Disallow: /private/

Bu durumda olduğu gibi belirli bir örümceği (Google Botu) engelleyebilirsiniz.

World Wide Web’in geniş doğası göz önüne alındığında, şimdiye kadarki en güçlü örümcekler bile tamamını tarayıp endeksleyemez. Bu nedenle, seçim politikasını, en alakalı bölümlerini taramak için kullanıyorlar. Ayrıca, WWW sık sık ve dinamik olarak değişir, bu nedenle örümceklerin web sitelerini tekrar ziyaret etip gerekmediğini hesaplamak için tazelik politikasını kullanmaları gerekir. Örümcekler, sunucuları çok fazla hızlı talep ederek kolayca zorlayabilirler, bu nedenle de bir nazik politika uygulanır. Bilinen örümceklerin çoğu, sunucudaki yükü üretmekten kaçınmak için sunucuları yoklamak için 20 saniyelik aralıklarla 3-4 dakikalık aralıklarla çalışırlar.

Gizemli ve kötü derin web veya karanlık web haberini duymuş olabilirsiniz. Web’in bir parçası değildirler, bilgiyi gizlemek için kasıtlı olarak arama motorları tarafından dizine eklenmiyorlar.

Sonuç

Şimdi, HTTP’nin nasıl çalıştığına dair daha iyi bir resme sahip olmalısınız ve isteklere, yanıtlara ve durum kodlarına göre çok daha fazlasını bulacaksınız. HTTP’nin, bir uygulama protokolü olarak potansiyelini elde etmek için kullandığı farklı donanım ve yazılım parçaları içeren bir bütün altyapı vardır.

Bu makalede bahsettiğim her kavram, tüm makaleyi veya bir kitabı bile kapsayacak kadar büyük. Hedefim, sizi nasıl kabaca birbirinden farklı fikirlerle buluşturmaktı, böylece hepsinin nasıl bir araya geldiğini ve ihtiyaç duyulduğunda neye bakacağını biliyorsunuz.

Açıklamaların bazılarını biraz kısa ve belirsiz bulduysanız ve önceki makalelerimi kaçırdıysanız, serinin 1. bölümünü ve HTTP’nin temel kavramları hakkında konuştuğum HTTP referansını ziyaret ettiğinizden emin olun.

Okuduğunuz için teşekkürler ve sunucuların istemcileri tanımlamak için kullanabileceği farklı yolları açıkladığım dizinin 3. bölümüne bakmaya devam edin.

Bu makaleyi kullanışlı buluyorsanız  lütfen bir açıklama bırakın.

Bir sonraki ders: HTTP Dersleri – Ders 3 – İstemci Kimliği

Referanslar;

Orijinal Yazı: https://www.code-maze.com/http-series-part-2/

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

Bu yazıda size HTTP temellerini sunacağım.

Ama neden HTTP?

Kendinize sorabileceğiniz HTTP hakkında neden okumalıyım?

Bir yazılım geliştiricisi iseniz, nasıl iletişim kurduğunu öğrenerek, daha iyi uygulamaları nasıl yazacağınızı anlayacaksınız. Sistem mimarı veya ağ yöneticisiyseniz, karmaşık ağ mimarileri tasarlama konusunda daha derin bilgi sahibi olursunuz.

Günümüzde çok önemli mimari tarz olan REST, tamamen HTTP özelliklerini kullanmaya dayanıyor; bu nedenle HTTP’yi anlamayı daha da önemli hale getiriyor. Harika RESTFULL uygulamalar yapmak istiyorsanız öncelikle HTTP’yi anlamalısınız.

Yani, World Wide Web ve ağ iletişiminin ardındaki temel kavramları anlama ve öğrenme şansını tepmek mi istiyorsun?

Umarım istemiyorsundur ?

Makalenin odak noktası, HTTP’nin en önemli bölümlerini mümkün olan en basit şekilde açıklamak üzerine olacak. Buradaki düşünce, HTTP ile ilgili tüm yararlı bilgileri tek bir yerde organize etmektir; böylece, ihtiyaç duyduğunuz bilgileri bulmak için kitaplara ve RFC’lere gitme zamanınızı kurtarabilirsiniz.

Bu makalede neler öğreneceksiniz?

  • HTTP tam olarak nedir
  • Kaynaklar
  • Web İstemcisi ve Web Sunucusu arasındaki bilgiler nasıl aktarılır
  • Mesajlar ve bazı mesaj örnekleri
  • MIME türleri
  • Talep Yöntemleri
  • Başlıkları
  • Durum kodları

Daha fazla ado olmadan, içeriye girelim.

HTTP tanımı

HTTP’nin kurucusu Tim Berners-Lee (aynı zamanda World Wide Web’in mucidi olduğu düşünülen adam). HTTP’nin geliştirilmesi için önemli olan diğer isimler arasında da REST mimari stilinin yaratıcısı Roy Fielding var.

Köprü Metni Aktarım Protokolü (Hyper-Text Transfer Protocol), uygulamaların birbirleriyle iletişim kurmak için kullandığı protokoldür. Özünde, HTTP, tüm internetteki medya dosyalarını istemciler ve sunucular arasında iletmekle görevlidir. HTML, görüntüler, metin dosyaları, filmler ve bunlar arasındaki her şeyi içerir ve bunu hızlı, güvenilir bir şekilde yapar.

HTTP, uygulama katmanındaki iletişim için kullanıldığından, uygulama protokolüdür, aktarım protokolü değildir. Burada belleğinizi tazelemek için netmork katmanlarına bakalım;

Kaynaklar

İnternetteki her şey bir kaynaktır ve HTTP kaynaklar ile çalışır. Bu dosyalar, akışlar, hizmetler ve her şeyi içerir. HTML sayfası bir kaynaktır, youtube videonuz bir kaynaktır, günlük sayfanızdaki bir web uygulamasındaki e-tablonuzu bir kaynaktır… olayı anladınız.

Fakat bir kaynaktan diğerini nasıl ayırt edersiniz?

Onlara bir URL vererek (Uniform resource locators).

URL, tarayıcınızın kaynağı bulabileceği benzersiz yere işaret eder.

Web İstemcisi ve Web Sunucusu arasındaki iletiler nasıl değişir

Her içerik parçası, her kaynak Web sunucusunda (HTTP sunucusu) bulunur. Bu sunucular, bu kaynakları sağlamak için bir HTTP isteği beklemektedir.

Ancak nasıl Web sunucusundan bir kaynak isteğinde bulunuyorsunuz?

Elbette bir HTTP istemcisine ihtiyacınız var ?

Bu makaleyi okumak için şu anda bir HTTP istemcisi kullanıyorsunuz. Web tarayıcıları HTTP istemcileridir. Kaynakları bilgisayarınıza almak için HTTP sunucularıyla iletişim kurarlar. En popüler istemcilerden bazıları Google Chrome, Mozilla Firefox, Opera, Apple’ın Safari ve ne yazık ki hala rezil Internet Explorer.

Mesajlar ve bazı mesaj örnekleri

Peki, HTTP mesajı nasıl görünüyor?

Çok fazla konuşmadan, HTTP mesajlarına bazı örnekler verelim:

GET İsteği

GET /repos/CodeMazeBlog/ConsumeRestfulApisExamples HTTP/1.1
Host: api.github.com
Content-Type: application/json
Authorization: Basic dGhhbmtzIEhhcmFsZCBSb21iYXV0LCBtdWNoIGFwcHJlY2lhdGVk
Cache-Control: no-cache

Post İsteği

POST /repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks?access_token=5643f4128a9cf974517346b2158d04c8aa7ad45f HTTP/1.1
Host: api.github.com
Content-Type: application/json
Cache-Control: no-cache
 
{
  "url": "http://www.example.com/example",
  "events": [
    "push"
  ],
  "name": "web",
  "active": true,
  "config": {
    "url": "http://www.example.com/example",
    "content_type": "json"
  }
}

İşte bir GET ve bir POST isteği örneği. Bu isteklerin farklı kısımlarını hızla gözden geçirelim.

Talebin ilk satırı, talep hattı için ayrılmıştır. İstek yöntemi adı, istek URI’si ve HTTP sürümünden oluşur.

Sonraki birkaç satır istek üstbilgilerini temsil etmektedir. İstek başlıkları, istekte bulunan içerik türleri, yanıtta beklenen içerik, yetkilendirme bilgileri vb. Gibi ek bilgi sağlar;

GET isteği için hikaye burada bitiyor. POST isteğinde ayrıca bir gövde olabilir ve gövde mesajı şeklinde ek bilgi taşıyabilirsiniz. Bu durumda, URI’de belirtilen verilen repo için GitHub web kancasının nasıl oluşturulması gerektiği konusunda ek bilgi içeren bir JSON mesajıdır. Bu mesaj, web kağıdının oluşturulması için gereklidir, bu nedenle bu bilgileri GitHub API’sine sunmak için POST isteği kullanıyoruz.

İstek hattı ve istek başlıkları, <CR> <LF> (satır başı ve satır besleme \r \n) tarafından takip edilmeli ve ileti üstbilgileri ile ileti gövdesi arasında yalnızca CRLF içeren tek bir boş satır bulunmalıdır.

HTTP isteği için referans: https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

Ve bu isteklere cevap olarak ne alacağız?

Yanıt mesajı

HTTP/1.1 200 OK
Server: GitHub.com
Date: Sun, 18 Jun 2017 13:10:41 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Status: 200 OK
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4996
X-RateLimit-Reset: 1497792723
Cache-Control: private, max-age=60, s-maxage=60
 
[
  {
    "type": "Repository",
    "id": 14437404,
    "name": "web",
    "active": true,
    "events": [
      "push"
    ],
    "config": {
      "content_type": "json",
      "insecure_ssl": "0",
      "url": "http://www.example.com/example"
    },
    "updated_at": "2017-06-18T12:17:15Z",
    "created_at": "2017-06-18T12:03:15Z",
    "url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404",
    "test_url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/test",
    "ping_url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/pings",
    "last_response": {
      "code": 422,
      "status": "misconfigured",
      "message": "Invalid HTTP Response: 404"
    }
  },
]

Yanıt mesajı, ilk satırın yanıt durumu hakkında taşıdığı bilgi hariç, istekle hemen hemen aynı şekilde yapılandırılmıştır. ?

Durum satırı, yanıt başlıkları ve yanıt gövdesi tarafından izlenir.

HTTP yanıtı için referans: https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

MIME türleri

MIME türleri internetteki dosya türlerini tanımlamak için standart bir yol olarak kullanılır. Tarayıcınız bir MIME türleri listesine sahiptir ve web sunucuları için de aynı şey geçerlidir. Bu şekilde, dosyalar işletim sisteminden bağımsız olarak aynı şekilde aktarılabilir.

Aslında multimedya e-postası için geliştirildikleri için MIME, Çok Amaçlı İnternet Posta Uzantısı anlamına gelir. O zamandan beri HTTP ve diğer pek çok protokol için kullanılmak üzere uyarlandılar.

Her MIME türü, bir tür, alt türü ve aşağıdaki biçimde isteğe bağlı parametrelerin bir listesinden oluşur: type / subtype; Isteğe bağlı parametreler.

İşte birkaç örnek:

Content-Type: application/json
Content-Type: text/xml; charset=utf-8
Accept: image/gif

Sık kullanılan MIME türlerinin ve alt türlerinin listesini HTTP referansında bulabilirsiniz.

İstek Yöntemleri

HTTP istek yöntemleri (“eylemler” de denir), kaynak üzerinde gerçekleştirilecek eylemi tanımlar. HTTP, en çok bilinen / kullanılan GET ve POST yöntemleri olan birkaç istek yöntemi tanımlar.

Bir istek yöntemi idempotent veya idempotent olmayabilir. Bu, yöntemin aynı kaynaklarda birkaç kez çağrılmasının güvenli / güvensiz olduğunu açıklayan basit bir terimdir. Başka bir deyişle, bu, yalnızca bilgi alma özelliğine sahip olan GET yönteminin varsayılan olarak idempotent olması gerektiği anlamına gelir. Aynı kaynaktaki GET’in tekrar tekrar çağırılması farklı bir yanıtla sonuçlanmamalıdır. Öte yandan POST yöntemi idempotent bir yöntem değildir.

HTTP / 1.1 öncesinde yalnızca üç yöntem vardı: GET, POST ve HEAD ve HTTP / 1.1’in belirtimi oyuna birkaçını daha getirdi: OPTIONS, PUT, DELETE, TRACE ve CONNECT.

Bu yöntemlerin her birinin ne yaptığını HTTP Referansında daha fazla bulabilirsiniz.

Başlıklar

Başlık alanları, istek veya yanıt mesajının ilk satırından hemen sonra bulabileceği iki nokta üstüste ayrılmış ad-değer alanlarıdır. Bunlar, HTTP mesajlarına daha fazla bağlam sağlarlar ve istemcilerin ve sunucuların, talebin veya yanıtın niteliği hakkında uygun şekilde bilgilendirilmesini sağlarlar.

Toplamda beş tür üstbilgi var:

  • Genel başlıklar: Bu üstbilgiler hem sunucu hem de istemci için yararlıdır. İyi bir örnek, mesajın oluşturulma zamanı ile ilgili bilgileri sağlayan tarih başlık alanını içerir.
  • İstek başlıkları: İstek mesajlarına özgü. Sunucuya ek bilgi sağlamaktadırlar. Örneğin, Kabul Et: * / * başlık alanı sunucuyu, istemcinin herhangi bir ortam türünü almaya istekli olduğunu bildirir.
  • Yanıt başlıkları: Yanıt mesajlarına özgü. İstemciye ilave bilgi sağlarlar. Örneğin, İzin ver: GET, HEAD, PUT üstbilgi alanı, istemciye hangi yöntemlerin istenen kaynak için izin verildiğini bildirir.
  • Varlık üstbilgileri: Bu üstbilgiler varlığın gövdesiyle ilgilidir. Örneğin, Content-Type: text / html header, uygulamanın verilerin HTML belgesi olduğunu bilmesini sağlar.
  • Genişletme üstbilgileri: Bunlar, uygulama geliştiricileri tarafından oluşturulan standart olmayan üstbilgilerdir. HTTP’nin bir parçası değil, ancak tolere edilmeleri gerekir.

Sıkça kullanılan istek ve yanıt başlıklarının listesini HTTP Referansında bulabilirsiniz.

Durum Kodları

Durum kodu, bir isteğin sonucunu gösteren üç basamaklı bir sayıdır. Bunu, insan tarafından okunabilir olan neden açıklaması takip eder.

Bazı örnekler şunları içerir:

  • 200 Başarılı.
  • 404 Bulunamadı
  • 500 Sunucu Hatası

Durum kodları, beş farklı gruptaki aralıklarla sınıflandırılır.

Hem durum kodu sınıflandırması hem de durum kodlarının tümü ve anlamları HTTP Referansında bulunabilir.

Sonuç

Phew, çok fazla bilgi oldu.

HTTP öğrenerek kazandığınız bilgi, doğrudan bazı problemi çözmenize yardımcı olan tür değildir. Ancak size, HTTP’den daha üst düzeydeki neredeyse her problem için uygulayabileceğiniz internet iletişiminin temel ilkesini anlayacaksınız. İster REST API’ler, web uygulaması geliştirme veya ağ olsun, şimdi bu tür sorunları çözerken en azından biraz daha emin olabilirsiniz.

Tabii ki, HTTP konuşmak için oldukça büyük bir konudur ve hala temel konulardan çok daha fazlası var.

HTTP serisinin 2. bölümünde HTTP’nin mimari yönlerini okuyabilirsiniz.

Bu makale size yardımcı oldu mu? Lütfen yorum bırakın ve bana bildirin.

Bir sonraki ders: HTTP Dersleri – Ders 2 – Mimari Yönleri

Referanslar:

Orjinal Yazı: https://www.code-maze.com/http-series-part-1/