Diğer sözlüklerde "HTTP"nin ne olduğunu görün. HTTP protokolü - Köprü Metni Aktarım Protokolü nedir

HTTP veya Köprü Metni Aktarım Protokolü (dünya çapında ağın) ana deliğidir. Protokolün ana görevi, ağda köprü metninin iletilmesini sağlamaktır. Protokol, istemci ve sunucu alışverişi için mesaj biçimini doğru bir şekilde tanımlar.

RFC 2616'da (HTTP1.1) HTTP protokolü açıklanmıştır.

Protokolün temeli, bir ASCII isteği ve buna bir sonraki yanıtı RFC 822 MIME standardında kullanarak istemci ve sunucu arasında etkileşim sağlamaktır.

Pratikte HTTP, 80 numaralı bağlantı noktası temelinde çalışır, ancak farklı şekilde yapılandırılabilir. TCP / IP isteğe bağlı olmasına rağmen, mesajların ayrıştırılması ve yeniden birleştirilmesiyle ilgilendiğinden ve tarayıcıyı veya sunucuyu "zorlamadığından" tercih edilen seçenek olmaya devam etmektedir.

HTTP protokolünün sadece web teknolojilerinde değil, diğer OOP uygulamalarında da (objektif yönelimli) kullanılabileceği unutulmamalıdır.

URL'si

İstemci-sunucu web iletişiminin temeli istektir. İstek, İnternetin Tekdüzen Kaynak Bulucusu olan URL kullanılarak gönderilir. Size bir URL'nin ne olduğunu hatırlatayım.

Temiz ve basit bir URL yapısı aşağıdaki unsurlardan oluşur:

• Protokol;
• Ev sahibi;
• Liman;
• Kaynak sedyesi;
• Etiketler (Talep).

Not: http protokolü, basit, güvenli olmayan bağlantılar için bir protokoldür. Güvenli bağlantılar, https protokolünü kullanarak çalışır. Veri alışverişi yapmak daha güvenlidir.

HTTP istek yöntemleri

URL parametrelerinden biri, iletişim kurmak istediğimiz ana bilgisayarın adını tanımlar. Ama bu yeterli değil. Yapılacak işlemin belirlenmesi gerekmektedir. Bu, HTTP protokolü tarafından tanımlanan bir yöntem kullanılarak yapılabilir.

HTTP yöntemleri

• Yöntem / Açıklama
• HEAD / Bir web sayfasının başlığını okuyun
• GET / Bir web sayfasını okuyun
• POST / Web sayfasına ekle
• PUT / Web sayfasını kaydet
• İZLE / isteği geri gönder
• SİL / Web sayfasını sil
• SEÇENEKLER / Seçenekleri göster
• CONNECT / Gelecekte kullanılmak üzere ayrılmıştır

HTTP yöntemlerine daha ayrıntılı bir göz atalım

GET yöntemi. MIME standardına göre kodlanmış bir sayfa (dosya, nesne) ister. Bu en yaygın kullanılan yöntemdir. Yöntem yapısı:
GET dosya adı HTTP / 1.1

HEAD yöntemi. Bu yöntem, mesajın başlığını ister. Bu durumda sayfa yüklenmez. Bu yöntem, sayfa önbelleğini yönetmek için gerekli olan sayfanın en son ne zaman yenilendiğini öğrenmenizi sağlar. Bu yöntem, istenen URL'nin işlevselliğini test etmenize olanak tanır.

PUT yöntemi. Bu yöntem, sayfayı sunucuya itebilir. PUT istek gövdesi, MIME kodlu barındırılan sayfayı içerir. Bu yöntem, istemci kimliği gerektirir.

POST yöntemi. Bu yöntem, mevcut bir sayfaya içerik ekler. Bir forum gönderisi eklemek için örnek olarak kullanılmıştır.

DELETE yöntemi. Bu yöntem sayfayı yok eder. Silme yöntemi, kullanıcının silme haklarının onaylanmasını gerektirir.

İZLEME yöntemi. Bu yöntem hata ayıklamadır. Sunucuya isteği geri göndermesini söyler ve sunucudan döndüğünde istemcinin isteğinin hatalı biçimlendirilip biçimlendirilmediğini size bildirir.

BAĞLANTI yöntemi- rezerv yöntemi, kullanılmaz.

SEÇENEKLER yöntemi herhangi bir dosyanın sunucu özelliklerini ve özelliklerini sorgulamanıza olanak tanır.

İstemci ve sunucu arasındaki "istek-yanıt" iletişiminde, sunucu mutlaka bir yanıt üretir. Bir web sayfası veya durum kodu içeren bir durum çubuğu olabilir. Durum kodu sizin tarafınızdan iyi bilinmektedir. Kodlardan biri bilinen kod 404 - Sayfa bulunamadı.

Durum kodu grupları

1xx: Sunucu hazır, Kod 100 - sunucu, istemci isteklerini işlemeye hazır;

2xx: Başarı.

• Kod 200 - istek başarıyla işlendi;
• Kod 204 - İçerik Yok.

3xx: Yönlendirme.

• Code 301 - İstenen sayfa taşındı;
• Kod 304 - Önbellekteki sayfa hala alakalı.

4xx: İstemci hatası.

Merhaba blog sitesinin sevgili okuyucuları. İnternetin doğru işleyişinden sorumlu mekanizmayı incelerken, şüphesiz HTTP veri aktarım protokolünü ve güvenli HTTPS sürümünü içeren ana yönlerine zaman ayırma ihtiyacından kurtulamazsınız.

Kullanıcının tarayıcısının bilgi almak için gerekli dosya ve belgeleri açmasını sağlayan bu aracın çalışmasının temeli, detayları aşağıda bu makalede ele alınacak olan "istemci-sunucu" teknolojisidir.

Tabii ki, faaliyetlerini gerçekten bilgisayar ağlarıyla çalışmaya ve ağ programları geliştirmeye adamak isteyenler, uygun nitelikleri elde etmek için bu konuyu maksimum düzeyde incelemeniz gerekir. Ama buna ihtiyacımız yok.

Ana şey, genel anlamda HTTP'nin ne olduğunu ve HTTPS'nin temel özelliklerinin neler olduğunu anlamak ve bunların içinde yer alan temel ilkeleri kavramak. Bu tür bilgiler, diğer şeylerin yanı sıra, sitenizin optimizasyonu ve tanıtımı için faydalı olacaktır, bu ve bu konuyla ilgili sonraki makalelerden koşulsuz onay alacaksınız.

HTTP nedir ve nasıl çalışır?

İnternette gerekli belgeyi almak için, kullanıcının HTTP (veya HTTPS) protokolünün adını içeren tarayıcının arama çubuğuna (url'lerin yapısı hakkında ayrıntılar) gerekli URL'yi girmesi yeterlidir.

3. HTTP / Sürüm- protokolün mevcut değişikliği belirtilir. Şu anda HTTP 1.1'dir (spesifikasyonunu kontrol edebilirsiniz). Bununla birlikte, taslak biçiminde, protokol 2.0'ın bir sonraki sürümü zaten var ve bu sürüme dayanıyor.

Alt satırda Ana bilgisayar başlığı DNS'den alınan IP'ye göre tarayıcı tarafından sunucuya gönderilen bir HTTP isteğinin parçası olarak. Bu ne için? Web sunucularında genellikle birden fazla kaynak bulunduğundan istenen siteyi belirlemek.

Geçtiklerimizi pekiştirmek için açıklayıcı bir örneğe bakalım. Diyelim ki tarayıcı, kullanıcıdan aşağıdaki adrese sahip bir sayfa görüntülemek için bir "görev" aldı:

Http://subscribe.ru/group/

Ardından, GET yöntemi aracılığıyla HTTP isteği aşağıdaki gibi oluşturulabilir (bu durumda, mesaj gövdesi genellikle eksiktir):

GET / grup / HTTP / 1.1 Ana Bilgisayar: abone.ru

Açıklık sağlamak için, bir Host başlığı dahil olmak üzere yalnızca en basit örneği sağladım, aslında bunlardan birkaçı olabilir. Ama hepsi bu değil. Gerçekten de, tam teşekküllü bir iletişim için, sunucunun bir tarayıcı isteğine yanıt vermesinden sonra kurulan bir diyalog gereklidir. Cevabın ilk satırı şematik olarak da gösterilebilir:

HTTP / Sürüm Durum Kodu Açıklama

Şimdi sunucu yanıtının bileşimini kısaca gözden geçirelim:

1. HTTP sürümü talebe benzetilerek belirtilir.

2. Durum kodu(Durum Kodu) - tarayıcı tarafından istenen belgenin durumu hakkında bilgi veren üç basamak. Örneğin, 200 - Tamam, sayfa var ve tarayıcıda görüntülenecek, 301 - başka bir url'ye yönlendirildi, - bu adreste web sayfası yok (silinmiş veya kullanıcı URL'yi girerken bir hata yapmış olabilir) ).

3. Açıklama(Sebep İfadesi) - yanıt koduna ekleme metni. Bazı durumlarda, açıklama standarttan farklı olabilir veya tamamen mevcut olmayabilir. Bu, diğer şeylerin yanı sıra sunucuda barındırılan yazılımın yapılandırmasından kaynaklanmaktadır.

Gerçek bir örnek mi? Lütfen. Yukarıda örnek olarak verdiğim isteğe sunucu yanıtını almaya çalışalım (url "http://subscribe.ru/group/"). Şöyle görünecek (başlıklı ilk satır):

HTTP / 1.1 200 Tamam Sunucu: nginx Tarih: 10 Haziran 2017 Cts 06:36:38 GMT İçerik Türü: metin / html; charset = utf-8 Bağlantı: canlı tut İçerik-Dil: tr Set-Cookie: Abone Ol :: Viziter = UQkivlk7k3YO3DgjAxM2Ag ==; sona eriyor = Per, 31-Ara-37 23:55:55 GMT; etki alanı = abone.ru; yol = / P3P: policyref = "/ w3c / p3p.xml", CP = "NOI PSA BUS UNIT'İMİZ"

Bu durumda, GET yöntemini kullanırken örneğin istenen belgenin (web sayfası) HTML kodunu içerebilen mesajın açıklaması ve gövdesi yoktur. Bu bölümler, istemci uygulamasının türüne bağlı olarak mevcut olabilir.

Bu nedenle, yukarıdakileri kısaca özetleyelim. Kullanıcı, içeriğini görüntülemek için almak amacıyla istenen sayfanın url'sini girerse, tarayıcı gerekli sunucuya bir GET isteği gönderir ve bir yanıt alır. Bu iletişimin bir sonucu olarak, (uygun koşullar altında) istenen belgenin içeriği görüntülenecek veya görüntülenmeyecektir.

Her durumda, sunucunun HTTP yanıtının içeriği (durum kodu dahil), istenen belgeyle ilgili yararlı bilgiler sağlayabilir.

Yukarıdaki bilgilerin bulmacaya kolayca sığması için belirli bir örnek eksik. HTTP Başlıkları adı verilen bir tanesinin (bu belirli web tarayıcısı benim çalışma aracımdır) yardımıyla ona bakacağız.

"Bir şişede" içerik sağlayan "istemci-sunucu" etkileşiminin tam bir resmini vermesi açısından uygundur. HTTP isteği ve yanıtı... Blogumun bir sayfasından diğerine bir bağlantıyı takip ederken bu eklentinin hangi belgeyi oluşturduğuna bakın:

Burada, en üstte, tarayıcının sunucuya eriştiği GET yöntemi ve ayrıca 200 OK durum koduyla işaretlenen sayfa durumu, sunucunun istenen ile ilgili tüm verileri ilettiğini açıkça gösterir. web sayfası.

Ayrıca ilgi HTTP Başlıkları aşağıda gösterilen. Örneğin, öğe "Yönlendiren" geçişin yapıldığı yerden bir url şeklinde bilgi verir.

başlık "Kullanıcı Aracısı" yalnızca isteği web sunucusuna gönderen istemci uygulamasını yansıtır. Bu durumda, bu bir tarayıcıdır, ancak başkaları da olabilir (mobil cihazlar, arama robotları vb.). Kullanıcı Aracısında sağlanan veriler, istekte bulunan uygulamayı tanımlamak için sunucu yazılımı tarafından gereklidir.

Sadece arama motoru botları Sıralamayı etkileyen bilgileri elde etmek için sitelerin sayfalarını taramak, öncelikle ilgileniyoruz, çünkü tam olarak belirli bir sayfanın kaderine, tanıtımının etkinliği açısından nasıl karar verdiklerine.

Bu nedenle bir sonraki yayında, SEO kaynak optimizasyonu ışığında web yöneticileri için son derece önemli olan robotun isteğine özel olarak HTTP başlıklarının nasıl görüntüleneceği ve sunucu yanıt kodlarının nasıl kontrol edileceği üzerinde daha ayrıntılı olarak durmayı planlıyorum. Bu nedenle, en son makaleyi zamanında almak için abone olun.

Güvenli HTTPS protokolü hakkında özel olan nedir?

Yeni başlayanlar da dahil olmak üzere tüm İnternet kullanıcılarının, aktarımlarının kullanıldığı hizmetlerde (ödeme sistemleri, çevrimiçi mağazalar, büyük özel) kişisel verileri korumaya hizmet eden özel bir HTTPS protokolü (Güvenli Köprü Metni Aktarım Protokolü) varlığından haberdar olduklarından eminim. portallar, vb.) vb.).

Benzer bir sitenin sayfa adresini girerseniz, bu bağlantı özel bir şekilde işaretlenecektir. Google Chrome'da (), örneğin, "Güvenli" yazılı bir kilit yeşil renkte görüntülenecek, üzerine tıkladığınızda kişisel verilerin korunmasıyla ilgili bazı bilgiler göreceksiniz:

HTTPS nedir? Kesin konuşmak gerekirse, bu tek başına bir protokol değildir. Bu, mekanizmalar aracılığıyla çalışan standart HTTP'dir. TLS veya SSL davetsiz misafirler tarafından gizli verilerin ele geçirilmesini ve alınmasını hariç tutan şifrelemeyi garanti edebilir.

Varsayılan olarak, güvenli protokol çalışırken 443 numaralı bağlantı noktası kullanılır (hatırlarsanız standart HTTP için 80'dir). HTTPS'de şifreleme için 40, 56, 128 ve 256 bitlik () anahtar uzunlukları kullanılır. Ancak ilk iki seçenek yeterli düzeyde güvenlik sağlayamadıklarından dikkate almaya bile değmez.

Son zamanlarda arama motorları, özellikle Google, tüm sitelerin sahiplerini güvenli bir protokole geçmeye ikna etmekte ve bu anın sıralama yaparken dikkate alınacağını ustaca ima etmektedir. Sonuç olarak, artık yalnızca kişisel verilerin aktarımıyla yakından ilgili siteler değil, birçok kaynak (hatta normal bloglar) zaten HTTPS ile çalışıyor.

Dahası, önde gelen barındırıcılar, güvenli bir bağlantı sağlamak için gerekli olan güvenli bir SSL sertifikası satın almayı teklif ediyor.

Elbette, çok sayıda bulunan HTTP (HTTPS) protokolünü kullanmanın tüm nüanslarını dikkate almadık. Bu konu bazı etkileyici dersler alabilir. Bununla birlikte, hem ileri düzey bir kullanıcı hem de bir web yöneticisi için yararlı olan ana yönler ele alınmaktadır. Alınan bilgi miktarından hala memnun değilseniz, özellikle yöntemlerin daha ayrıntılı olarak tartışıldığı aşağıdaki video dersinden kolayca tamamlayabilirsiniz:

Köprü Metni Aktarım Protokolü (HTTP) Hiper ortamın dağıtılmış bilgi sistemleri için gerekli olan gerekli veri aktarım hızını sağlayan üst düzey (yani uygulama katmanı) bir protokoldür. HTTP, 1990'dan beri World Wide Web projesi tarafından kullanılmaktadır.

Pratik bilgi sistemleri, ilkel veri alma, değiştirme ve açıklamalardan daha fazlasını gerektirir. HTTP / 1.0, bir isteğin amacını belirtmek için kullanılabilecek açık bir dizi yöntem sağlar. Belirli bir yöntemin uygulanması gereken kaynağı belirtmek için bir konum (URL) veya ad (URN) biçiminde bir Evrensel Kaynak Tanımlayıcısının (URI) kullanıldığı referans disiplini üzerine inşa edilmiştir. İleti biçimi, İnternet Postası veya Çok Amaçlı İnternet Posta Uzantılarına benzer.

HTTP / 1.0 ayrıca çeşitli kullanıcı görüntüleyicileri ve ağ geçitleri arasında iletişim için kullanılır ve SMTP, NNTP, FTP, Gopher ve WAIS gibi mevcut İnternet protokollerine hiper ortam erişimi sağlar. HTTP / 1.0, proxy sunucular aracılığıyla bu tür ağ geçitlerinin daha önce bahsedilen protokolleri kullanarak herhangi bir kayıp olmadan veri aktarımına izin verecek şekilde tasarlanmıştır.

Genel yapı

HTTP, istek/yanıt paradigmasına dayanır. İstekte bulunan bir program (genellikle istemci olarak adlandırılır) bir alıcı hizmet programıyla (genellikle sunucu olarak adlandırılır) iletişim kurar ve sunucuya şu biçimde bir istek gönderir: istek yöntemi, URI, protokol sürümü, ardından isteği içeren MIME benzeri bir mesaj kontrol bilgileri, müşteri hakkındaki bilgiler ve belki de mesajın gövdesi. Sunucu, bir durum satırı (protokol sürümü ve durum kodu - başarı veya hata dahil) içeren bir mesajla yanıt verir, ardından sunucu hakkında bilgiler, yanıtın içeriği hakkında meta bilgiler ve muhtemelen yanıt içeren MIME benzeri bir mesaj gelir. vücudun kendisi. Bir programın aynı anda hem istemci hem de sunucu olabileceği unutulmamalıdır. Bu metinde bu terimlerin kullanımı, programın genel işlevlerine değil, yalnızca bu özel iletişim oturumu sırasında program tarafından gerçekleştirilen role atıfta bulunur.

İnternette iletişim genellikle TCP/IP protokollerine dayanır. WWW için varsayılan bağlantı noktası numarası TCP 80'dir, ancak diğer bağlantı noktası numaraları da kullanılabilir - bu, HTTP'yi üst katman protokolü olarak kullanma olasılığını dışlamaz.

Çoğu uygulamada, her istek için istemci tarafından bir iletişim oturumu açılır ve isteğe verilen yanıt sona erdiğinde sunucu tarafından kapatılır. Ancak, bu protokolün bir özelliği değildir. Hem istemci hem de sunucu, örneğin bazı kullanıcı eylemlerinin bir sonucu olarak oturumu kapatabilmelidir. Her durumda, taraflardan birinin başlattığı bir bağlantı kesme durumu, durumu ne olursa olsun mevcut talebi kesintiye uğratır.

Genel konseptler

İstek, bir istemciden sunucuya gönderilen bir mesajdır.
Bu mesajın ilk satırı, istenen kaynağa uygulanacak yöntemi, kaynak tanımlayıcısını ve kullanılan protokol sürümünü içerir. HTTP / 0.9 protokolü ile uyumluluk için iki HTTP istek formatı vardır:

Sorgu = Basit Sorgu | Full-Request Simple-Request = "GET" SP Request-URI CRLF Full-Request = String-Status * (Genel-Başlık | İstek-Başlığı | İçerik-Başlığı) CRLF [İstek-İçerik]

Bir HTTP / 1.0 sunucusu bir Basit İstek alırsa, bir HTTP / 0.9 Basit Yanıt ile yanıt vermelidir ZORUNLU. Tam Yanıtı işleyebilen bir HTTP / 1.0 istemcisi asla Basit İstek göndermemelidir.

Hat Durumu

Durum satırı, yöntemin adının yer aldığı bir satırla başlar, ardından İstek URI'si ve kullanılan protokolün sürümü gelir. Durum satırı CRLF karakterleriyle biter. Çizgi elemanları boşluklarla (SP) ayrılır. Sondaki CRLF dizisi dışında Durum Satırında LF ve CR karakterlerine izin verilmez.

Dize-Durumu = Yöntem SP İsteği-URI SP HTTP-Sürüm CRLF

Tam İstek Durum Dizesi ile Basit İstek Durum Dizesi arasındaki farkın, HTTP Sürümü alanının varlığı olduğuna dikkat edilmelidir.

Yöntem

Yöntem alanı, İstek-URI tarafından tanımlanan kaynağa uygulanacak yöntemi belirtir. Yöntem adları büyük/küçük harfe duyarlıdır. Mevcut yöntem listesi genişletilebilir.

Yöntem = "GET" | "KAFA" | "PUT" | "POSTA" | "SİL" | "BAĞLANTI" | "BAĞLANTIYI ÇIKAR" | ek yöntem

Belirli bir kaynak tarafından izin verilen yöntemlerin listesi, "Puanlar"ın Başlık-İçerik alanında belirtilebilir. Ancak, istemci, farklı yöntemlerin geçerliliği dinamik olarak değişebileceğinden, belirli bir yöntemin belirtilen kaynağa uygulanıp uygulanmayacağı yanıt durum kodu aracılığıyla sunucu tarafından her zaman uyarılır. Bu yöntem sunucu tarafından biliniyorsa ancak belirtilen kaynak için izin verilmiyorsa, sunucu "405 Yönteme İzin Verilmiyor" durum kodunu ve yöntem bilinmiyorsa veya desteklenmiyorsa "501 Uygulanmadı" durum kodunu döndürmelidir. bu sunucu tarafından. Ortak HTTP / 1.0 yöntemleri aşağıda açıklanmıştır.

ELDE ETMEK

GET yöntemi, İstek URI'si tarafından tanımlanan herhangi bir bilgiyi almak için kullanılır. İstek URI'si veri yayınlayan bir sürece atıfta bulunuyorsa, yanıt süreç kodunun kendisi değil (bu sürecin çıktısı olmadığı sürece) o süreç tarafından oluşturulan veriler olacaktır.

İstek mesajı bir "If-Modified-Since" başlık alanı içeriyorsa, GET yöntemi "koşullu GET" olarak değiştirilir. Koşullu bir GET'e yanıt olarak, istenen kaynağın gövdesi yalnızca If-Modified-Since başlığında belirtilen tarihten sonra değiştiyse gönderilir. Bunu belirleme algoritması aşağıdaki durumları içerir:

• İsteğe verilen yanıtın durum kodu "200 OK" den farklıysa veya "Eğer-Modified-Since" başlık alanında belirtilen tarih yanlışsa, yanıt normal bir GET isteğine verilen yanıtla aynı olacaktır.
• Kaynak belirtilen tarihten sonra değiştiyse, yanıt da normal bir GET isteğine verilen yanıtla aynı olacaktır.
• Belirtilen tarihten sonra kaynak değişmediyse, sunucu bir 304 Değiştirilmedi durum kodu döndürür.

Koşullu GET yönteminin kullanımı, ağ üzerinden gereksiz bilgilerin iletilmesine izin vermediğinden ağın yükünü boşaltmaya yöneliktir.

KAFA

HEAD yöntemi, sunucunun yanıtta bir Yanıt Gövdesi döndürmemesi dışında GET yöntemine benzer. HEAD isteğine verilen yanıtın HTTP başlıklarında bulunan meta bilgiler, bir GET isteğine verilen yanıtın HTTP başlıklarındaki bilgilerle aynı olmalıdır. Bu yöntem, kaynağın kendisini ağ üzerinden iletmeden bir kaynak hakkında meta bilgi elde etmek için kullanılabilir. Koşullu GET'e benzer "Koşullu HEAD" yöntemi tanımsızdır.

İLETİ

POST yöntemi, sunucunun istekte yer alan bilgileri İstek URI'si alanında Durum Satırında belirtilen kaynağa bağlı olarak kabul etmesini istemek için kullanılır. POST yöntemi, aşağıdaki işlevler için ortak bir yöntemi kullanabilmek üzere tasarlanmıştır:

• Mevcut kaynakların ek açıklaması
• Haber gruplarına, posta listelerine veya benzer makale gruplarına gönderi ekleme
• Veri bloklarının veri işleme süreçlerine teslimi
• Ekleme işlemi ile veritabanlarını genişletme

POST yöntemi tarafından gerçekleştirilen asıl işlev sunucuya özeldir ve genellikle İstek URI'sine bağlıdır. Dosyanın bulunduğu dizine bağlı olması, yeni makalenin eklendiği haber grubuna bağlı olması, girişin veritabanına bağlı olması gibi, eklenen bilgiler belirtilen URI'ye bağlı olarak kabul edilir.

İstemci, isteğe bir "URI" başlığı ekleyerek yeni bir kaynağı tanımlamak için bir URI önerebilir. Ancak, sunucu bu URI'yi yalnızca tavsiye olarak kabul etmelidir ve istek gövdesini farklı bir URI ile veya hiç URI olmadan depolayabilir.

Bir POST isteğinin işlenmesi sonucunda yeni bir kaynak oluşturulmuşsa, yanıtın 201 Created durum koduna sahip olması ve yeni kaynağın URI'sini içermesi gerekir.

KOYMAK

PUT yöntemi, sunucudan İstek-Gövdesini İstek-URI'sine eşit bir URI altında saklamasını ister. İstek URI'si zaten var olan bir kaynağa atıfta bulunuyorsa, İstek Gövdesi bu kaynağın değiştirilmiş bir versiyonu olarak ele alınacaktır. İstek-URI'si tarafından başvurulan kaynak mevcut değilse ve verilen URI, yeni kaynak için bir açıklama olarak kabul edilebilirse, sunucu verilen URI ile bir kaynak YARATABİLİR. Yeni bir kaynak oluşturulmuşsa, sunucu istekte bulunan istemciyi "201 Oluşturuldu" durum koduyla bir yanıtla bilgilendirmelidir. Mevcut bir kaynak değiştirilmişse, müşteriye işlemin başarılı olduğunu bildirmek için 200 OK yanıtı gönderilmelidir. Belirtilen URI'ye sahip bir kaynak oluşturulamıyor veya değiştirilemiyorsa uygun bir hata mesajı gönderilir.

POST ve PUT yöntemleri arasındaki temel fark, İstek URI'si alanının farklı anlamıdır. POST yöntemi için bu URI, istek gövdesinde yer alan bilgileri bir tür eklenti olarak yönetecek bir kaynağı belirtir. Kaynak, bir veri işleme süreci, başka bir protokole ağ geçidi veya açıklama eklenebilen ayrı bir kaynak olabilir. Buna karşılık, bir PUT talebinin URI'si, İçerik Talebi'nde yer alan bilgileri tanımlar. PUT isteğini kullanan kişi tam olarak hangi URI'yi kullanacağını bilir ve isteğin alıcısı bu isteği başka bir kaynağa uygulamaya çalışmamalıdır.

SİLMEK

DELETE yöntemi, İstek URI'si tarafından tanımlanan kaynakları kaldırmak için kullanılır. Bu yöntemin sunucu üzerindeki sonuçları insan müdahalesi ile (veya başka bir şekilde) değiştirilebilir. Prensipte, sunucu tarafından iletilen durum kodu eylemin başarıyla tamamlandığını bildirse bile, istemci silme işleminin tamamlandığından asla emin olamaz. Ancak sunucu, yanıt anında kaynağı silmeyi veya erişilemeyen bir alana taşımayı amaçlayana kadar başarıyı bildirmemelidir.

BAĞLANTI

LINK yöntemi, bir İstek URI'sinde belirtilen mevcut bir kaynak ile diğer mevcut kaynaklar arasında ilişkiler kurar. LINK yönteminin belgeler arasında bağlantı kurulmasına izin veren diğer yöntemlerden farkı, LINK yönteminin bir istekte İstek-Gövdesi iletilmesine izin vermemesi ve bu yöntem sonucunda yeni kaynakların oluşturulmamasıdır.

BAĞLANTIYI KALDIR

UNLINK yöntemi, İstek URI'sinde belirtilen kaynak için bir veya daha fazla referans ilişkisini kaldırır. Bu ilişkiler, LINK yöntemi veya "Link" başlığını destekleyen başka bir yöntem kullanılarak kurulabilir. Bir kaynağa bir bağlantının kaldırılması, kaynağın varlığının sona erdiği veya gelecekteki bağlantılar için erişilemez hale geldiği anlamına gelmez.

İstek-Başlık Alanları

İstek-Başlığı alanları, istemcinin, istek ve istemcinin kendisi hakkında sunucuya ek bilgiler iletmesine izin verir.

İstek-Başlığı = Kabul | Kabul Et-Karakter Seti | Kabul-Kodlama | Kabul Et-Dil | yetkilendirme | Kimden | If-Modified-Since | Pragma | Yönlendiren | Kullanıcı Aracısı | uzatma başlığı

Ek olarak, uzatma mekanizması aracılığıyla ek başlıklar tanımlanabilir; bunları tanımayan uygulamalar bu başlıkları Başlık-İçerik olarak değerlendirmelidir.

İstek başlığı alanlarından bazıları aşağıda tartışılacaktır.

İtibaren

Kimden alanı mevcutsa, istekte bulunan aracıyı kontrol eden kullanıcının tam E-posta adresini içermelidir. Bu adres, RFC 822'de tanımlanan biçimde belirtilmelidir. Bu alanın biçimi: Kimden = "Kimden" ":" adres belirtimi. Örneğin:

İtibaren: [e-posta korumalı]

Bu alan, oturum açma işlevleri için ve ayrıca yanlış veya istenmeyen isteklerin kaynağını belirlemek için kullanılabilir. Erişim haklarının sınıflandırılmamış bir farklılaşma biçimi olarak kullanılmamalıdır. Bu alanın yorumlanması, işlenmekte olan talebin, uygulanan yöntemin sorumluluğunu kabul eden verilen kullanıcı adına yapıldığı şeklindedir. Özellikle robotik ajanlar, sorun olması durumunda robotun çalışmasından sorumlu kişiyle iletişime geçebilmeleri için bu başlığı kullanmalıdır. Bu alanda belirtilen İnternet posta adresi, bu isteğin gönderildiği ana bilgisayarın adresiyle eşleşmek zorunda değildir. Mümkünse, adres, aslında bir İnternet E-posta adresi veya diğer posta sistemlerinden bir adresin İnternet E-postası temsili olsun, erişilebilir bir İnternet adresi olmalıdır.

Not: Bir istemci, kendi özel çıkarları veya kullandıkları yerel güvenlik sistemleriyle çelişebileceğinden, kullanıcının izni olmadan Kimden üstbilgi alanını kullanmamalıdır. Kullanıcıya, talep edilmeden önce herhangi bir zamanda bu alanı reddetme, izin verme veya değiştirme olanağı sağlamanız önemle tavsiye edilir.

Eğer-Modified-Since

If-Modified-Since başlık alanı, onu koşullu hale getirmek için GET yöntemiyle birlikte kullanılır: talep edilen kaynak bu alanda belirtilen süre içinde değişmediyse, bu kaynağın bir kopyası sunucu tarafından döndürülmez; bunun yerine, bir Yanıt Gövdesi olmadan bir 304 Değiştirilmedi yanıtı döndürülecektir.

If-Modified-Since = "If-Modified-Since" ":" HTTP tarihi

Başlık kullanımına bir örnek:

Bu özelliğin amacı, yerel önbellek bilgilerini minimum iletilen bilgi ile verimli bir şekilde güncelleme yeteneği sağlamaktır. Aynı sonuç, sunucu belgenin içeriğinin değiştiğini belirtiyorsa, HEAD yöntemi ve ardından GET kullanılarak elde edilebilir.

Kullanıcı Aracısı

User-Agent başlık alanı, istekte bulunan kullanıcı aracısı hakkında bilgi içerir. Bu alan istatistikler, protokol hatalarının izlenmesi ve kullanıcı aracılarının otomatik olarak tanınması için kullanılır. Zorunlu olmamakla birlikte, kullanıcı aracıları isteklerine her zaman bu alanı dahil etmelidir. Alan, yazılım ürününün adını temsil eden birden çok satır, ürünün sürümünü belirten isteğe bağlı bir eğik çizgi ve kullanıcı aracısının önemli bir bölümünü oluşturan diğer yazılım ürünlerini içerebilir. Geleneksel olarak, ürünler, uygulamanın tanımlanması için azalan önem sırasına göre listelenir.

Kullanıcı Aracısı = "Kullanıcı Aracısı" ":" 1 * (ürün) ürün = dize ["/" ürün sürümü] ürün sürümü = dize

Kullanıcı Aracısı: CERN-LineMode / 2.15 libwww / 2.17b3

Ürünün adını açıklayan dize kısa ve öz olmalıdır - bu başlığın diğer alakasız bilgilerin reklamını yapmak için kullanılmasına izin verilmez ve protokole uygun olmadığı kabul edilir. Ürün sürümü alanında herhangi bir dize bulunabilse de, bu dize yalnızca ürün sürümünü belirtmek için kullanılmalıdır. User-Agent alanı, değerinin parçası olmayan yorumlarda ek bilgiler içerebilir.

Tepki yapısı

Sunucu, talebi alıp yorumladıktan sonra aşağıdaki forma uygun olarak bir yanıt gönderir:

Cevap = Basit Cevap | Tam Cevap Basit Cevap = [İçerik-Cevap] Tam Cevap = Durum-Dize * (Genel-Başlık | Yanıt-Başlığı | İçerik-Başlığı) CRLF [İçerik-Yanıt]

Basit Yanıt, yalnızca HTTP / 0.9 Basit İsteğe yanıt olarak veya sunucu yalnızca sınırlı HTTP / 0.9 protokolünü destekliyorsa gönderilmelidir. Bir istemci bir HTTP / 1.0 Tam İstek gönderirse ve Durum Satırı ile başlamayan bir yanıt alırsa, sunucunun yanıtının bir Basit Yanıt olduğunu varsaymalı ve buna göre işlemelidir. Basit Yanıtın yalnızca istenen bilgilerden (başlıklar olmadan) oluştuğu ve sunucunun iletişim oturumunu kapattığı anda veri akışının durduğu unutulmamalıdır.

Hat Durumu

Tam Talebin ilk satırı, protokol sürümünün ardından sayısal bir durum kodu ve bununla ilişkili metin cümlesinden oluşan bir Durum Satırıdır. Durum Çizgisinin tüm öğeleri boşluklarla ayrılır. Sonlandırıcı CRLF dizisi dışında CR ve LF karakterlerine izin verilmez.

Satır-Durumu = Sürüm-HTTP SP Durum-Kod SP İfadesi-Hakkında "açıklama.

Durum Satırı her zaman "HTTP /" protokol versiyonu 1 * DIGIT "." ile başladığından. 1 * SAYI (örneğin HTTP / 1.0), bir yanıtın Basit Cevap mı yoksa Tam Cevap mı olduğunu belirlemek için bu ifadenin varlığı esas kabul edilir. Basit Cevap formatı böyle bir satırın (yanıt mesajının yanlış yorumlanmasına ve onu Tam Cevap ile karıştırılmasına yol açacaktır) oluşumunu dışlamasa da, böyle bir meydana gelme olasılığı sıfıra yakındır.

Durum-Kodu ve açıklaması

Durum Kodu öğesi, isteği yorumlama ve karşılama girişiminin sonucunu tanımlayan 3 basamaklı bir tam sayı kodudur. Bunu takip eden Açıklama İfadesi, Durum Kodunun kısa bir metin açıklaması için tasarlanmıştır. Durum Kodu bir makine tarafından kullanılmak üzere tasarlanmıştır, Açıklama İfadesi ise bir kişi tarafından kullanılmak üzere tasarlanmıştır. Müşteri, Açıklama Cümlesini araştırmak ve göstermek zorunda değildir.

Durum Kodunun ilk basamağı yanıt sınıfını belirlemek için kullanılır. Son iki hane herhangi bir sınıflandırma rolü oynamaz. İlk basamak için 5 değer vardır:

1. 1xx: Bilgilendirici - Kullanılmaz, ancak ileride kullanılmak üzere ayrılmıştır
2. 2xx: Başarılı - İstek tamamen alındı, anlaşıldı ve işlenmek üzere kabul edildi.
3. 3xx: Yönlendirme - İstemci, isteği başarıyla tamamlamak için daha fazla işlem yapmalıdır. Gerekli ek eylem bazen müşteri tarafından kullanıcı etkileşimi olmadan gerçekleştirilebilir, ancak bunun yalnızca istekte kullanılan yöntemin kayıtsız olduğu durumlarda (GET veya HEAD) gerçekleştirilmesi şiddetle önerilir.
4. 4xx: İstemci Hatası - Geçersiz sözdizimi içeren bir istek başarıyla tamamlanamadı. 4xx sınıfı, istemci tarafından bir hatanın yapıldığı durumları tanımlamayı amaçlamaktadır. İstemci bir 4xx Durum Kodu yanıtı aldığında isteği henüz tamamlamadıysa, sunucuya veri göndermeyi derhal durdurmalıdır. Bu tür Durum Kodları, istekte kullanılan tüm yöntemler için geçerlidir.
5. 5xx: Sunucu Hatası - Sunucu, doğru şekilde gönderilen bir isteğe yanıt veremedi. Bu durumlarda
   sunucu ya bir hata yaptığını biliyor ya da isteği işleyemiyor. HEAD isteklerine verilen yanıtlar dışında, sunucu, İçerik-Yanıtı'na hata durumunun ve koşulun geçici mi yoksa kalıcı mı olduğunun bir açıklamasını gönderir. Bu tür Durum Kodları, istekte kullanılan tüm yöntemler için geçerlidir.

Durum Kodlarının tek tek anlamları ve ilgili Açıklama İfadeleri aşağıda verilmiştir. Bu Açıklayıcı Cümleler yalnızca tavsiye edilir - anlamlarını koruyan ve protokol tarafından izin verilen diğer ifadeler ile değiştirilebilirler.

Durum-Kodu = "200"; tamam | "201"; Oluşturuldu | "202"; kabul edildi | "203"; Geçici Bilgi | "204"; İçerik Yok | "300"; Çoklu Seçenekler | "301"; Kalıcı Olarak Taşındı | "302"; Geçici Olarak Taşındı | "303"; Yöntem | "304"; Değiştirilmedi | "400"; Kötü İstek | "401"; yetkisiz | "402"; Ödeme Gerekli | "403"; yasak | "404"; Bulunamadı | "405"; Yönteme İzin Verilmiyor | "406"; Yok Kabul Edilebilir | "407"; Proxy Kimlik Doğrulaması Gerekli | "408"; Zaman Aşımı Talebi | "409"; Çatışma | "410"; gitti | "500"; Dahili Sunucu Hatası | "501"; Uygulanmadı | "502"; Kötü Ağ Geçidi | "503"; Hizmet Kullanılamıyor | "504"; Ağ Geçidi Zaman Aşımı | Uzantı-Kodu Uzantı-Kodu = 3DIGIT Cümle-Hakkında "açıklama = string * (SP string)

HTTP uygulamalarının tüm Durum Kodlarını anlaması gerekli değildir, ancak böyle bir anlayış açıkça arzu edilir. Ancak, uygulamaların Durum Kodlarının sınıflarını (ilk basamakla tanımlanır) tanıyabilmesi ve yanıt durumunun tüm Durum Kodlarını Durum Kodu x00'e eşdeğermiş gibi ele alabilmesi gerekir.

Başlık-Yanıt Alanları

Yanıt başlığı alanları, sunucunun, Durum Satırına girilemeyen yanıtla ilgili ek bilgileri iletmesine izin verir. Bu başlık alanları, bir isteğe yanıt olarak gönderilen yanıtın içeriği hakkında bilgi aktarmayı amaçlamaz, ancak sunucunun kendisiyle ilgili bilgiler olabilir.

Yanıt-Başlığı = Genel | Yeniden Dene-Sonra | sunucu | WWW-Kimlik Doğrulama | uzatma başlığı

Ek yanıt başlığı alanları, genişletme mekanizması aracılığıyla uygulanabilse de, bu alanları tanımayan uygulamalar bunları Başlık-İçerik alanları olarak değerlendirmelidir. Bu alanların tam açıklaması CERN'deki HTTP protokolü belirtiminde bulunabilir.

Genel konseptler

Tam İstek ve Tam Yanıt, bazı bilgileri ayrı istek ve yanıtlarda iletmek için kullanılabilir. Bu bilgi, sırasıyla İçerik-Talebi veya İçerik-Yanıt ile İçerik-Başlığıdır.

Başlık-İçerik Alanları

İçerik-Başlığı alanları, sırasıyla İstek-İçerik veya Yanıt-İçerik hakkında isteğe bağlı meta bilgileri içerir. Karşılık gelen mesajın gövdesi (istek veya yanıt) mevcut değilse, İçerik Başlığı talep edilen kaynak hakkında bilgi içerir.

İçerik başlığı alanlarından bazıları aşağıda açıklanmıştır.

İzin vermek

İzin Ver başlığı alanı, İstek URI'si tarafından tanımlanan kaynağın desteklediği yöntemlerin bir listesidir. Bu alanın amacı, alıcıyı kaynakla ilişkili geçerli yöntemler hakkında doğru bir şekilde bilgilendirmektir; bu alan "405 Yönteme İzin Verilmiyor" durum koduyla yanıtta bulunmalıdır.

İzin Ver = "İzin Ver" ":" 1 # yöntem

Kullanım örneği:

İzin ver: GET, HEAD, PUT

Tabii ki, müşteri başka yöntemleri deneyebilir. Ancak bu alanda belirtilen yöntemleri izlemeniz önerilir. Bu alanın varsayılan değeri yoktur; tanımsız bırakılırsa, izin verilen yöntemler kümesi, her istek sırasında sunucu tarafından belirlenir.

İçerik Uzunluğu

Content-Length, bir isteğe yanıt olarak sunucu tarafından gönderilen ileti gövdesinin boyutunu veya bir HEAD isteği olması durumunda, bir GET isteğine yanıt olarak gönderilecek ileti gövdesinin boyutunu belirtir.

Content-Length = "Content-Length" ":" 1 * DIGIT

Örneğin:

İçerik Uzunluğu: 3495

Zorunlu olmamakla birlikte, uygulamaların, içerdiği bilgi türünden bağımsız olarak iletilen mesajın boyutunu ayrıştırmak için bu alanı kullanmaları şiddetle tavsiye edilir. İçerik-Uzunluk alanı için sıfırdan büyük herhangi bir tamsayı değeri geçerlidir.

İçerik türü

İçerik Türü başlık alanı, alıcı uca gönderilen mesajın gövdesindeki bilgi türünü veya HEAD yöntemi olması durumunda, GET yöntemi olsaydı gönderilecek olan bilgi türünü (ortamı) tanımlar. kullanılmış.

Content-Type = "Content-Type" ":" ortam tipi

Medya türleri ayrı ayrı tanımlanır.
Örnek:

İçerik Türü: metin / html; karakter kümesi = ISO-8859-4

Content-Type'ın varsayılanı yoktur.

Son düzenleme

Başlık alanı, gönderenin kaynağın en son değiştirildiğine inandığı tarih ve saati içerir. Bu alanın semantiği, alıcının onu nasıl yorumlaması gerektiğine göre tanımlanır: alıcının kaynağın Son Değiştirme alanında geçen tarihten daha eski bir kopyası varsa, kopyanın eski olduğu kabul edilmelidir.

Last-Modified = "Son-Değiştirme" ":" HTTP Tarihi

Kullanım örneği:

Bu başlık alanının tam anlamı, gönderenin uygulamasına ve kaynağın kendisinin doğasına bağlıdır. Dosyalar için, en son değiştirildiği zaman olabilir. Veritabanı ağ geçitleri için bu, veritabanındaki verilerin en son güncellendiği zaman olabilir. Her durumda, alıcı yalnızca sonuç - verilen alanda ne olduğu - hakkında endişelenmeli ve sonucun nasıl elde edildiği konusunda endişelenmemelidir.

mesaj gövdesi

Mesajın gövdesi, sırasıyla İçerik-Talebi veya İçerik-Yanıt anlamına gelir. İletinin gövdesi, varsa, Başlık-İçerik alanları tarafından belirtilen format ve kodlamada bir HTTP / 1.0 isteği veya yanıtı olarak gönderilir.

Message-Body = * OCTET (burada OCTET herhangi bir 8-bit karakterdir)

Bir ileti gövdesi, yalnızca istek yönteminin var olduğunu varsayarsa, isteğe dahil edilir. HTTP / 1.0 spesifikasyonu için bu yöntemler POST ve PUT'tur. Genel olarak, bir mesaj gövdesinin varlığı, iletilen istekte İçerik-Uzunluk ve/veya İçerik-Aktarım-Kodlama gibi içerik başlık alanlarının varlığı ile belirtilir.

Bu makaleyi okuduktan sonra, sıkıştırma kullanmanın neden bu kadar önemli olduğunu ve web sitenizde ne gibi etkileri olabileceğini öğreneceksiniz. Bu makale iki temele dayanmaktadır ...

6.1 WWW Hizmeti

Servis WWW (World Wide Web) - köprü metni bilgilerinin değişimi için tasarlanmıştır.

Proje 1989 yılında önerildi. 1993 yılında ilk tarayıcı ortaya çıktı.

WWW, bir "istemci-sunucu" şeması üzerine kurulmuştur.

Tarayıcı(Internet Explorer, Opera ...) çok protokollü bir istemci ve HTML yorumlayıcısıdır. Tipik bir yorumlayıcı olarak, istemci komutlara (etiketlere) bağlı olarak farklı işlevler gerçekleştirir. Bu işlevlerin kapsamı, yalnızca metnin ekrana yerleştirilmesini değil, alınan HTML metnini ayrıştırırken sunucuyla bilgi alışverişini de içerir; bu, metinde gömülü grafik görüntüleri görüntülerken en açık şekilde gerçekleşir.

HTTP Sunucusu(Apeche, IIS ...) istemci dosya isteklerini işler (en basit durumda).

HTTP aracılığıyla istemci ve sunucu arasındaki etkileşim.

Başlangıçta, WWW hizmeti üç standarda dayanıyordu:

HTML (Köprü Metni İşaretleme Dili) - belgeler için köprü metni işaretleme dili;

URL (Evrensel Kaynak Bulucu) - ağdaki kaynakları adreslemenin evrensel bir yolu;

HTTP (Köprü Metni Aktarım Protokolü), bir köprü metni bilgi alışverişi protokolüdür.

CGI (Common Gateway Interface), evrensel bir ağ geçidi arabirimidir. HTTP sunucusunun, sunucuda kurulu diğer programlarla (örneğin, bir DBMS) etkileşimi için tasarlanmıştır.

6.2 HTTP protokolü

İlk belge (ancak standart değil) RFC1945'tir (Köprü Metni Aktarım Protokolü - HTTP / 1.0 T. Berners-Lee, R. Fielding, H. Frystyk Mayıs 1996)

Programın özelliklerinden bazıları:

siteyi tarama derinliğini ve harici bağlantıları ayarlama

örneğin indirmek için dosya türünü (uzantı) ayarlayarak yalnızca grafikleri indirebilirsiniz.

dosyanın boyutuna bir sınır koyun.

grafik kartları tarama.

çalışma programını ayarlama, yerleşik Zamanlayıcı.

bazı müşteriler için bir sınırlama varsa, müşterinin iş adı.

aynı anda indirilen dosyaların sayısını ayarlama.

Burada, tarayıcınızın 90'ların başından bu güne kadar web sayfalarını yüklemesine izin veren ağ protokolü olan HTTP protokolünün ana yönlerinin bir açıklaması yer almaktadır. Bu makale, bilgisayar ağlarıyla çalışmaya ve ağ uygulamaları geliştirmeye yeni başlayanlar ve resmi özellikleri kendi başlarına okumanın hala zor olduğu kişiler için yazılmıştır.

HTTP- başlangıçta hiper metin belgelerinin (yani, diğer belgelere geçişi düzenlemenize izin veren bağlantılar içerebilecek belgeler) aktarımı için tasarlanmış yaygın bir veri aktarım protokolü.

HTTP kısaltması şu anlama gelir: Üstmetin transfer protokolü, "Üstmetin transfer protokolü". OSI spesifikasyonuna göre HTTP, bir uygulama (üst, 7.) katman protokolüdür. Geçerli protokol sürümü olan HTTP 1.1, RFC 2616 belirtiminde açıklanmıştır.

HTTP protokolü, bir istemci-sunucu veri aktarım yapısının kullanıldığını varsayar. İstemci uygulaması bir istek oluşturur ve bunu sunucuya gönderir, ardından sunucu yazılımı bu isteği işler, bir yanıt oluşturur ve istemciye geri gönderir. İstemci uygulaması daha sonra benzer şekilde işlenecek olan diğer istekleri göndermeye devam edebilir.

Geleneksel olarak HTTP protokolü kullanılarak çözülen bir problem, web kaynaklarına (genellikle bir web tarayıcısı) erişen bir kullanıcı uygulaması ile bir web sunucusu arasındaki veri alışverişidir. Şu anda, World Wide Web'in çalışması HTTP protokolü sayesinde sağlanmaktadır.

Ayrıca HTTP, genellikle SOAP, XML-RPC ve WebDAV gibi diğer uygulama katmanı protokolleri için bir iletişim protokolü olarak kullanılır. Bu durumda HTTP protokolünün bir "taşıma" olarak kullanıldığı söylenir.

Birçok yazılım ürününün API'si, veri aktarımı için HTTP kullanımını da ima eder - verilerin kendisi, örneğin XML veya JSON gibi herhangi bir biçimde olabilir.

Tipik olarak HTTP protokolü üzerinden veri iletimi TCP/IP bağlantıları üzerinden gerçekleştirilir. Sunucu yazılımı genellikle 80 numaralı TCP bağlantı noktasını kullanır (ve bağlantı noktası açıkça belirtilmemişse, o zaman istemci yazılımı, başka herhangi birini kullanabilmesine rağmen, genellikle açık HTTP bağlantıları için varsayılan olarak 80. bağlantı noktasını kullanır).

Nasıl HTTP isteği gönderirim?

HTTP protokolünü anlamanın en kolay yolu, bir web kaynağına manuel olarak erişmeye çalışmaktır. Bir tarayıcı olduğunuzu ve Anatoly Alizar'ın makalelerini gerçekten okumak isteyen bir kullanıcınız olduğunu hayal edin.

Adres çubuğuna şunu girdiğini varsayalım:

Http: //alizar.site/

Buna göre, bir web tarayıcısı olarak artık alizar.site adresindeki web sunucusuna bağlanmanız gerekiyor.

Bunu yapmak için uygun herhangi bir komut satırı yardımcı programını kullanabilirsiniz. Örneğin telnet:

Telnet alizar.Site 80

Aniden fikrinizi değiştirirseniz, Ctrl + "]" tuşlarına basın ve ardından enter yapın - bu, HTTP bağlantısını kapatmanıza izin verecektir. Telnet'e ek olarak, beğeninize nc (veya ncat) deneyebilirsiniz.

Sunucuya bağlandıktan sonra bir HTTP isteği göndermeniz gerekir. Bu arada, bu çok kolay - HTTP istekleri yalnızca iki satırdan oluşabilir.

Bir HTTP isteği oluşturmak için, bir başlangıç ​​satırı oluşturmak ve ayrıca en az bir başlık ayarlamak gerekir - bu, gerekli olan ve her istekte bulunması gereken Ana Bilgisayar başlığıdır. Gerçek şu ki, bir alan adının bir IP adresine dönüştürülmesi istemci tarafında gerçekleştirilir ve buna göre, bir TCP bağlantısı açtığınızda, uzak sunucu, bağlantı için hangi adresin kullanıldığı hakkında herhangi bir bilgiye sahip değildir: örneğin alizar..ru veya m adresi olabilir. Bununla birlikte, aslında, her durumda ağ bağlantısı 212.4.43.44 düğümü ile açılır ve başlangıçta, bağlantı açılırken bu IP değil adres ayarlandı, ancak bazı alan adları, daha sonra sunucu bu konuda hiçbir şekilde bilgilendirilmedi - ve bu yüzden bu adresin Host başlığına iletilmesi gerekiyor.

HTTP 1.1 için başlangıç ​​(ilk) istek dizesi aşağıdaki gibi oluşur:

Örneğin (bunun gibi bir başlangıç ​​satırı sitenin ana sayfasının istendiğini gösterebilir):

Ve elbette, gerçekten kullanmaya başladığınızda herhangi bir teknolojinin çok daha basit ve net hale geldiğini unutmayın.

İyi şanslar ve verimli öğrenme!

Etiketler:

• http
• alizar
• spdy

Etiket ekle