HTTP haqqında sadə dillə desək. Parametrlər sorğusu: HTTP POST sorğusunda parametrlər necə göndərilir? xx: Məlumat mesajları

HTTP paylanmış sistemlər arasında hipermətn ötürmək üçün bir protokoldur. Əslində http müasir İnternetin əsas elementidir. Özümüzə hörmət edən veb tərtibatçıları olaraq, bu barədə mümkün qədər çox şey bilməliyik.

Gəlin bu protokola öz peşəmizin gözü ilə baxaq. Birinci hissədə biz əsasları nəzərdən keçirəcəyik və sorğulara/cavablara baxacağıq. Növbəti məqalədə keşləmə, əlaqənin işlənməsi və autentifikasiya kimi daha ətraflı xüsusiyyətlərə baxacağıq.

Həmçinin bu məqalədə mən əsasən RFC 2616 standartına istinad edəcəyəm: Hypertext Transfer Protocol -- HTTP/1.1.

HTTP Əsasları

HTTP çoxsaylı hostlar və müştərilər arasında əlaqə yaratmağa imkan verir və bir sıra şəbəkə parametrlərini dəstəkləyir.

Əsasən, TCP/IP rabitə üçün istifadə olunur, lakin bu, yeganə mümkün variant deyil. Varsayılan olaraq, TCP/IP 80 portdan istifadə edir, lakin digərləri istifadə edilə bilər.

Ev sahibi ilə müştəri arasında ünsiyyət iki mərhələdə baş verir: sorğu və cavab. Müştəri HTTP sorğusu yaradır, buna cavab olaraq server cavab (mesaj) verir. Bir az sonra bu iş sxeminə daha ətraflı baxacağıq.

HTTP protokolunun cari versiyası 1.1-dir və bəzi yeni funksiyalar təqdim edilmişdir. Fikrimcə, onlardan ən vacibləri bunlardır: daim açıq əlaqə üçün dəstək, yeni məlumat ötürmə mexanizmi parçalanmış ötürmə kodlaşdırması, keşləmə üçün yeni başlıqlar. Bunun bəzilərinə bu məqalənin ikinci hissəsində baxacağıq.

URL

Veb kommunikasiyasının əsasını Uniform Resource Locator (URL) vasitəsilə göndərilən sorğu təşkil edir. Əminəm ki, siz artıq URL-nin nə olduğunu bilirsiniz, lakin tamlıq üçün bir neçə söz demək qərarına gəldim. URL strukturu çox sadədir və aşağıdakı komponentlərdən ibarətdir:

Protokol müntəzəm bağlantılar üçün http və ya daha təhlükəsiz məlumat mübadiləsi üçün https ola bilər. Standart port 80-dir. Bundan sonra serverdəki resursa gedən yol və parametrlər silsiləsi gəlir.

Metodlar

URL-dən istifadə edərək, əlaqə qurmaq istədiyimiz hostun dəqiq adını müəyyənləşdiririk, lakin hansı hərəkəti yerinə yetirməli olduğumuzu yalnız HTTP metodundan istifadə etməklə bildirmək olar. Əlbəttə ki, bizim edə biləcəyimiz bir neçə növ hərəkət var. HTTP əksər tətbiqlərin ehtiyaclarına uyğun olan ən zəruri olanları həyata keçirir.

Mövcud üsullar:

GET: Mövcud resursa daxil olun. URL bütün lazımi məlumatları sadalayır ki, server tələb olunan resursu cavab olaraq tapıb qaytara bilsin.

POST: Yeni resurs yaratmaq üçün istifadə olunur. POST sorğusu adətən yeni resurs yaratmaq üçün bütün lazımi məlumatları ehtiva edir.

QOY: Cari resursu yeniləyin. PUT sorğusu yenilənəcək məlumatları ehtiva edir.

SİLİN: Mövcud resursu silmək üçün istifadə olunur.

Bu üsullar ən populyardır və ən çox müxtəlif alətlər və çərçivələr tərəfindən istifadə olunur. Bəzi hallarda PUT və DELETE sorğuları POST göndərməklə göndərilir, onun məzmunu resursda yerinə yetirilməli olan hərəkəti göstərir: yaratmaq, yeniləmək və ya silmək.

HTTP digər üsulları da dəstəkləyir:

BAŞ: GET-ə bənzəyir. Fərq ondadır ki, bu tip sorğu ilə heç bir mesaj ötürülmür. Server yalnız başlıqları qəbul edir. Məsələn, resursun dəyişdirilib-dəyişdirilmədiyini müəyyən etmək üçün istifadə olunur.

İZ: ötürülmə zamanı sorğu hər biri öz məlumatını daxil edən bir çox giriş nöqtələri və proxy serverlərdən keçir: IP, DNS. Bu üsuldan istifadə edərək, bütün aralıq məlumatları görə bilərsiniz.

OPSİYONLAR: Xüsusi resurs üçün server imkanlarını, parametrlərini və konfiqurasiyasını müəyyən etmək üçün istifadə olunur.

Vəziyyət kodları

Müştərinin sorğusuna cavab olaraq server status kodunu ehtiva edən cavab göndərir. Bu kodun xüsusi mənası var ki, müştəri cavabı necə şərh edəcəyini daha aydın başa düşə bilsin:

1xx: Məlumat mesajları

Bu kodların dəsti HTTP/1.1-də təqdim edilmişdir. Server bu formada sorğu göndərə bilər: Gözləyin: 100-davam et, yəni müştəri hələ də sorğunun qalan hissəsini göndərir. HTTP/1.0 ilə işləyən müştərilər bu başlıqlara məhəl qoymurlar.

2xx: Uğur mesajları

Əgər müştəri 2xx seriyasından kod alıbsa, sorğu uğurla göndərilib. Ən ümumi seçim 200 OK-dir. GET sorğusu ilə server mesajın mətnində cavab göndərir. Digər mümkün cavablar da var:

202 Qəbul edilmişdir: Sorğu qəbul edildi, lakin cavabda resurs olmaya bilər. Bu, server tərəfindəki asinxron sorğular üçün faydalıdır. Resursun göndərilib-göndərilməyəcəyini server müəyyən edir.
204 Məzmun yoxdur: Cavab orqanında heç bir mesaj yoxdur.
205 Məzmunu Sıfırla: Serverə sənədin təqdimatını sıfırlamağı əmr edir.
206 Qismən Məzmun: Cavab məzmunun yalnız bir hissəsini ehtiva edir. Əlavə başlıqlar məzmunun və digər məlumatların ümumi uzunluğunu müəyyən edir.

3xx: yönləndirmə

Müştəriyə daha bir tədbir görməyin lazım olduğuna dair bir növ mesaj. Ən ümumi istifadə halı müştərini başqa ünvana yönləndirməkdir.

301 Daimi köçürülüb: Resurs indi fərqli URL-də tapıla bilər.
303 Digərlərinə baxın: Resurs müvəqqəti olaraq başqa URL-də tapıla bilər. Məkan başlığında müvəqqəti URL var.
304 Dəyişdirilməmişdir: Server resursun dəyişdirilmədiyini və müştərinin cavabın keşlənmiş versiyasını istifadə etməli olduğunu müəyyən edir. Məlumatın eyniliyini yoxlamaq üçün ETag (Entity Tag hash) istifadə olunur;

4xx: Müştəri səhvləri

Bu mesaj sinfi, sorğunun səhvən göndərildiyinə qərar verərsə, server tərəfindən istifadə olunur. Ən çox yayılmış kod 404 Tapılmadı. Bu o deməkdir ki, resurs serverdə tapılmayıb. Digər mümkün kodlar:

400 Səhv Sorğu: Sual səhv qurulub.
401 İcazəsiz: Sorğu etmək üçün autentifikasiya tələb olunur. Məlumat Avtorizasiya başlığı vasitəsilə ötürülür.
403 qadağandır: Server resursa girişə icazə vermədi.
405 Metod İcazə Verilmir: Mənbəyə daxil olmaq üçün etibarsız HTTP metodundan istifadə edilib.
409 Münaqişə: server sorğunu tam emal edə bilmir, çünki resursun daha yeni versiyasını dəyişməyə çalışır. Bu, çox vaxt PUT sorğuları ilə baş verir.

5xx: Server xətaları

Sorğunu emal edərkən server xətasını aşkar etmək üçün istifadə olunan bir sıra kodlar. Ən çox yayılmış: 500 Daxili Server Xətası. Digər seçimlər:

501 Həyata keçirilmir: Server tələb olunan funksionallığı dəstəkləmir.
503 Xidmət əlçatan deyil: Bu, serverdə xəta olduqda və ya həddən artıq yükləndikdə baş verə bilər. Adətən bu halda server cavab vermir və cavab üçün verilən vaxt başa çatır.

Sorğu/cavab mesajı formatları

Aşağıdakı şəkildə siz müştəri tərəfindən sorğunun göndərilməsi, server tərəfindən cavabın işlənməsi və göndərilməsinin sxematik prosesini görə bilərsiniz.

HTTP vasitəsilə ötürülən mesajın strukturuna baxaq:

Mesaj = *() CRLF [ ] = Sorğu Xətti | Status-Xətti = Alan-Adı ":" Sahə-Dəyər

Mesajın başlığı və mətni arasında boş sətir olmalıdır. Bir neçə başlıq ola bilər:

Müvafiq funksiya işə salınarsa, cavab orqanı məlumatın hamısını və ya bir hissəsini ehtiva edə bilər (Transfer-Encoding: chunked). HTTP/1.1 həmçinin Transfer-Encoding başlığını dəstəkləyir.

Ümumi başlıqlar

Həm sorğularda, həm də cavablarda istifadə olunan bir neçə başlıq növləri bunlardır:

Bu yazıda bəzi şeyləri artıq əhatə etdik, bəzilərini ikinci hissədə daha ətraflı müzakirə edəcəyik.

via başlığı TRACE sorğusunda istifadə olunur və bütün proxy serverlər tərəfindən yenilənir.

Pragma başlığı fərdi başlıqları siyahıya almaq üçün istifadə olunur. Məsələn, Pragma: no-cache, Cache-Control: no-cache ilə eynidir. Bu barədə ikinci hissədə daha çox danışacağıq.

Tarix başlığı sorğunun/cavabın tarixini və vaxtını saxlamaq üçün istifadə olunur.

Upgrade başlığı protokolu dəyişdirmək üçün istifadə olunur.

Transfer-Encoding, Transfer-Encoding: chunked istifadə edərək cavabı bir neçə hissəyə bölmək üçün nəzərdə tutulub. Bu HTTP/1.1-də yeni xüsusiyyətdir.

Müəssisə Başlıqları

Müəssisə başlıqları məzmun haqqında meta məlumat verir:

Content prefiksli bütün başlıqlar mesajın mətninin strukturu, kodlaşdırılması və ölçüsü haqqında məlumat verir.

İstifadə müddəti başa çatır başlığı obyektin bitmə vaxtı və tarixini ehtiva edir. “Heç vaxt bitməz” dəyəri cari andan etibarən vaxt + 1 kod deməkdir. Son Dəyişiklikdə obyektin sonuncu dəfə dəyişdirildiyi vaxt və tarix var.

Bu başlıqlardan istifadə edərək, tapşırıqlarınız üçün lazım olan məlumatları təyin edə bilərsiniz.

Sorğu Formatı

Sorğu belə görünür:

Sorğu Xətti = Metod SP URI SP HTTP-Versiya CRLF Metod = "SEÇİMLƏR" | "Baş" | "GET" | "POST" | "QOYUN" | "SİL" | "İZ"

SP tokenlər arasında ayırıcıdır. HTTP versiyası HTTP-Versiyasında göstərilmişdir. Həqiqi sorğu belə görünür:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Bağlantı: canlı saxlama Keş-nəzarət: keş-nəzarət yoxdur Praqma: önbellek yoxdur Qəbul: mətn/html, proqram/xhtml+xml, proqram/xml; q=0.9,*/*;q=0.8

Mümkün sorğu başlıqlarının siyahısı:

Accept başlığı dəstəklənən mim növlərini, dili və simvol kodlamasını müəyyən edir. From, Host, Referer və User-Agent başlıqlarında müştəri haqqında məlumat var. If- prefiksləri şərait yaratmaq üçün nəzərdə tutulub. Şərt keçməzsə, 304 Dəyişdirilmədi xətası baş verəcək.

Cavab Formatı

Cavab formatı yalnız statusda və bir sıra başlıqlarda fərqlənir. Status belə görünür:

Status-Line = HTTP-Versiya SP Status-Code SP Səbəb-İfadəsi CRLF

HTTP versiyası
Status kodu
İnsan tərəfindən oxuna bilən status mesajı

Normal vəziyyət belə görünür:

HTTP/1.1 200 OK

Cavab başlıqları aşağıdakı kimi ola bilər:

Yaş mesajın serverdə yaradıldığı vaxtdır.
Cavabda dəyişiklikləri və dəyişiklikləri yoxlamaq üçün ETag MD5 obyektləri.
Məkan yönləndirmə üçün istifadə olunur və yeni URL-i ehtiva edir.
Server cavabın yaradıldığı serveri təyin edir.

Düşünürəm ki, bu gün üçün kifayət qədər nəzəriyyədir. İndi HTTP mesajlarını izləmək üçün istifadə edə biləcəyimiz alətlərə nəzər salaq.

HTTP trafikini aşkar etmək üçün alətlər

HTTP trafikinə nəzarət etmək üçün bir çox vasitə var. Onlardan bir neçəsini təqdim edirik:

Ən çox istifadə edilən Chrome Tərtibatçı Alətləridir:

Sazlayıcı haqqında danışsaq, Fiddler-dən istifadə edə bilərsiniz:

HTTP trafikinə nəzarət etmək üçün sizə curl, tcpdump və tshark lazımdır.

HTTP ilə işləmək üçün kitabxanalar - jQuery AJAX

jQuery çox populyar olduğundan, AJAX sorğuları üçün HTTP cavablarını idarə etmək üçün alətlər də var. jQuery.ajax(parametrlər) haqqında məlumatı rəsmi internet saytında tapa bilərsiniz.

Parametrlər obyektini ötürməklə və beforeSend geri çağırış funksiyasından istifadə etməklə biz setRequestHeader() metodundan istifadə edərək sorğu başlıqlarını təyin edə bilərik.

$.ajax(( url: "http://www.articles.com/latest", yazın: "GET", beforeSend: funksiyası (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en" ");)))

Sorğu statusunu emal etmək istəyirsinizsə, bunu belə edə bilərsiniz:

$.ajax(( statusCode: ( 404: function() ( alert("səhifə tapılmadı"); ) ) ));

Alt xətt

Budur, HTTP protokolunun əsaslarına ekskursiya. İkinci hissədə daha maraqlı faktlar və misallar yer alacaq.

Proqramçı olsanız da, olmasanız da, bunu bütün İnternetdə görmüsünüz. Hazırda brauzerin ünvan çubuğunda "http://" ilə başlayan bir şey göstərilir. Hətta ilk Hello World skriptiniz anlayışınız olmadan HTTP başlığı göndərdi. Bu yazıda biz HTTP başlıqlarının əsaslarını və onların veb tətbiqlərimizdə necə istifadə oluna biləcəyini öyrənəcəyik.

HTTP başlıqları nədir?

HTTP Hypertext Transfer Protocol deməkdir. World Wide Web bu protokoldan istifadə edir. 1990-cı illərin əvvəllərində yaradılmışdır. Brauzerinizdə gördüyünüz demək olar ki, hər şey HTTP vasitəsilə kompüterinizə ötürülür. Məsələn, bu məqalə üçün səhifəni açdığınız zaman brauzeriniz 40-dan çox HTTP sorğusu göndərdi və onların hər biri üçün HTTP cavabları aldı.

HTTP başlıqları bu HTTP sorğularının və cavablarının əsas hissəsidir və onlar müştərinin brauzeri, tələb olunan səhifə, server və s. haqqında məlumat daşıyır.

Misal

Ünvan çubuğuna URL daxil etdiyiniz zaman brauzeriniz HTTP sorğusu göndərir və bu belə görünə bilər:

GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1 Host: net.tutsplus.com İstifadəçi-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9. 1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Qəbul edin: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Qəbul-Dil: az -us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120 Praqma: önbelleksiz Keş-nəzarət: önbellek yoxdur

Birinci sətir sorğu haqqında bəzi əsas məlumatları ehtiva edən "Sorğu Xətti"dir. Qalanları HTTP başlıqlarıdır.

Bu sorğudan sonra brauzeriniz belə görünə bilən HTTP cavabı alır:

HTTP/1.x 200 OK Transfer-Kodlaşdırma: parçalanmış Tarix: Şənbə, 28 Noyabr 2009 04:36:25 GMT Server: LiteSpeed Bağlantı: X-Powered-By: W3 Total Cache/0.8 Pragma: ictimai Bitmə vaxtı: Şənbə , 28 Noyabr 2009 05:36:25 GMT Etag: "pub1259380237;gz" Cache-Control: max-age=3600, public Content-Type: text/html; charset=UTF-8 Son Modifikasiya: Şənbə, 28 Noyabr 2009 03:50:37 GMT X-Pingback: http://net.tutsplus.com/xmlrpc.php Məzmun-kodlaşdırma: gzip Fərqli: Qəbul-Encoding, Cookie, İstifadəçi-Agent Ən yaxşı 20+ MySQL Ən Yaxşı Təcrübələri - Nettuts+

Birinci sətir boş sətirə qədər "Status Xətti", ardınca "HTTP Başlıqları"dır. Bundan sonra "məzmun" (bu halda HTML çıxışı) başlayır.

Brauzerinizdə veb səhifənin mənbə koduna baxdığınız zaman HTTP başlıqlarını deyil, HTML-nin yalnız bir hissəsini görürsünüz, baxmayaraq ki, onlar həqiqətən birlikdə göndərilmişdir.

Bu HTTP sorğuları həmçinin şəkillər, CSS faylları, JavaScript faylları və s. kimi başqa şeylər üçün göndərilir və qəbul edilir. Buna görə də əvvəllər dedim ki, siz yalnız bu məqalə səhifəsini endirdiyinizdən bəri brauzeriniz ən azı 40 və ya daha çox HTTP sorğusu göndərib.

İndi strukturu daha ətraflı nəzərdən keçirək.

HTTP başlıqlarını necə görmək olar

HTTP başlıqlarını təhlil etmək üçün aşağıdakı Firefox uzantılarından istifadə edirəm:

HTTP sorğularında HTTP başlıqları

İndi biz HTTP sorğularında tapılan ən ümumi HTTP başlıqlarından bəzilərinə baxacağıq.

Bu başlıqların demək olar ki, hamısını PHP-də $_SERVER massivində tapmaq olar. Bütün başlıqları bir anda əldə etmək üçün getallheaders() funksiyasından da istifadə edə bilərsiniz.

Ev sahibi

HTTP sorğusu xüsusi IP ünvanlarına göndərilir. Lakin əksər serverlər bir IP altında birdən çox sayt yerləşdirməyə qadir olduğundan, onlar brauzerin hansı domen adını axtardığını bilməlidirlər.

Ev sahibi: net.tutsplus.com

Bu, əsasən domen və alt domen daxil olmaqla, host adıdır.

PHP-də onu $_SERVER["HTTP_HOST"] və ya $_SERVER["SERVER_NAME"] kimi tapmaq olar.

İstifadəçi-Agent

İstifadəçi Agenti: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)

Bu başlıqda bir neçə məlumat ola bilər, məsələn:

Brauzer adı və versiyası.
Əməliyyat sisteminin adı və versiyası.
Defolt dil.

Veb saytlar sörfçü sistemləri haqqında müəyyən ümumi məlumatları necə toplaya bilər. Məsələn, onlar sörfçünün mobil brauzerdən istifadə edib-etmədiyini aşkar edə və onları öz veb-saytının mobil versiyasına yönləndirə bilər ki, bu da daha aşağı qətnamə ilə işləyir.

PHP-də bunu belə ifadə etmək olar: $_SERVER["HTTP_USER_AGENT"].

Əgər (strstr($_SERVER["HTTP_USER_AGENT"],"MSIE 6")) ( "Lütfən, IE6 istifadə etməyi dayandırın!"; ) əks-səda verirsə

Qəbul Dili

Qəbul Dili: en-us,en;q=0.5

Bu başlıq standart dil parametrlərini göstərir. Saytın müxtəlif dil versiyaları varsa, bu məlumatlara əsaslanaraq yeni sörfçünü yönləndirə bilər.

PHP-də bunu belə tapmaq olar: $_SERVER["HTTP_ACCEPT_LANGUAGE"].

Əgər (substr($_SERVER["HTTP_ACCEPT_LANGUAGE"], 0, 2) == "fr") ( başlıq("Yer: http://french.mydomain.com"); )

Qəbul-kodlaşdırma

Qəbul-kodlaşdırma: gzip, deflate

Müasir brauzerlərin əksəriyyəti gzip-i dəstəkləyir və bunu başlıqda göndərir. Veb server daha sonra HTML çıxışını sıxılmış formatda göndərə bilər. Bu, bant genişliyinə və vaxta qənaət etmək üçün ölçüsü 80%-ə qədər azaldır.

PHP-də bunu belə tapmaq olar: $_SERVER["HTTP_ACCEPT_ENCODING"]. Bununla belə, siz ob_gzhandler() geri çağırış funksiyasından istifadə etdiyiniz zaman o, dəyəri avtomatik olaraq yoxlayacaq, ona görə də sizə lazım deyil.

// çıxışın buferləşdirilməsinə imkan verir // və brauzer bunu dəstəklədiyi halda bütün çıxış sıxılır ob_start("ob_gzhandler");

Əgər-Dəyişdirilsə-Bundan sonra

Əgər veb-sənəd brauzerinizdə artıq keşlənibsə və siz onu yenidən ziyarət edirsinizsə, brauzeriniz aşağıdakıları göndərməklə sənədin yenilənib-yenilənmədiyini yoxlaya bilər:

Həmin tarixdən bəri dəyişməyibsə, server "304 Dəyişdirilməmiş" cavab kodu göndərir, lakin məzmun dəyişmir və brauzer məzmunu keşdən yükləyir.

PHP-də bunu belə tapmaq olar: $_SERVER["HTTP_IF_MODIFIED_SINCE"].

// fərz edək ki, $last_modify_time çıxışın sonuncu yeniləndiyi vaxt olub // brauzer If-Modified-Since başlığını göndərib? if(isset($_SERVER["HTTP_IF_MODIFIED_SINCE"])) ( // brauzer önbelleği dəyişdirmə vaxtı ilə uyğun gəlirsə, əgər ($last_modify_time == strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE"])) ( // 304 başlığı göndərin və məzmun başlığı yoxdur("HTTP/1.1 304 Dəyişdirilməmişdir");

Cari keşi yoxlamaq üçün istifadə edilə bilən Etag HTTP başlığı da var. Bu barədə bir azdan danışacağıq.

Kuki

Adından da göründüyü kimi, bu, həmin domen üçün brauzerinizdə saxlanılan kukiləri göndərir.

Kuki: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120; foo = bar

Bunlar nöqtəli vergüllə ayrılmış ad=dəyər cütləridir. Kukilərdə seans id də ola bilər.

PHP-də fərdi kukilərə $_COOKIE massivindən istifadə etməklə daxil olmaq olar. Siz $_SESSION massivindən istifadə edərək birbaşa sessiya dəyişənlərinə daxil ola bilərsiniz və əgər sizə sessiya id-si lazımdırsa, kuki əvəzinə session_id() funksiyasından istifadə edə bilərsiniz.

Echo $_COOKIE["foo"]; // çıxış: bar echo $_COOKIE["PHPSESSID"]; // çıxış: r2t5uvjq435r4q7ib3vtdjq120 session_start(); echo session_id(); // çıxış: r2t5uvjq435r4q7ib3vtdjq120

İstinad edən

Adından da göründüyü kimi, bu HTTP başlığında istinad url var.

Məsələn, Nettuts+ ana səhifəsinə keçib məqalə linkinə klikləsəm, bu başlıq brauzerimə göndəriləcək:

İstinadçı: http://net.tutsplus.com/

PHP-də onu $_SERVER["HTTP_REFERER"] kimi tapmaq olar.

Əgər (isset($_SERVER["HTTP_REFERER"])) ( $url_info = parse_url($_SERVER["HTTP_REFERER"]); // sörfçü Google-dan gəlir? if ($url_info["host"] == "www .google.com") ( parse_str($url_info["query"], $vars); echo "Bu açar sözü Google-da axtarmısınız: ". $vars["q"]; ) ) // əgər istinad edilən url olubsa : // http://www.google.com/search?source=ig&hl=en&rlz=&=&q=http+headers&aq=f&oq=&aqi=g-p1g9 // çıxış belə olacaq: // Siz Google-da axtarış etdiniz bu açar söz: http başlıqları

Ola bilsin ki, “referrer” sözünün “referer” kimi səhv yazıldığını görmüsünüz. Təəssüf ki, oxşar şəkildə rəsmi HTTP spesifikasiyası oldu və ilişib qaldı.

Səlahiyyət

Avtorizasiya: Əsas bXl1c2VyOm15cGFzcw==

Başlıq daxilindəki məlumatlar base64 kodludur. Məsələn, base64_decode("bXl1c2VyOm15cGFzcw ==") "myuser: mypass" qaytaracaq

PHP-də bu dəyərləri $_SERVER["PHP_AUTH_USER"] və $_SERVER["PHP_AUTH_PW"] kimi tapmaq olar.

Bu barədə daha çox WWW-Authenticate başlığı haqqında danışırıq.

HTTP cavablarında HTTP başlıqları

İndi HTTP cavablarında tapılan ən çox yayılmış HTTP başlıqlarına baxacağıq.

PHP-də siz header() funksiyasından istifadə edərək cavab başlıqlarını təyin edə bilərsiniz. PHP artıq məzmunun yüklənməsi, kukilərin və digər əşyaların qurulması üçün müəyyən başlıqları avtomatik göndərir... Siz headers_list() funksiyasından istifadə edərək göndərilən və ya göndəriləcək başlıqları görə bilərsiniz. Siz headers_sent() funksiyasından istifadə edərək başlıqların artıq göndərilib-göndərilmədiyini yoxlaya bilərsiniz.

Keş-nəzarət

w3.org-dan tərif: "Cache-Control başlıq sahəsi sorğu/cavab zənciri boyunca bütün keşləmə mexanizmləri tərəfindən izlənilməli olan direktivləri müəyyən etmək üçün istifadə olunur." Bu "keşləmə mexanizmləri"nə internet provayderinizin istifadə edə biləcəyi şlüzlər və proksilər daxildir.

Cache-Control: max-age=3600, ictimai

"ictimai" cavabın hər kəs tərəfindən yaddaşda saxlanıla biləcəyi deməkdir. "maksimum yaş" keşin neçə saniyə etibarlı olduğunu göstərir. Saytınızın önbelleğe alınmasına icazə vermək server yükünü və bant genişliyini azalda və brauzerin yüklənmə vaxtını yaxşılaşdıra bilər.

Keşləmənin qarşısını "no-cache" direktivindən istifadə etməklə də almaq olar.

Cache-Control: heç bir önbellek

Məzmun növü

Bu başlıq sənədin "mime-növünü" təyin edir. Brauzer daha sonra bunun əsasında məzmunu necə şərh edəcəyini müəyyənləşdirir. Məsələn, html səhifəsi (və ya html çıxışı olan PHP skripti) bunu qaytara bilər:

Məzmun növü: mətn/html; charset=UTF-8

"mətn" növü, "html" isə sənədin alt növüdür. Başlıqda simvol dəsti kimi daha çox məlumat da ola bilər.

Bir gif şəkli üçün bu göndərilə bilər.

Məzmun növü: şəkil/gif

Brauzer mime tipinə əsaslanan xarici proqram və ya brauzer genişlənməsindən istifadə edə bilər. Məsələn, bu, Adobe Reader proqramını yükləyəcək:

Məzmun növü: proqram/pdf

Birbaşa yükləyərkən, Apache adətən sənədin mim növünü aşkar edə və müvafiq başlığı göndərə bilər. Bundan əlavə, əksər brauzerlərdə müəyyən dərəcədə nasazlığa dözümlülük var və başlıqlar səhv və ya çatışmazsa, mim növlərini avtomatik aşkarlayır.

Siz ümumi mim növlərinin siyahısını tapa bilərsiniz.

PHP-də faylın mim növünü təyin etmək üçün finfo_file() funksiyasından istifadə edə bilərsiniz.

Məzmun-Ərazi

Bu başlıq brauzerə məzmunu təhlil etmək əvəzinə fayl endirmə pəncərəsini açmağı bildirir. Misal:

Məzmun-Dispozisiya: əlavə; fayl adı = "download.zip"

Bu, brauzeri bunu etməyə məcbur edəcək:

Qeyd edək ki, müvafiq Məzmun Tipi başlığı da bununla birlikdə göndərilməlidir:

Məzmun növü: proqram/zip Məzmun-Disposition: əlavə; fayl adı = "download.zip"

Məzmun Uzunluğu

Məzmun brauzerə təqdim edildikdə, server bu başlıqdan istifadə edərək ölçüsünü (baytla) təyin edə bilər.

Məzmun uzunluğu: 89123

Bu, faylları endirərkən xüsusilə faydalıdır. Brauzer yükləmənin gedişatını belə müəyyən edə bilər.

Məsələn, burada yavaş yükləməni simulyasiya edən, yazdığım saxta skript var.

// bu zip fayl başlığıdır("Məzmun növü: proqram/zip"); // 1 milyon bayt (təxminən 1 meqabayt) başlıq("Məzmun uzunluğu: 1000000"); // yükləmə dialoqunu yükləyin və onu yadda saxlayın download.zip başlığı ("Content-Disposition: attachment; filename="download.zip"") // 1000 dəfə 1000 bayt data ($i = 0; $i< 1000; $i++) { echo str_repeat(".",1000); // sleep to slow down the download usleep(50000); }

Nəticə budur:

İndi Content-Length başlığını şərh edəcəyəm

// bu zip faylının başlığıdır("Məzmun növü: proqram/zip"); // brauzer ölçüsünü bilməyəcək // başlıq("Məzmun uzunluğu: 1000000"); // endirmə dialoqunu yükləyin və onu download.zip başlığı kimi yadda saxlayın("Məzmun-Disposition: attachment; filename="download.zip""); // 1000 dəfə 1000 bayt məlumat ($i = 0; $i< 1000; $i++) { echo str_repeat(".",1000); // sleep to slow down the download usleep(50000); }

İndi nəticə belədir:

Brauzer yalnız neçə bayt yükləndiyini deyə bilər, lakin ümumi məbləği bilmir. Və tərəqqi çubuğu tərəqqi göstərmir.

Etag

Bu, keşləmə üçün istifadə olunan başqa bir başlıqdır. Bu belə görünür:

Etaq: "pub1259380237;gz"

Veb server bu başlığı xidmət etdiyi hər bir sənədlə göndərə bilər. Dəyər son dəyişdirilmiş tarixə, fayl ölçüsünə və ya hətta fayl yoxlama məbləğinə əsaslana bilər. Brauzer daha sonra sənədi önbelleğe aldığı üçün bu dəyəri saxlayır. Növbəti dəfə brauzer eyni faylı tələb etdikdə bunu HTTP sorğusunda göndərir:

Uyğunluq yoxdursa: "pub1259380237;gz"

Sənədin Etag dəyəri buna uyğun gələrsə, server 200 əvəzinə 304 göndərəcək və məzmun olmayacaq. Brauzer məzmunu öz keşindən yükləyəcək.

Son Dəyişiklik

Adından göründüyü kimi, bu başlıq sənədin GMT formatında sonuncu dəfə dəyişdirildiyi tarixi göstərir:

Son Dəyişiklik: Şənbə, 28 Noyabr 2009 03:50:37 GMT $modify_time = filemtime($file); header("Son Modifikasiya: " . gmdate("D, d M Y H:i:s", $dəyişiklik_zamanı) . " GMT");

Bu, brauzerə sənədi keş etmək üçün başqa bir yol təklif edir. Brauzer bunu HTTP sorğusu ilə göndərə bilər:

Bu barədə daha əvvəl "Dəyişdirildikdə-Since" bölməsində danışdıq.

Məkan

Bu başlıq yönləndirmə üçün istifadə olunur. Cavab kodu 301 və ya 302 olarsa, server bu başlığı da göndərməlidir. Məsələn, http://www.nettuts.com saytına daxil olduğunuz zaman brauzeriniz aşağıdakıları alacaq:

HTTP/1.x 301 Daimi köçürüldü ... Məkan: http://net.tutsplus.com/ ...

PHP-də sörfçünü bu şəkildə yönləndirə bilərsiniz:

Başlıq("Yer: http://net.tutsplus.com/");

Varsayılan olaraq, bu, 302 cavab kodu göndərəcək. 301 əvəzinə göndərmək istəyirsinizsə:

Başlıq("Yer: http://net.tutsplus.com/", doğru, 301);

Set-Cookie

Veb sayt brauzerinizdə kuki qurmaq və ya yeniləmək istədikdə bu başlıqdan istifadə edəcək.

Set-Cookie: dəri = dəri; yol=/; domain=.amazon.com; sona çatır=Bazar, 29 Noyabr 2009 21:42:28 GMT Set-Cookie: session-id=120-7333518-8165026; yol=/; domain=.amazon.com; başa çatır=27 Fevral 08:00:00 2010 GMT

Hər kuki ayrı başlıq kimi göndərilir. Nəzərə alın ki, JavaScript istifadə edərək qurulan kukilər HTTP başlıqlarından keçmir.

PHP-də siz setcookie() funksiyasından istifadə edərək kukiləri təyin edə bilərsiniz və PHP müvafiq HTTP başlıqlarını göndərir.

Setcookie("TestCookie", "foobar");

Bu başlığın göndərilməsinə səbəb olan nədir:

Set-Cookie: TestCookie=foobar

İstifadə müddəti göstərilməyibsə, brauzer pəncərəsi bağlandıqda kuki silinir.

WWW-Autentifikasiya

Sayt bu başlığı HTTP vasitəsilə istifadəçinin autentifikasiyası üçün göndərə bilər. Brauzer bu başlığı görəndə giriş dialoqunu açacaq.

WWW-Authenticate: Əsas realm="Məhdud Sahə"

Nə kimi görünəcək:

sorğu strukturu (8)

HTTP sorğusunda GET kimi parametrlər göndərilir sorğu sətri :

http://example.com/page ?parametr=dəyər&also=başqa

HTTP sorğusunda POST parametrlər URI ilə birlikdə göndərilmir.

Dəyərlər haradadır? Sorğu başlığında? Müraciətin mətnində? Nə kimi görünür?

Cavablar

HTTP POST mesajlarındakı forma dəyərləri sorğu ilə eyni formatda sorğu orqanına göndərilir.

Ətraflı məlumat üçün spesifikasiyaya baxın.

Bəzi veb xidmətləri sizdən dərc etməyi tələb edir data xahiş və metadata ayrıca. Məsələn, uzaq funksiya imzalanmış metadata sətirinin URI-yə daxil edilməsini və verilənlərin HTTP əlavəsinə göndərilməsini gözləyə bilər.

POST sorğusu semantik olaraq belə görünə bilər:

POST /?AuthId=YOURKEY&Action=WebServiceAction&İmza=rcLXfkPldrYm04 HTTP/1.1 Məzmun Növü: mətn/tab-separated-dəyərlər; charset=iso-8859-1 Məzmun uzunluğu: Host: webservices.domain.com Qəbul edin: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Qəbul edin-kodlaşdırma: şəxsiyyət İstifadəçi-Agent: Mozilla/3.0 (uyğundur; Indy Library) adı id John G12N Sarah J87M Bob N33Y

Bu yanaşma məntiqi olaraq QueryString və Body-Post-u veb server üçün "parse təlimatı" olan tək Məzmun Tipindən istifadə edərək birləşdirir.

Qeyd: HTTP/1.1 bükülmüş solda #32 (boşluq) və sağda #10 (Xətt axını) ilə.

İlk öncə GET və POST edək

Alın: Bu serverdə edilən və serverdən və ondan sonra gələn sorğu sətirindən məlumat almaq üçün istifadə edilən standart HTTP sorğusudur? URI-də unikal resursu əldə etmək üçün istifadə olunur.

bu formatdır

GET /someweb.asp?data=value HTTP/1.0

burada data=value ötürülən sorğu sətirinin dəyəridir.

POST: o, məlumatların serverə təhlükəsiz şəkildə göndərilməsi üçün istifadə olunur ki, tələb olunanların hamısı POST sorğu formatıdır

POST /somweb.aspHTTP/1.0 Host: localhost Məzmun Növü: application/x-www-form-urlencoded //burada istənilən formatı yerləşdirə bilərsiniz Məzmun-Uzunluq: 11 //bu, Ad= somenamedən asılıdır.

Niyə GET üzərində POST?

GET-də serverlərə göndərilən dəyər adətən sorğu sətirində əsas URL-ə əlavə olunur. Bu, məlumatlarınızın sındırılmasına imkan verir (bu, etimadnamələrinizin təyin olunduğu Facebook günlərində problem idi) beləliklə, POST məlumatlarınızı gizlədikcə daha təhlükəsiz olan serverə göndərmək üçün Request Body-dən istifadə edən serverə məlumat göndərmək üçün istifadə edirdi. məlumatlarınız və o, məlumatlarınızı sahələrdən alır, onların uzunluğunu hesablayır və məzmun uzunluğu üçün başlığa əlavə edir və heç bir mühüm məlumat birbaşa URL-ə əlavə edilmir.

Sorğunuz qorunduğuna görə, serverə göndərilən istənilən dəyər Sorğu Orqanına göndərilə bilər, çünki ad istifadəçilərin göndərmək istədikləri məlumatları ehtiva edir (və o, URL Kodlu URL Kodlanmış formatında göndərilir) və Sorğu Başlıqları Sorğu Bölməsindəki dəyərləri Sorğu Başlıqları ilə müqayisə edərək sorğunu təhlükəsiz saxlayacaq.

Sorğuların serverlərdə necə yerinə yetirildiyi haqqında əsas məlumatları öyrənmək üçün Google Developer Tools-un şəbəkə bölməsindən istifadə edə bilərsiniz.

və siz həmişə Cache-Control, Origin, Accept kimi Başlıqları Sorğuya daha çox dəyər əlavə edə bilərsiniz.

Qısa cavab: POST sorğularında dəyərlər sorğunun "bədənində" göndərilir. Veb formalarında onlar çox güman ki, proqram/x-www-form-urlencoded və ya multipart/form-data media növü ilə göndərilir. Veb sorğularını idarə etmək üçün nəzərdə tutulmuş proqramlaşdırma dilləri və ya çərçivələr adətən bu cür sorğularla "The Right Thing™" edir və sizə asanlıqla deşifrə olunan dəyərlərə (məsələn, PHP-də $_REQUEST və ya $_POST və ya cgi.FieldStorage()) asan girişi təmin edir. flask .request.form Python).

İndi gəlin bir az kənara çəkilək, bu fərqi başa düşməyə kömək edə bilər;)

GET və POST sorğuları arasındakı fərq əsasən semantikdir. Onlar da fərqli şəkildə "istifadə olunur" ki, bu da mənaların necə çatdırılmasında fərqi izah edir.

GET (müvafiq RFC bölməsi)

GET sorğusu edərkən, siz serverdən bir və ya bir sıra obyekt tələb edirsiniz. Müştəriyə nəticəni süzgəcdən keçirməyə icazə vermək üçün o, URL-in "sorğu sətri" adlanandan istifadə edə bilər. Sorğu sətri sonrakı hissədir? Bu URI sintaksisinin bir hissəsidir.

Beləliklə, tətbiq kodunuz baxımından (bu hissə alır sorğu) bu dəyərlərə daxil olmaq üçün URI-nin sorğu hissəsini yoxlamalı olacaqsınız.

Qeyd edək ki, açarlar və dəyərlər URI-nin bir hissəsidir. Brauzerlər bacarmaq URI uzunluğuna məhdudiyyət qoyur. HTTP standartı heç bir məhdudiyyətin olmadığını bildirir. Lakin bu yazıya görə əksər brauzerlər URI-ləri məhdudlaşdırır (mənim xüsusi dəyərlərim yoxdur). sorğuları GET heç vaxt serverə yeni məlumat göndərmək üçün istifadə edilməlidir. Xüsusilə böyük sənədlər deyil. Burada POST və ya PUT istifadə etməlisiniz.

POST (müvafiq RFC bölməsi)

POST sorğusu edərkən müştəri əslində yenisini göndərir sənəd uzaq hosta. Beləliklə, xətt xahiş(semantik olaraq) mənası yoxdur. Buna görə tətbiq kodunuzda onlara girişiniz yoxdur.

POST bir az daha mürəkkəbdir (və daha çevikdir):

POST sorğusunu qəbul edərkən siz həmişə "faydalı yük" və ya HTTP termini ilə desək: mesaj orqanı gözləməlisiniz. Mesaj gövdəsinin özü olduqca yararsızdır, çünki yoxdur standart(deyə bildiyim qədər. Bəlkə proqram/octet-stream?) formatı. Bədən formatı Content-Type başlığı ilə müəyyən edilir. Metod="POST" ilə HTML FORM elementindən istifadə edərkən bu adətən application/x-www-form-urlencoded olur. Əgər fayl yükləməsindən istifadə edirsinizsə, başqa bir çox yayılmış növ çoxhissəli/forma verilənləridir. Amma bəlkə hər şey: mətndən/düzdən, proqram/json üzərindən və ya hətta xüsusi proqram/oktet axını ilə.

İstənilən halda, POST sorğusu tətbiq tərəfindən emal edilə bilməyən Məzmun Növü ilə edilirsə, o, 415 status kodunu qaytarmalıdır.

Əksər proqramlaşdırma dilləri (və/və ya veb çərçivələri) mesajın mətnini ən çox yayılmış növlərdən (məsələn, proqram/x-www-form-urlencoded, multipart/form-data və ya proqram/ kimi) kodlaşdırmağın bir yolunu təklif edir. json ). Fərdi növlər potensial olaraq bir az daha çox iş tələb edir.

Standart HTML kodlu sənəd nümunəsindən istifadə edərək, proqram aşağıdakı addımları yerinə yetirməlidir:

Məzmun növü sahəsini oxuyun
Əgər dəyər dəstəklənən media növlərindən biri deyilsə, 415 status kodu ilə cavab qaytarın
əks halda, mesajın gövdəsindən dəyərləri deşifrə edin.

Yenə də PHP və ya digər populyar dillər üçün veb çərçivələri kimi dillər, yəqin ki, bunu sizin üçün həll edəcək. İstisna 415 səhvidir. Heç bir çərçivə tətbiqinizin hansı məzmun növlərini dəstəklədiyini və/və ya dəstəkləməyəcəyini proqnozlaşdıra bilməz. Bu sizdən asılıdır.

PUT (müvafiq RFC bölməsi)

PUT sorğusu POST sorğusu ilə eyni şəkildə işlənir. Böyük fərq ondan ibarətdir ki, POST sorğusu serverə yeni resursun necə (əgər varsa) yaradılmasına qərar verməyə imkan verməlidir. Tarixən (indi köhnəlmiş RFC2616-dan, sorğunun göndərildiyi "alt" (alt) URI kimi yeni resurs yaratmalı idi).

PUT sorğusu resursu xüsusi olaraq "kənara qoymalıdır" V bu URI və tam ilə bu məzmun. Nə çox, nə də az. İdeya bundan ibarətdir müştəri yaradılmasına cavabdehdir dolu resursu "QOYMA". Server bunu qəbul etməlidir olduğu kimi verilmiş URL-də.

Nəticədə, POST sorğusu adətən bu məqsədlər üçün istifadə edilmir əvəzedicilər mövcud resurs. PUT sorğusu yarada bilər Vəəvəz et.

Qeyd

Pulta əlavə məlumat göndərmək üçün istifadə edilə bilən "yol parametrləri" də var, lakin bunlar o qədər qeyri-adidir ki, təfərrüata varmayacağam. Ancaq istinad üçün RFC-dən bir parça:

İerarxik yollardakı nöqtə seqmentlərindən başqa, ümumi sintaksisə görə yol seqmenti qeyri-şəffaf sayılır. Tətbiq quran URI-lər çox vaxt seqmentdə icazə verilən qorunan simvollardan xüsusi sxem və ya tərtibata xas olan alt komponentləri ayırmaq üçün istifadə edir. Məsələn, qorunan nöqtəli vergül (";") və bərabər ("=") simvolları çox vaxt həmin seqmentə aid olan parametrləri və parametr dəyərlərini məhdudlaşdırmaq üçün istifadə olunur. Qorunan vergül simvolu ("") tez-tez oxşar məqsədlər üçün istifadə olunur. Məsələn, bir URI istehsalçısı "ad; v=1.1" "ad"ın 1.1 versiyasına istinadı göstərmək üçün, digəri isə onu göstərmək üçün "ad, 1.1" kimi seqmentdən istifadə edə bilər. Parametr növləri sxemə xas semantikadan istifadə etməklə müəyyən edilə bilər, lakin əksər hallarda parametrin sintaksisi URI-dən imtina alqoritminin həyata keçirilməsinə xasdır.

Siz onu birbaşa brauzerinizin URL çubuğuna daxil edə bilməzsiniz.

Məsələn, HTTP başlıqlarından istifadə edərək POST məlumatlarının İnternetdə necə göndərildiyini görə bilərsiniz. Nəticə belə bir şey olacaq

Http://127.0.0.1/pass.php POST /pass.php HTTP/1.1 Host: 127.0.0.1 İstifadəçi-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Accept. text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://127.0.0.1/pass.php Kuki: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5 Əlaqə: canlı saxlamaq Məzmun növü: application/x-www-form-urlencoded Məzmun uzunluğu: 30 istifadəçi adı=zurfyx&pass=password

Harada danışır

Məzmun uzunluğu: 30 istifadəçi adı=zurfyx&pass=password

post dəyərləri olacaq.

Dəyərlər məzmun növündə göstərilən formatda sorğu orqanına göndərilir.

Tipik olaraq məzmun növü application/x-www-form-urlencoded dir, ona görə də sorğu orqanı sorğu sətri ilə eyni formatdan istifadə edir:

Parametr=dəyər&also=başqa

Bir formada fayl yükləməsindən istifadə etdiyiniz zaman, bunun əvəzinə fərqli formata malik olan çoxhissəli/forma məlumat kodlaşdırmasından istifadə edirsiniz. Bu, daha mürəkkəbdir, lakin adətən onun necə göründüyünə diqqət yetirməyə ehtiyac yoxdur, ona görə də nümunə göstərməyəcəm, lakin onun mövcud olduğunu bilmək faydalı ola bilər.

POST sorğusunda standart media növü application/x-www-form-urlencoded-dir. Bu, açar-dəyər cütlərinin kodlaşdırılması üçün formatdır. Açarlar təkrarlana bilər. Hər açar-dəyər cütü & simvolu ilə ayrılır və hər bir açar öz dəyərindən = simvolu ilə ayrılır.

Misal üçün:

Adı: John Smith Sinif: 19

Belə yazılmışdır:

Adı=John+Smith&Qrade=19

HTTP başlıqlarından sonra sorğu orqanında yerləşdirilir.

Sual yenidən oxunur. Verilən faktiki sual CSS xassələrindəki satıcı prefiksləri kimi deyil, burada gələcək yoxlamaq və təchizatçı dəstəyi və rəsmi standartlar haqqında düşünmək mənasızdır. Verilən faktiki sual daha çox URL sorğusu parametr adlarının seçilməsinə bənzəyir. Onların kim olduğu heç kəsin vecinə olmamalıdır. Amma adların adi adlarla üst-üstə düşməsi tamamilə düzgün, ümumi və düzgün bir şeydir.

Səbəb:
Bu haqqında xüsusi proqram başlıqları üçün tərtibatçılar arasında razılaşmalar - « onların hesabı ilə bağlı məlumatlar- üçüncü tərəflər tərəfindən həyata keçirilməli olan təchizatçılar, standart qurumlar və ya protokollarla heç bir əlaqəsi olmayan, istisna olmaqla, sözügedən tərtibatçı sadəcə olaraq serverlər, proksilər və ya müştərilər tərəfindən istifadə üçün başqa məqsədləri ola bilən başlıqlardan qaçmalıdır. Bu səbəbdən verilmiş "X-Gzip/Gzip" və "X-Forwarded-For/Forwarded-For" nümunələri mübahisəlidir. Bu, URL sorğu parametrləri üçün adlandırma konvensiyalarına bənzər şəxsi API kontekstində konvensiyalarla bağlı sualı doğurur. Bu, üstünlük və adlar arasındakı məsafə məsələsidir; "X" olmadan hər hansı proksi və ya provayder tərəfindən dəstəklənən "X-ClientDataFoo" ilə bağlı narahatlıqlar aydın şəkildə yersizdir.

"X-" prefiksi haqqında xüsusi və ya sehrli heç nə yoxdur, lakin bu, bunun fərdi başlıq olduğunu başa düşməyə kömək edir. Əslində, RFC-6648 və digərləri "X-" prefiksinin istifadəsinin qarşısını alır, çünki - HTTP müştəri və server təchizatçıları prefiksdən imtina etdikcə - tətbiqləriniz, şəxsi API-ləriniz, şəxsi məlumatlarınız, ötürmə mexanizminiz adlar arasında toqquşmadan daha yaxşı təcrid olunur. və az sayda rəsmi qorunan titullar. Bununla belə, mənim şəxsi üstünlük və tövsiyəm bir addım irəli getmək və məsələn, "X-ACME-ClientDataFoo" etməkdir (əgər vidjet şirkətiniz "ACME"dirsə).

IMHO IETF spesifikasiyası OP-nin sualına cavab vermək üçün kifayət qədər spesifik deyil, çünki o, tamamilə fərqli istifadə hallarını ayırd edə bilmir: (A) bir tərəfdən "Forwarded-For" kimi qlobal miqyasda tətbiq olunan yeni xüsusiyyətləri həyata keçirən təchizatçılar. (B) Proqram tərtibatçıları proqram üçün xüsusi sətirləri müştəri və serverə ötürür. Spektr yalnız birinciyə aiddir, (A). Burada sual (B) üçün razılaşmaların olub-olmamasıdır. Yemək. Bunlara parametrləri əlifba sırası ilə qruplaşdırmaq və onları bir çox standartlara uyğun (A) tipli başlıqlardan ayırmaq daxildir. "X-" və ya "X-ACME-" prefiksinin istifadəsi (B) üçün əlverişli və qanunidir və (A) ilə ziddiyyət təşkil etmir. Daha çox satıcı (A) üçün “X-” istifadə etməyi dayandırdıqca (B) daha aydın olacaq.

Misal:
Google (müxtəlif standart orqanlarda bir az çəki daşıyan) - bu gündən etibarən, 20141102 cavabıma edilən bu kiçik dəyişiklikdə - hazırda bu cavabın dəyişdirilməsində iştirak edən Apache modulunun versiyasını göstərmək üçün "X-Mod-Pagespeed" istifadə edir. Həqiqətən kimsə Google-a "X-" olmadan "Mod-Pagespeed" istifadə etməyi təklif edir və/və ya IETF-dən onun istifadəsinə xeyir-dua verməsini xahiş edir?

Xülasə:
Əgər siz serverinizə verilənləri ötürmək üçün tətbiqinizdə xüsusi HTTP başlıqlarından istifadə edirsinizsə (bəzən kukilərə uyğun alternativ kimi) və bu başlıqların tətbiqinizin kontekstindən kənarda istifadə edilməsi açıq şəkildə nəzərdə tutulmayıbsa, "X-" prefiksli adları uyğunlaşdırın. və ya "X- FOO-" ağlabatandır və ümumiyyətlə qəbul edilir.

HTTP sorğusu və ya mesajı üç hissədən ibarətdir: sorğu xətti və HTTP mesajının əsas hissəsi.

Sorğu sətri, və ya başlanğıc xətti: serverə edilən sorğuda sorğunun növünü (metodunu), tələb olunan səhifənin URI-sini və versiyasını (məsələn, HTTP/1.1) ehtiva edən sətir. Serverdən gələn cavabda bu sətir HTTP protokolunun versiyasını və cavab kodunu ehtiva edir. Cavab kodu üçrəqəmli tam ədəddir. Onun ardınca adətən kodu izah edən boşluqla ayrılmış izahlı ifadə gəlir, məsələn: 200 OK və ya 404 Not Found.

HTTP sorğu metodları (növləri): GET, POST, PUT, PATCH, HEAD, SİL, İZLƏ. Çox vaxt GET və ya POST metodları HTTP sorğusunda istifadə olunur: GET müəyyən edilmiş URI-də veb səhifənin məzmununu tələb etmək üçün istifadə olunur. URI göstərilmədən səhifənin ünvanıdır, məsələn: site/internet/chto-takoe-http-zapros-soobshhenie/ əvəzinə /internet/chto-takoe-http-zapros-soobshhenie/. Brauzer parametrləri GET-də URI-də "? ": GET /index.php?param1=value1¶m2=value2. Adi GET metodundan əlavə şərti GET və qismən GET də var. Şərti GET sorğularında If-Modified-Since, If-Match, If-Range və oxşar başlıqlar var.

POST - məlumat göndərmək üçün istifadə olunur. POST metodundan istifadə edərək məlumat göndərərkən, GET metodundan istifadə edərək məlumat göndərərkən olduğu kimi, brauzerdəki ünvan daxiletmə xəttində deyil, HTTP mesajının mətnində göstərilir. Məsələn, məqalənin altında yerləşən forma vasitəsilə şərh göndərilərkən POST metodu ilə məlumat serverə ötürülür. Fayllar həmçinin POST metodundan istifadə etməklə serverə yüklənir.

- bu, veb səhifəni düzgün qurmaq üçün istifadə olunan müxtəlif parametrləri ehtiva edən sorğunun bir hissəsidir.

HTTP mesajı— serverdən alınan məlumatları ehtiva edir, məsələn, HTML kodu şəklində yaradılan veb-səhifə və ya resurs, məsələn, şəkil.

Nümunə HTTP mesajları:

Serverə HTTP sorğusu:

GET /internet/chto-takoe-http-zapros-soobshhenie/ HTTP/1..9,image/webp,*/*;q=0.8 İstifadəçi-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 ( KHTML, Gecko kimi) Chrome/40.0.2150.0 Qəbul-kodlaşdırma: gzip, deflate, sdch Qəbul-Dil: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Kuki: wp- parametrlər-1=hidetb%3D; wp-settings-time-1=1424958215; wordpress_test_cookie=WP+Cookie;

Serverdən cavab:

HTTP/1.1 200 OK - cavab başlanğıc xətti: Server: nginx/1.6.2 Tarix: Bazar, 19 Aprel 2015 00:22:50 GMT Məzmun növü: mətn/html; charset=UTF-8 Məzmun Uzunluğu: 9431 Bağlantı: canlı saxla. Alive: timeout=30 X-Powered-By: PHP/5.5.22 Bitmə vaxtı: Çərşənbə, 11 Yanvar 1984 05:00:00 GMT Keş İdarəsi: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Cavab əsası (html səhifəsi) aşağıdakı kimidir.