С прости думи за HTTP. Заявка за параметри: Как се изпращат параметри в HTTP POST заявка? xx: Информационни съобщения

HTTP е протокол за прехвърляне на хипертекст между разпределени системи. Всъщност http е основен елемент на съвременната мрежа. Като уважаващи себе си уеб разработчици трябва да знаем възможно най-много за него.

Нека погледнем този протокол през призмата на нашата професия. В първата част ще разгледаме основите и ще разгледаме заявките/отговорите. В следващата статия ще разгледаме по-подробни функции, като кеширане, обработка на връзката и удостоверяване.

Също така в тази статия ще се позовавам главно на стандарта RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1.

Основи на HTTP

HTTP позволява комуникация между множество хостове и клиенти и поддържа набор от мрежови настройки.

По принцип TCP/IP се използва за комуникация, но това не е единственият възможен вариант. По подразбиране TCP/IP използва порт 80, но могат да се използват и други.

Комуникацията между хоста и клиента се осъществява на два етапа: заявка и отговор. Клиентът генерира HTTP заявка, в отговор на която сървърът предоставя отговор (съобщение). Малко по-късно ще разгледаме тази схема на работа по-подробно.

Текущата версия на HTTP протокола е 1.1, в която са въведени някои нови функции. Според мен най-важните от тях са: поддръжка за постоянно отворена връзка, нов механизъм за пренос на данни, кодиране на пренос на парчета, нови хедъри за кеширане. Ще разгледаме част от това във втората част на тази статия.

URL адрес

Ядрото на уеб комуникацията е заявката, която се изпраща чрез Uniform Resource Locator (URL). Сигурен съм, че вече знаете какво е URL, но за пълнота реших да кажа няколко думи. Структурата на URL адреса е много проста и се състои от следните компоненти:

Протоколът може да бъде http за редовни връзки или https за по-сигурен обмен на данни. Портът по подразбиране е 80. Това е последвано от пътя до ресурса на сървъра и верига от параметри.

Методи

Използвайки URL, ние определяме точното име на хоста, с който искаме да комуникираме, но какво действие трябва да извършим, може да бъде съобщено само чрез HTTP метода. Разбира се, има няколко вида действия, които можем да предприемем. HTTP имплементира най-необходимите, подходящи за нуждите на повечето приложения.

Съществуващи методи:

ВЗЕМЕТЕ: Достъп до съществуващ ресурс. URL адресът изброява цялата необходима информация, така че сървърът да може да намери и върне искания ресурс като отговор.

ПУБЛИКУВАНЕ: Използва се за създаване на нов ресурс. POST заявката обикновено съдържа цялата необходима информация за създаване на нов ресурс.

СЛАГАМ: Актуализирайте текущия ресурс. Заявката PUT съдържа данните, които трябва да бъдат актуализирани.

ИЗТРИЙ: Използва се за изтриване на съществуващ ресурс.

Тези методи са най-популярните и най-често се използват от различни инструменти и рамки. В някои случаи заявките PUT и DELETE се изпращат чрез изпращане на POST, чието съдържание показва действието, което трябва да се извърши върху ресурса: създаване, актуализиране или изтриване.

HTTP поддържа и други методи:

ГЛАВА: Подобно на GET. Разликата е, че при този тип заявка не се предава съобщение. Сървърът получава само заглавките. Използва се например за определяне дали даден ресурс е бил модифициран.

СЛЕДИ: по време на предаване заявката преминава през много точки за достъп и прокси сървъри, всеки от които въвежда своя собствена информация: IP, DNS. Използвайки този метод, можете да видите цялата междинна информация.

НАСТРОИКИ: Използва се за дефиниране на сървърни възможности, настройки и конфигурация за конкретен ресурс.

Статус кодове

В отговор на заявка от клиента, сървърът изпраща отговор, който съдържа и статус код. Този код има специално значение, така че клиентът да може по-ясно да разбере как да интерпретира отговора:

1xx: Информационни съобщения

Набор от тези кодове беше въведен в HTTP/1.1. Сървърът може да изпрати заявка във формата: Expect: 100-continue, което означава, че клиентът все още изпраща останалата част от заявката. Клиентите, изпълняващи HTTP/1.0, игнорират тези заглавки.

2xx: Съобщения за успех

Ако клиентът получи код от серията 2xx, тогава заявката е изпратена успешно. Най-често срещаният вариант е 200 ОК. С GET заявка сървърът изпраща отговор в тялото на съобщението. Има и други възможни отговори:

202 Прието: Заявката е приета, но може да не съдържа ресурса в отговора. Това е полезно за асинхронни заявки от страната на сървъра. Сървърът определя дали да изпрати ресурса или не.
204 Няма съдържание: Няма съобщение в тялото на отговора.
205 Нулиране на съдържанието: Инструктира сървъра да нулира представянето на документа.
206 Частично съдържание: Отговорът съдържа само част от съдържанието. Допълнителните заглавки определят общата дължина на съдържанието и друга информация.

3xx: Пренасочване

Един вид съобщение към клиента за необходимостта от предприемане на още едно действие. Най-честият случай на използване е пренасочване на клиента към друг адрес.

301 Преместен за постоянно: Ресурсът вече може да бъде намерен на различен URL адрес.
303 Вижте други: Ресурсът може временно да бъде намерен на различен URL адрес. Заглавката Location съдържа временен URL адрес.
304 Не е променено: Сървърът определя, че ресурсът не е бил модифициран и клиентът трябва да използва кешираната версия на отговора. За проверка на идентичността на информацията се използва ETag (Entity Tag hash);

4xx: Грешки на клиента

Този клас съобщения се използва от сървъра, ако той реши, че заявката е изпратена по погрешка. Най-често срещаният код е 404 Not Found. Това означава, че ресурсът не е намерен на сървъра. Други възможни кодове:

400 Лоша заявка: Въпросът е формулиран неправилно.
401 Неразрешено: Изисква се удостоверяване, за да направите заявка. Информацията се предава чрез заглавката за оторизация.
403 Забранено: Сървърът не позволи достъп до ресурса.
405 Методът не е разрешен: Използван е невалиден HTTP метод за достъп до ресурса.
409 Конфликт: сървърът не може да обработи напълно заявката, защото се опитва да промени по-нова версия на ресурс. Това често се случва с PUT заявки.

5xx: Сървърни грешки

Поредица от кодове, които се използват за откриване на сървърна грешка при обработка на заявка. Най-често: 500 вътрешна грешка на сървъра. Други възможности:

501 Не е внедрено: Сървърът не поддържа исканата функционалност.
503 Услугата не е достъпна: Това може да се случи, ако сървърът има грешка или е претоварен. Обикновено в този случай сървърът не отговаря и времето, дадено за отговор, изтича.

Формати на съобщения за заявка/отговор

На следващото изображение можете да видите схематичен процес на изпращане на заявка от клиента, обработка и изпращане на отговор от сървъра.

Нека да разгледаме структурата на съобщение, предадено чрез HTTP:

Съобщение = *() CRLF [ ] = Ред за заявка | Статус-ред = Име на поле ":" Стойност на поле

Трябва да има празен ред между заглавката и тялото на съобщението. Може да има няколко заглавия:

Основният текст на отговора може да съдържа цялата или част от информацията, ако съответната функция е активирана (Трансфер-кодиране: на части). HTTP/1.1 също поддържа заглавката Transfer-Encoding.

Общи заглавия

Ето няколко типа заглавки, които се използват както в заявки, така и в отговори:

Вече разгледахме някои неща в тази статия, някои ще разгледаме по-подробно във втората част.

Заглавието via се използва в TRACE заявка и се актуализира от всички прокси сървъри.

Заглавието Pragma се използва за изброяване на персонализирани заглавки. Например Pragma: no-cache е същото като Cache-Control: no-cache. Ще говорим повече за това във втора част.

Заглавието Date се използва за съхраняване на датата и часа на заявката/отговора.

Заглавието Upgrade се използва за промяна на протокола.

Transfer-Encoding има за цел да раздели отговора на множество части с помощта на Transfer-Encoding: chunked. Това е нова функция в HTTP/1.1.

Заглавки на обекти

Заглавките на обекта предават мета информация за съдържанието:

Всички заглавки с префикс Content- предоставят информация за структурата, кодирането и размера на тялото на съобщението.

Заглавката Expires съдържа времето и датата на изтичане на обекта. Стойността „никога не изтича“ означава време + 1 код от текущия момент. Last-Modified съдържа часа и датата, когато обектът е бил последно модифициран.

Използвайки тези заглавки, можете да посочите информацията, необходима за вашите задачи.

Формат на заявката

Искането изглежда по следния начин:

SP е разделителят между токените. HTTP версията е посочена в HTTP-версия. Действителната заявка изглежда така:

GET /articles/http-basics HTTP/1.1 Хост: www.articles.com Връзка: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml; q=0,9,*/*;q=0,8

Списък с възможни заглавки на заявки:

Заглавката Accept указва поддържаните MIME типове, език и кодиране на знаци. Заглавките From, Host, Referer и User-Agent съдържат информация за клиента. If- префиксите са предназначени да създават условия. Ако условието не премине, ще възникне грешка 304 Not Modified.

Формат на отговора

Форматът на отговора се различава само по състоянието и броя на заглавките. Състоянието изглежда така:

Статус-ред = HTTP-версия SP код на състояние SP причина-фраза CRLF

HTTP версия
Код на състоянието
Съобщение за състояние, което може да се чете от човека

Нормалното състояние изглежда така:

HTTP/1.1 200 OK

Заглавките на отговорите могат да бъдат както следва:

Възраст е времето в секунди, когато съобщението е създадено на сървъра.
ETag MD5 обекти за проверка за промени и модификации на отговора.
Местоположението се използва за пренасочване и съдържа новия URL адрес.
Сървърът указва сървъра, където е генериран отговорът.

Мисля, че това е достатъчно теория за днес. Сега нека да разгледаме инструментите, които можем да използваме за наблюдение на HTTP съобщения.

Инструменти за откриване на HTTP трафик

Има много инструменти за наблюдение на HTTP трафик. Ето няколко от тях:

Най-често използваните са Chrome Developers Tools:

Ако говорим за дебъгер, можете да използвате Fiddler:

За да наблюдавате HTTP трафика, ще ви трябват curl, tcpdump и tshark.

Библиотеки за работа с HTTP - jQuery AJAX

Тъй като jQuery е толкова популярен, той също има инструменти за обработка на HTTP отговори за AJAX заявки. Информация за jQuery.ajax(настройки) можете да намерите на официалния уебсайт.

Чрез предаване на обект за настройки и използване на функцията за обратно извикване beforeSend, можем да зададем заглавките на заявката с помощта на метода setRequestHeader().

$.ajax(( url: "http://www.articles.com/latest", тип: "GET", beforeSend: функция (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en "); )))

Ако искате да обработите състоянието на заявката, можете да го направите по следния начин:

$.ajax(( statusCode: ( 404: function() ( alert("страницата не е намерена"); ) ) ));

Долен ред

Ето го, обиколка на основите на HTTP протокола. Втората част ще съдържа още повече интересни факти и примери.

Независимо дали сте програмист или не, виждали сте го навсякъде в Интернет. В момента адресната лента на браузъра показва нещо, което започва с „http://“. Дори първият ви скрипт Hello World изпрати HTTP заглавка без вашето разбиране. В тази статия ще научим за основите на HTTP хедърите и как те могат да се използват в нашите уеб приложения.

Какво представляват HTTP заглавките?

HTTP означава Hypertext Transfer Protocol. Световната мрежа използва този протокол. Създадена е в началото на 90-те години. Почти всичко, което виждате в браузъра си, се прехвърля на компютъра ви чрез HTTP. Например, когато сте отворили страницата за тази статия, вашият браузър е изпратил над 40 HTTP заявки и е получил HTTP отговор за всяка от тях.

HTTP заглавките са основната част от тези HTTP заявки и отговори и носят информация за браузъра на клиента, заявената страница, сървъра и др.

Пример

Когато въведете URL в адресната лента, вашият браузър изпраща HTTP заявка и може да изглежда така:

GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1 Хост: net.tutsplus.com Потребителски агент: 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) 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 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Връзка: keep-alive Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120 Pragma: без кеш Cache-Control: без кеш

Първият ред е "Редът за заявка", който съдържа основна информация за заявката. Останалите са HTTP заглавки.

След тази заявка вашият браузър получава HTTP отговор, който може да изглежда така:

HTTP/1.x 200 OK Transfer-Encoding: chunked Дата: събота, 28 ноември 2009 г. 04:36:25 GMT Сървър: LiteSpeed Връзка: затворете X-Powered-By: W3 Total Cache/0.8 Pragma: публичен Изтича: събота , 28 ноември 2009 г. 05:36:25 GMT Etag: "pub1259380237;gz" Cache-Control: max-age=3600, public Content-Type: text/html; charset=UTF-8 Last-Modified: Sat, 28 Nov 2009 03:50:37 GMT X-Pingback: http://net.tutsplus.com/xmlrpc.php Content-Encoding: gzip Vary: Accept-Encoding, Cookie, Потребителски агент Топ 20+ най-добри практики за MySQL - Nettuts+

Първият ред е „Редът на състоянието“, следван от „HTTP заглавките“, до празния ред. След това започва „съдържанието“ (в този случай HTML изходът).

Когато погледнете изходния код на уеб страница във вашия браузър, виждате само част от HTML, а не HTTP заглавките, въпреки че те всъщност са изпратени.

Тези HTTP заявки също се изпращат и получават за други неща като изображения, CSS файлове, JavaScript файлове и т.н. Ето защо казах по-рано, че вашият браузър е изпратил поне 40 или повече HTTP заявки, откакто сте изтеглили само тази страница със статия.

Сега нека разгледаме структурата по-подробно.

Как да видите HTTP заглавки

Използвам следните разширения на Firefox за анализ на HTTP заглавки:

HTTP заглавки в HTTP заявки

Сега ще разгледаме някои от най-често срещаните HTTP заглавки в HTTP заявки.

Почти всички тези заглавки могат да бъдат намерени в масива $_SERVER в PHP. Можете също да използвате функцията getallheaders(), за да извлечете всички заглавки наведнъж.

Домакин

HTTP заявката се изпраща до конкретни IP адреси. Но тъй като повечето сървъри могат да хостват множество сайтове под едно IP, те трябва да знаят какво име на домейн търси браузърът.

Домакин: net.tutsplus.com

Това е основно името на хоста, включително домейна и поддомейна.

В PHP може да се намери като $_SERVER["HTTP_HOST"] или $_SERVER["SERVER_NAME"].

Потребителски агент

Потребителски агент: 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)

Тази заглавка може да съдържа няколко части от информация, като например:

Име и версия на браузъра.
Име и версия на операционната система.
Език по подразбиране.

Ето как уебсайтовете могат да събират определена обща информация за системите на своите сърфисти. Например, те могат да открият дали сърфист използва мобилен браузър и да го пренасочат към мобилната версия на техния уебсайт, която работи по-добре при по-ниска резолюция.

В PHP може да се изрази така: $_SERVER["HTTP_USER_AGENT"].

If (strstr($_SERVER["HTTP_USER_AGENT"],"MSIE 6")) ( echo "Моля, спрете да използвате IE6!"; )

Приемане на език

Език за приемане: en-us,en;q=0.5

Тази заглавка показва езиковите настройки по подразбиране. Ако даден сайт има различни езикови версии, той може да пренасочи нов сърфиращ въз основа на тези данни.

В PHP може да се намери така: $_SERVER["HTTP_ACCEPT_LANGUAGE"].

If (substr($_SERVER["HTTP_ACCEPT_LANGUAGE"], 0, 2) == "fr") ( header("Местоположение: http://french.mydomain.com"); )

Приемам-Кодиране

Приемане на кодиране: gzip, deflate

Повечето съвременни браузъри поддържат gzip и изпращат това в заглавката. След това уеб сървърът може да изпрати изходния HTML в компресиран формат. Това намалява размера с до 80%, за да спести честотна лента и време.

В PHP може да се намери така: $_SERVER["HTTP_ACCEPT_ENCODING"]. Въпреки това, когато използвате функцията за обратно извикване ob_gzhandler(), тя автоматично ще провери стойността, така че не е необходимо да го правите.

// разрешава буфериране на изхода // и целият изход се компресира, ако браузърът го поддържа ob_start("ob_gzhandler");

If-Modified-Since

Ако уеб документ вече е кеширан във вашия браузър и го посетите отново, вашият браузър може да провери дали документът е актуализиран, като изпрати следното:

Ако не се е променило от тази дата, сървърът изпраща код за отговор „304 Not Modified“, но съдържанието не го прави и браузърът зарежда съдържанието от кеша.

В PHP може да се намери така: $_SERVER["HTTP_IF_MODIFIED_SINCE"].

// приемем, че $last_modify_time е последният изход, който е актуализиран // браузърът изпрати ли If-Modified-Since хедър? if(isset($_SERVER["HTTP_IF_MODIFIED_SINCE"])) ( // ако кешът на браузъра съвпада с времето за промяна if ($last_modify_time == strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE"])) ( // изпраща заглавка 304 и няма заглавка на съдържанието ("HTTP/1.1 304 не е променено"); изход; ) )

Има също Etag HTTP хедър, който може да се използва за проверка на текущия кеш. Ще говорим за това след малко.

бисквитка

Както подсказва името, това изпраща бисквитки, съхранени във вашия браузър за този домейн.

Бисквитка: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120; foo=бар

Това са двойки име=стойност, разделени с точка и запетая. Бисквитките може също да съдържат идентификатор на сесия.

В PHP отделните бисквитки могат да бъдат достъпни с помощта на масива $_COOKIE. Можете да получите директен достъп до променливите на сесията, като използвате масива $_SESSION и ако имате нужда от идентификатора на сесията, можете да използвате функцията session_id() вместо бисквитка.

Echo $_COOKIE["foo"]; // изход: bar echo $_COOKIE["PHPSESSID"]; // изход: r2t5uvjq435r4q7ib3vtdjq120 session_start(); echo session_id(); // изход: r2t5uvjq435r4q7ib3vtdjq120

Референт

Както подсказва името, тази HTTP заглавка съдържа референтен url.

Например, ако отида на началната страница на Nettuts+ и щракна върху връзка към статия, тази заглавка ще бъде изпратена до моя браузър:

Референт: http://net.tutsplus.com/

В PHP може да се намери като $_SERVER["HTTP_REFERER"].

If (isset($_SERVER["HTTP_REFERER"])) ( $url_info = parse_url($_SERVER["HTTP_REFERER"]); // сърфистът идва ли от Google? if ($url_info["host"] == "www .google.com") ( parse_str($url_info["query"], $vars); echo "Търсихте в Google тази ключова дума: ". $vars["q"]; ) ) // ако препращащият url е бил : // http://www.google.com/search?source=ig&hl=en&rlz=&=&q=http+headers&aq=f&oq=&aqi=g-p1g9 // резултатът ще бъде: // Търсихте с Google тази ключова дума: http заглавки

Може би сте забелязали, че думата "референт" е изписана неправилно като "референт". За съжаление, той стана официалната HTTP спецификация по подобен начин и се заби.

Упълномощаване

Упълномощаване: Основно bXl1c2VyOm15cGFzcw==

Данните в заглавката са кодирани base64. Например base64_decode("bXl1c2VyOm15cGFzcw ==") ще върне "myuser: mypass"

В PHP тези стойности могат да бъдат намерени като $_SERVER["PHP_AUTH_USER"] и $_SERVER["PHP_AUTH_PW"].

Повече за това, когато говорим за заглавката WWW-Authenticate.

HTTP заглавки в HTTP отговори

Сега ще разгледаме някои от най-често срещаните HTTP заглавки в HTTP отговорите.

В PHP можете да зададете заглавки на отговорите с помощта на функцията header(). PHP вече изпраща определени заглавки автоматично, за зареждане на съдържание и настройка на бисквитки и други... Можете да видите заглавките, които се изпращат или ще бъдат изпратени, като използвате функцията headers_list(). Можете да проверите дали заглавките вече са изпратени с помощта на функцията headers_sent().

Кеш контрол

Дефиниция от w3.org: „Полето за заглавка Cache-Control се използва за указване на директиви, които ТРЯБВА да бъдат следвани от всички механизми за кеширане по веригата заявка/отговор.“ Тези „механизми за кеширане“ включват шлюзове и проксита, които вашият интернет доставчик може да използва.

Cache-Control: max-age=3600, публичен

"публичен" означава, че отговорът може да бъде кеширан от всеки. "max-age" показва колко секунди е валиден кешът. Разрешаването на вашия сайт да кешира може да намали натоварването на сървъра и честотната лента и да подобри времето за зареждане на браузъра.

Кеширането може също да бъде предотвратено с помощта на директивата "no-cache".

Кеш контрол: без кеш

Тип съдържание

Тази заглавка указва "mime-типа" на документа. След това браузърът определя как да интерпретира съдържанието въз основа на това. Например html страница (или PHP скрипт с html изход) може да върне това:

Content-Type: текст/html; charset=UTF-8

"text" е типът, а "html" е подтипът на документа. Заглавката може също да съдържа повече информация, като набор от знаци.

За gif изображение това може да бъде изпратено.

Тип съдържание: изображение/gif

Браузърът може да използва външно приложение или разширение на браузъра въз основа на mime-типа. Например това ще зареди Adobe Reader:

Тип съдържание: приложение/pdf

Когато се зарежда директно, Apache обикновено може да открие mime типа на документа и да изпрати подходящата заглавка. Освен това повечето браузъри имат известна степен на толерантност към грешки и автоматично откриват mime типове, ако заглавките са неправилни или липсват.

Можете да намерите списък с често срещани типове mime.

В PHP можете да използвате функцията finfo_file(), за да определите mime типа на файл.

Съдържание-разположение

Тази заглавка казва на браузъра да отвори прозорец за изтегляне на файл, вместо да се опитва да анализира съдържанието. Пример:

Съдържание-Разпореждане: запор; име на файл="изтегляне.zip"

Това ще принуди браузъра да направи следното:

Обърнете внимание, че съответната заглавка Content-Type също трябва да бъде изпратена заедно с това:

Content-Type: application/zip Content-Disposition: прикачен файл; име на файл="изтегляне.zip"

Съдържание-дължина

Когато съдържанието се сервира на браузъра, сървърът може да посочи неговия размер (в байтове), като използва тази заглавка.

Дължина на съдържанието: 89123

Това е особено полезно при изтегляне на файлове. Ето как браузърът може да определи напредъка на изтеглянето.

Например, ето макет скрипт, който написах, който симулира бавно зареждане.

// това е заглавка на zip файл ("Content-Type: application/zip"); // 1 милион байта (около 1 мегабайт) заглавка ("Content-Length: 1000000"); // заредете диалогов прозорец за изтегляне и го запазете като download.zip header("Content-Disposition: attachment; filename="download.zip""); // 1000 пъти по 1000 байта данни за ($i = 0; $i< 1000; $i++) { echo str_repeat(".",1000); // sleep to slow down the download usleep(50000); }

Ето резултата:

Сега ще коментирам заглавката Content-Length

// това е заглавка на zip файл ("Content-Type: application/zip"); // браузърът няма да знае размера // header("Content-Length: 1000000"); // заредете диалогов прозорец за изтегляне и го запазете като download.zip header("Content-Disposition: attachment; filename="download.zip""); // 1000 пъти по 1000 байта данни за ($i = 0; $i< 1000; $i++) { echo str_repeat(".",1000); // sleep to slow down the download usleep(50000); }

Сега резултатът е такъв:

Браузърът може да каже само колко байта са били изтеглени, но не знае общата сума. И лентата за напредъка не показва напредъка.

Etag

Това е друг хедър, който се използва за кеширане. Изглежда така:

Etag: "pub1259380237;gz"

Уеб сървърът може да изпрати този хедър с всеки документ, който обслужва. Стойността може да се базира на последната модифицирана дата, размер на файла или дори контролна сума на файл. След това браузърът съхранява тази стойност, докато кешира документа. Следващият път, когато браузърът поиска същия файл, той изпраща това в HTTP заявка:

Ако-няма съвпадение: "pub1259380237;gz"

Ако Etag стойността на документа съвпада с тази, сървърът ще изпрати 304 вместо 200 и няма съдържание. Браузърът ще зареди съдържание от своя кеш.

Последно модифициран

Както подсказва името, тази заглавка показва датата, на която документът е бил последно модифициран във формат GMT:

Последна промяна: събота, 28 ноември 2009 г. 03:50:37 GMT $modify_time = filemtime($file); header("Последна промяна: " . gmdate("D, d M Y H:i:s", $modify_time) . " GMT");

Това предлага на браузъра друг начин за кеширане на документа. Браузърът може да изпрати това в HTTP заявка:

Говорили сме за това преди в секцията If-Modified-Since.

Местоположение

Тази заглавка се използва за пренасочване. Ако кодът на отговор е 301 или 302, сървърът трябва също да изпрати този хедър. Например, когато отидете на http://www.nettuts.com, вашият браузър ще получи следното:

HTTP/1.x 301 Преместен за постоянно ... Местоположение: http://net.tutsplus.com/ ...

В PHP можете да пренасочите сърфиращия по следния начин:

Header("Местоположение: http://net.tutsplus.com/");

По подразбиране това ще изпрати код за отговор 302. Ако искате да изпратите вместо 301:

Header("Местоположение: http://net.tutsplus.com/", true, 301);

Комплект-бисквитка

Когато уебсайт иска да зададе или актуализира бисквитка във вашия браузър, той ще използва тази заглавка.

Set-Cookie: skin=noskin; път=/; домейн=.amazon.com; expires=Sun, 29-Nov-2009 21:42:28 GMT Set-Cookie: session-id=120-7333518-8165026; път=/; домейн=.amazon.com; изтича=Съб 27 февруари 08:00:00 2010 GMT

Всяка бисквитка се изпраща като отделен хедър. Моля, обърнете внимание, че бисквитките, зададени с помощта на JavaScript, не преминават през HTTP заглавки.

В PHP можете да зададете бисквитки с помощта на функцията setcookie() и PHP изпраща съответните HTTP заглавки.

Setcookie("TestCookie", "foobar");

Какво причинява изпращането на този хедър:

Set-Cookie: TestCookie=foobar

Ако не е посочен срок на валидност, бисквитката се изтрива при затваряне на прозореца на браузъра.

WWW-удостоверяване

Сайтът може да изпрати тази заглавка, за да удостовери потребителя чрез HTTP. Когато браузърът види този хедър, той ще отвори диалогов прозорец за влизане.

WWW-Authenticate: Basic realm="Restricted Area"

Как ще изглежда:

структура на заявката (8)

В HTTP заявка ВЗЕМЕТЕпараметрите се изпращат като низ за заявка :

http://example.com/page ?параметър=стойност&също=друго

В HTTP заявка ПУБЛИКУВАНЕпараметрите не се изпращат заедно с URI.

Къде са ценностите? В заглавката на заявката? В тялото на заявката? Как изглежда?

Отговори

Стойностите на формуляра в HTTP POST съобщенията се изпращат до тялото на заявката в същия формат като заявката.

За повече информация вижте спец.

Някои уеб услуги изискват да публикувате данниискане и метаданниотделно. Например отдалечена функция може да очаква подписан низ от метаданни да бъде включен в URI и данните да бъдат изпратени в HTTP приложение.

POST заявка може семантично да изглежда така:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1 Content-Type: text/tab-separated-values; charset=iso-8859-1 Content-Length: Host: webservices.domain.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: identity Потребителски агент: Mozilla/3.0 (съвместим; Indy Library) име id John G12N Sarah J87M Bob N33Y

Този подход логично съчетава QueryString и Body-Post, използвайки един Content-Type, който е "инструкция за анализ" за уеб сървъра.

Забележка: HTTP/1.1 увитна #32 (интервал) вляво и с #10 (подаване на ред) вдясно.

Първо, нека ВЗЕМЕМЕ и ПОСТУВАМЕ

Вземете:Това ли е стандартната HTTP заявка, която се прави на сървъра и се използва за извличане на данни от сървъра и низа на заявката, който идва след това? в URI се използва за извличане на уникален ресурс.

това е форматът

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

тук data=value е подадената стойност на низа на заявката.

ПУБЛИКАЦИЯ:той се използва за безопасно изпращане на данни към сървъра, така че всичко, което е необходимо, е форматът на POST заявка

POST /somweb.aspHTTP/1.0 Хост: localhost Content-Type: application/x-www-form-urlencoded //можете да поставите произволен формат тук Content-Length: 11 //зависи Name= somename

Защо POST вместо GET?

В GET стойността, изпратена до сървърите, обикновено се добавя към основния URL адрес в низа на заявката. Това позволява вашите данни да бъдат хакнати (това беше проблем в дните на Facebook, където вашите идентификационни данни бяха зададени), така че POST използва за изпращане на данни до сървъра, който използва Request Body, за да изпрати вашите данни до сървъра, който е по-сигурен, тъй като скрива вашите данни и получава вашите данни от полетата, изчислява дължината им и ги добавя към заглавката за дължина на съдържанието и никакви важни данни не се добавят директно към URL адреса

Сега, когато вашата заявка е защитена, всички стойности, изпратени до сървъра, могат да бъдат изпратени до тялото на заявката, тъй като името предполага, че ще съдържа данните, които потребителите биха искали да изпратят (и се изпращат в URL кодиран URL кодиран формат) и заглавките на заявката ще пазят заявката в безопасност, като сравняват стойностите в тялото на заявката с заглавките на заявката

Можете да използвате мрежовия раздел на Google Developer Tools, за да намерите основна информация за това как се изпълняват заявките на сървърите.

и винаги можете да добавите повече стойности към заглавките на заявките като Cache-Control, Origin, Accept.

Кратък отговор:в POST заявките стойностите се изпращат в „тялото“ на заявката. В уеб формуляри те най-вероятно се изпращат с типа медия application/x-www-form-urlencoded или multipart/form-data. Програмните езици или рамки, предназначени да обработват уеб заявки, обикновено правят „Правилното нещо™“ с такива заявки и ви осигуряват лесен достъп до лесно декодирани стойности (напр. $_REQUEST или $_POST в PHP или cgi.FieldStorage(), колба .request.form в Python).

Сега нека се отклоним малко, което може да ви помогне да разберете разликата ;)

Разликата между GET и POST заявките е до голяма степен семантична. Те също така се „използват“ по различен начин, което обяснява разликата в това как се предават значенията.

GET (съответстващ RFC раздел)

Когато правите GET заявка, вие питате сървъра за един или набор от обекти. За да позволи на клиента да филтрира резултата, той може да използва това, което се нарича "низ на заявка" на URL адреса. Низът на заявката частта след ли е? Това е част от синтаксиса на URI.

И така, по отношение на кода на вашето приложение (частта, която получавазаявка) ще трябва да проверите частта за заявка на URI за достъп до тези стойности.

Имайте предвид, че ключовете и стойностите са част от URI. Браузъри моганалага ограничение на дължината на URI. HTTP стандартът гласи, че няма ограничения. Но към момента на писане повечето браузъри ограничават URI (нямам конкретни стойности). GET заявки никогатрябва да се използва за изпращане на нова информация към сървъра. Особено не големи документи. Тук трябва да използвате POST или PUT.

POST (съответстващ RFC раздел)

Когато прави POST заявка, клиентът всъщност изпраща нова документкъм отдалечения хост. Така че линията исканеняма (семантично) смисъл. Ето защо нямате достъп до тях в кода на приложението си.

POST е малко по-сложен (и по-гъвкав):

Когато получавате POST заявка, винаги трябва да очаквате "полезен товар" или в термините на HTTP: тялото на съобщението. Самото тяло на съобщението е доста безполезно, защото няма стандартен(доколкото мога да преценя. Може би приложение/октет-поток?) формат. Форматът на тялото се определя от заглавката Content-Type. Когато използвате HTML FORM елемент с method="POST", това обикновено е application/x-www-form-urlencoded. Друг много често срещан тип е multipart/form-data, ако използвате качване на файл. Но може би нещо: от text/plain, над application/json или дори с персонализирано приложение/octet-stream.

Във всеки случай, ако се направи POST заявка с Content-Type, който не може да бъде обработен от приложението, то трябва да върне код на състоянието 415.

Повечето езици за програмиране (и/или уеб рамки) предлагат начин за декодиране на тялото на съобщението от/към най-често срещаните типове (като application/x-www-form-urlencoded, multipart/form-data или application/ json ) Така че е лесно. Персонализираните типове изискват потенциално малко повече работа.

Използвайки стандартен пример за кодиран HTML документ, приложението трябва да изпълни следните стъпки:

Прочетете полето Content-Type
Ако стойността не е един от поддържаните типове носители, върнете отговор с код на състояние 415
в противен случай декодирайте стойностите от тялото на съобщението.

Отново, езици като PHP или уеб рамки за други популярни езици вероятно ще се справят с това вместо вас. Изключение прави грешка 415. Никоя рамка не може да предвиди какви видове съдържание вашето приложение избира да поддържа и/или да не поддържа. Зависи от теб.

PUT (съответстващ RFC раздел)

PUT заявката се обработва точно както POST заявката. Голямата разлика е, че POST заявката трябва да позволи на сървъра да реши как (ако изобщо) да създаде новия ресурс. Исторически (от вече остарелия RFC2616, той трябваше да създаде нов ресурс като "под" (дете) URI, където е изпратена заявката).

Заявката PUT трябва да "остави настрана" конкретно ресурса Vтози URI и точно стова съдържание. Нито повече, нито по - малко. Идеята е, че клиентотговаря за създаването пъленресурс към "PUTtting". Сървърът трябва да го приеме както ена дадения URL адрес.

В резултат на това POST заявката обикновено не се използва за заменисъществуващ ресурс. PUT заявка може да създаде Изамени.

Забележка

Има и „параметри на пътя“, които могат да се използват за изпращане на допълнителни данни към дистанционното, но те са толкова необичайни, че няма да навлизам в подробности. Но за справка, ето извадка от RFC:

Освен точковите сегменти в йерархичните пътища, сегментът на пътя се счита за непрозрачен от общия синтаксис. URI адресите за изграждане на приложения често използват запазените знаци, разрешени в сегмента, за да разграничат подкомпонентите, които са специфични за определена схема или оформление. Например запазената точка и запетая (";") и знаците за равно ("=") често се използват за ограничаване на параметри и стойности на параметри, които се прилагат към този сегмент. Запазеният знак запетая (",") често се използва за подобни цели. Например, един производител на URI може да използва сегмент като „име; v=1.1", за да посочи препратка към версия 1.1 на "име", докато друг може да използва сегмент като "име, 1.1", за да го посочи. Типовете параметри могат да бъдат дефинирани с помощта на специфична за схемата семантика, но в повечето случаи синтаксисът на параметрите е специфичен за изпълнението на алгоритъма за дерефериране на URI.

Не можете да го въведете директно в URL лентата на браузъра.

Можете да видите как POST данните се изпращат в Интернет с помощта на HTTP заглавки например. Резултатът ще бъде нещо подобно

Http://127.0.0.1/pass.php POST /pass.php HTTP/1.1 Хост: 127.0.0.1 Потребителски агент: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Приемам: 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 Бисквитка: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5 Връзка: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 30 username=zurfyx&pass=password

Къде говори

Дължина на съдържанието: 30 потребителско име=zurfyx&pass=парола

ще има пост стойности.

Стойностите се изпращат до тялото на заявката във формата, посочен в типа съдържание.

Обикновено типът съдържание е application/x-www-form-urlencoded, така че тялото на заявката използва същия формат като низа на заявката:

Параметър=стойност&също=друго

Когато използвате качване на файл във формуляр, вие използвате вместо това кодиране на multipart/form-data, което има различен формат. По-сложно е, но обикновено не е нужно да се интересувате как изглежда, така че няма да покажа пример, но може да е полезно да знаете, че съществува.

Типът медия по подразбиране в POST заявка е application/x-www-form-urlencoded. Това е формат за кодиране на двойки ключ-стойност. Ключовете могат да бъдат дублирани. Всяка двойка ключ-стойност е разделена със знак &, а всеки ключ е отделен от своята стойност със знак =.

Например:

Име: Джон Смит Клас: 19

Написано като:

Име=Джон+Смит&Клас=19

Той се поставя в тялото на заявката след HTTP заглавките.

Въпросът се препрочита. Действително зададеният въпрос не е като префиксите на доставчика в свойствата на CSS, където има смисъл в бъдеще да проверявате и мислите за поддръжката на доставчика и официалните стандарти. Действително зададеният въпрос е по-близък до избора на имена на параметри на URL заявка. Никой не трябва да се интересува кои са. Но съвпадението на имената с обикновените е нещо напълно правилно, обичайно и правилно.

Обосновка:
Става въпрос за споразумения между разработчиците за персонализирани заглавки, специфични за приложението - « данни, свързани с техния акаунт- които нямат нищо общо с доставчици, стандартни органи или протоколи, които трябва да бъдат внедрени от трети страни, освен че въпросният разработчик просто трябва да избягва заглавки, които може да имат други цели за използване от сървъри, проксита или клиенти. Поради тази причина дадените примери за "X-Gzip/Gzip" и "X-Forwarded-For/Forwarded-For" са спорни. Това повдига въпроса за конвенциите в контекста на частен API, подобно на конвенциите за именуване на параметри на заявка на URL. Това е въпрос на предпочитание и разстояние между имената; притесненията относно "X-ClientDataFoo", поддържан от който и да е прокси или доставчик без "X", очевидно са неуместни.

Няма нищо специално или магическо в префикса "X-", но ви помага да разберете, че това е персонализирана заглавка. Всъщност RFC-6648 и други помагат да се предотврати използването на префикса "X-", защото - тъй като доставчиците на HTTP клиенти и сървъри изоставят префикса - вашите приложения, частни API, лични данни, механизъм за прехвърляне стават още по-добре изолирани от сблъсъци между имена и малък брой официални запазени заглавия. Моето лично предпочитание и препоръка обаче е да отидете една крачка напред и да направите например „X-ACME-ClientDataFoo“ (ако вашата компания за джаджи е „ACME“).

IMHO спецификацията на IETF не е достатъчно конкретна, за да отговори на въпроса на OP, тъй като не може да направи разлика между напълно различни случаи на употреба: (A) доставчици, внедряващи нови глобално приложими функции като „Forwarded-For“, от една страна, vs. (B) Разработчиците на приложения предават специфични за приложението низове на клиента и сървъра. Спектърът засяга само първия, (A). Въпросът тук е дали има споразумения за (Б). Яжте. Те включват групиране на параметри по азбучен ред и отделянето им от много съвместими със стандартите заглавки тип (A). Използването на префикс "X-" или "X-ACME-" е удобно и законно за (B) и не противоречи на (A). Тъй като повече търговци спрат да използват „X-“ за (A), (B) ще стане по-ясно.

Пример:
Google (който носи малко тежест в различни органи за стандартизация) - от днес, 20141102 в тази незначителна промяна на моя отговор - в момента използва "X-Mod-Pagespeed", за да посочи версията на неговия модул Apache, участващ в трансформирането на този отговор. Някой всъщност предлага ли Google да използва "Mod-Pagespeed" без "X-" и/или да поиска от IETF да благослови използването му?

Резюме:
Ако използвате персонализирани HTTP заглавки (като понякога подходяща алтернатива на бисквитките) във вашето приложение, за да предавате данни на вашия сървър и тези заглавки очевидно не са предназначени да се използват извън контекста на вашето приложение, съпоставете имена с префикс „X-“ или "X- FOO-" е разумно и общоприето.

Една HTTP заявка или съобщение се състои от три части: линията на заявката и тялото на HTTP съобщението.

Низ на заявка, или начален ред: в заявка към сървъра, ред, който съдържа типа заявка (метод), URI на исканата страница и версия (например HTTP/1.1). В отговора от сървъра този ред съдържа версията на HTTP протокола и кода на отговора. Кодът на отговора е трицифрено цяло число. Обикновено е последван от обяснителна фраза, разделена с интервал, която обяснява кода, например: 200 OK или 404 Not Found.

Методи за HTTP заявка (типове): GET, POST, PUT, PATCH, HEAD, DELETE, TRACE. Най-често методите GET или POST се използват в HTTP заявка: GET се използва за искане на съдържанието на уеб страница на посочения URI. URI е адресът на страницата без посочване, например: /internet/chto-takoe-http-zapros-soobshhenie/ вместо site/internet/chto-takoe-http-zapros-soobshhenie/. Браузърът може да предава параметри в GET в URI след "? ": GET /index.php?param1=value1¶m2=value2. В допълнение към обикновения GET метод има също условен GET и частичен GET. Условните GET заявки съдържат If-Modified-Since, If-Match, If-Range и подобни заглавки.

POST - използва се за изпращане на информация до . Когато изпращате данни чрез метода POST, те се посочват в тялото на HTTP съобщението, а не в реда за въвеждане на адреса в браузъра, както се прави при изпращане на данни чрез метода GET. Например, когато изпращате коментар чрез формата, разположена под статията, информацията се предава на сървъра чрез метода POST. Файловете също се качват на сървъра чрез метода POST.

- това е част от заявката, която съдържа различни параметри, които се използват за правилно изграждане на уеб страницата.

Тяло на HTTP съобщението— съдържа данни, получени от сървъра, например генерирана уеб страница под формата на HTML код или ресурс, например картина.

Примерни HTTP съобщения:

HTTP заявка към сървъра:

GET /internet/chto-takoe-http-zapros-soobshhenie/ HTTP/1..9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 ( KHTML, като Gecko) Chrome/40.0.2150.0 Accept-Encoding: gzip, deflate, sdch Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: wp- настройки-1=скриванеb%3D; wp-settings-time-1=1424958215; wordpress_test_cookie=WP+бисквитка;

Отговор от сървъра:

HTTP/1.1 200 OK - начален ред за отговор: Сървър: nginx/1.6.2 Дата: неделя, 19 април 2015 г. 00:22:50 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 9431 Връзка: keep-alive Keep-Alive: timeout=30 X-Powered-By: PHP/5.5.22 Изтича: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Следва тялото на отговора (html страница).