Методите за заявка чрез http протокол включват. Нека разгледаме HTTP методите по-подробно

Ако формулярът е изпратен по обичайния начин, тогава самият браузър кодира (urlencode) името и стойността на всяко поле с данни (вход и т.н.) и изпраща формуляра на сървъра в кодиран вид.

Вторият метод на кодиране е без кодиране. Например, не е необходимо кодиране за прехвърляне на файлове. Той е посочен във формуляра (само за POST) по следния начин:

В този случай нищо не се кодира при изпращане на данни към сървъра. И сървърът, от своя страна, гледайки „Content-Type: multipart/form-data“ ще разбере какво е пристигнало.

Кодиране на данни.

Ако използвате само UTF-8, нямате нужда от този раздел.

Всички GET/POST параметри, отиващи към сървъра, с изключение на случаите на multipart/form-data, са кодирани в UTF-8. Не в кодирането на страницата, а в UTF-8. Ето защо, например, в PHP те трябва да бъдат прекодирани с функцията iconv, ако е необходимо.

$name = iconv("UTF8","CP1251",$_GET["име"]);

Браузърът получава отговора от сървъра точно в кодирането, посочено в заглавката на отговора Content-Type. Тоест, отново в PHP, за да може браузърът да приеме отговора в windows-1251 и нормално да показва данните на страницата в windows-1251, трябва да изпратите заглавка, кодирана в PHP код, например така:

Header("Content-Type: text/plain; charset=windows-1251");

Или сървърът трябва да добави такъв хедър. Например в apache кодирането се добавя автоматично с опцията:

# в конфигурацията на Apache AddDefaultCharset windows-1251
.

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

Предимства

Простота

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

Разширяемост

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

Разпространение

При избора на HTTP протокол за решение специфични задачиВажен фактор е неговото разпространение. В резултат на това това е изобилие от различна документация за протокола на много езици по света, включване на лесни за използване инструменти за разработка в популярни IDE, поддръжка на протокола като клиент в много програми, и богат избор сред хостинг компании с HTTP сървъри.

Недостатъци и проблеми

Голям размер на съобщението

Използването на текстов формат в протокола създава съответен недостатък: големият размер на съобщенията в сравнение с прехвърлянето на двоични данни. Поради това се увеличава натоварването на оборудването при генериране, обработка и предаване на съобщения. За решаването на този проблем протоколът включва вградени средства за кеширане от страна на клиента, както и средства за компресиране на предаваното съдържание. Нормативни документиПротоколът предвижда наличието на прокси сървъри, които позволяват на клиента да получи документ от най-близкия до него сървър. Освен това в протокола беше въведено делта кодиране, така че не целият документ да се предава на клиента, а само неговата модифицирана част.

Липса на "навигация"

Въпреки че протоколът е проектиран като средство за работа със сървърни ресурси, той не предоставя изрично средство за навигация между тези ресурси. Например, клиентът не може изрично да поиска списък с налични файлове, както в . Предполагаше се, че крайният потребител вече познава хипервръзките. Това е съвсем нормално и удобно за хората, но е трудно, когато задачата е автоматично да се обработват и анализират всички сървърни ресурси без човешка намеса. Решението на този проблем лежи изцяло на плещите на разработчиците на приложения, използващи този протокол.

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

HTTP протоколът е разработен за решаване на типични ежедневни проблеми, при които самото време за обработка на заявката трябва да отнема малко време или изобщо да не се взема предвид. Но при индустриална употреба с разпределени изчисления и големи натоварвания на сървъра HTTP протоколът се оказва безпомощен. През 1998 г. W3C предложи алтернативен протокол HTTP-NG(Английски) HTTP следващо поколение), за да замени напълно остарелия с фокус върху тази област. Идеята за неговата необходимост беше подкрепена от големи специалисти в областта на разпределените изчисления, но този протокол все още е в етап на разработка.

Софтуер

всичко софтуерза работа с HTTP протокола е разделен на три големи категории:

• Сървърикато основни доставчици на услуги за съхранение и обработка на информация (обработка на заявки).
• клиенти- крайни потребители на сървърни услуги (изпращане на заявка).
• Проксиза извършване на транспортни услуги.

За да се разграничат крайните сървъри от проксита, официалната документация използва термина първоначален сървър(Английски) Първоначален сървър). Разбира се, един и същи софтуерен продукт може едновременно да изпълнява функциите на клиент, сървър или посредник, в зависимост от възложените задачи. Спецификациите на HTTP протокола описват подробно поведението за всяка от тези роли.

клиенти

HTTP протоколът първоначално е разработен за достъп до хипертекстови документи в World Wide Web. Следователно основните клиентски реализации са браузъри(потребителски агенти). Популярни браузъри(по азбучен ред): Chrome, Internet Explorer, Mozilla Firefox, Safari.

За да видите запазеното съдържание на сайтове на компютър без интернет връзка, те са измислени офлайн браузъри. Сред известните. Те ви позволяват да изтегляте определени файлове по всяко време след загуба на връзката с уеб сървъра. Популярни програми в Windows OS са Download Master, Free Мениджър на изтеглянията, ReGet. В KGet и d4x (Програма за изтегляне за X). Много потребители на Linux предпочитат да използват NASA World Wind, който също използва HTTP.

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

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

Origin сървъри

Основни реализации: Internet Information Services (IIS), nginx.

Прокси сървъри

Основни реализации: UserGate, Multiproxy, Naviscope, Списък на уеб сървъри

История на развитието

HTTP/0.9

HTTP/1.0

HTTP/1.1

Актуалната версия на протокола беше приета през юни. Новото в тази версия беше „ постоянна връзка»: Стартова линия) - определя вида на съобщението;

Заглавките и тялото на съобщението може да липсват, но началният ред е задължителен елемент, тъй като показва типа заявка/отговор. Изключение прави версия 0.9 на протокола, при която съобщението за заявка съдържа само началния ред, а съобщението за отговор съдържа само тялото на съобщението.

Стартова линия

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

ВЗЕМЕТЕ URI- за версия на протокола 0.9. Метод URI HTTP/ Версия- за други версии.

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

ВЗЕМЕТЕ /wiki/Http HTTP/1.0

Началният ред на отговора на сървъра има следния формат:

HTTP/ Версия Код на състоянието Обяснение

• Версия- двойка арабски цифри, разделени с точка, както е в заявката.
• Код на състоянието(Английски) Код на състоянието) - три арабски цифри. Кодът на състоянието определя по-нататъшното съдържание на съобщението и поведението на клиента.
• Обяснение(Английски) Фраза за причина) - кратко текстово обяснение на кода за отговор за потребителя. Не засяга съобщението по никакъв начин и не е задължително.

Например сървърът отговори на предишната ни заявка от клиента за тази страница с реда:

HTTP/1.0 200 Добре

Методи

НАСТРОИКИ

Използва се за определяне на възможностите на уеб сървъра или параметрите на връзката за конкретен ресурс. Сървърът ТРЯБВА да включва заглавка Allow в своя отговор със списък на поддържаните методи. Заглавките на отговорите може също да включват информация за поддържаните разширения.

Очаква се заявката на клиента да съдържа тяло на съобщението, за да посочи информацията, която го интересува. Форматът на тялото и процедурата за работа с него в момента не са определени. Сървърът трябва да го игнорира засега. Подобна е ситуацията и с тялото в отговора на сървъра.

За да разберете възможностите на целия сървър, клиентът трябва да посочи звездичка - “*” в URI. ОПЦИИ * HTTP/1.1 заявките могат също да се използват за проверка на изправността на сървъра (подобно на pinging) и за тестване дали сървърът поддържа HTTP версия 1.1.

Резултатът от този метод не се кешира.

ВЗЕМЕТЕ

Използва се за запитване до съдържанието на определен ресурс. Като се използва GET методможете също да стартирате процес. В този случай информацията за напредъка на процеса трябва да бъде включена в тялото на отговорното съобщение.

Клиентът може да предава параметри за изпълнение на заявка в URI на целевия ресурс след "? ":
GET /path/resource?param1=value1¶m2=value2 HTTP/1.1

Съгласно HTTP стандарта GET заявките се считат за идемпотентни - повтарянето на една и съща GET заявка многократно трябва да доведе до едни и същи резултати (при условие, че самият ресурс не се е променил във времето между заявките). Това позволява отговорите на GET заявките да бъдат кеширани.

В допълнение към обичайния метод GET има и разграничение. Условните GET заявки съдържат If-Modified-Since, If-Match, If-Range и подобни заглавки. Частичните GET съдържат диапазон в заявката. Процедурата за изпълнение на такива заявки се определя отделно от стандартите.

ГЛАВА

Подобно на метода GET, с изключение на това, че няма тяло в отговора на сървъра. Заявката HEAD обикновено се използва за извличане на метаданни, проверка за съществуването на ресурс (проверка на URL) и да се види дали той се е променил от последния достъп до него.

Заглавките на отговорите може да са кеширани. Ако метаданните на даден ресурс не съвпадат със съответната информация в кеша, копието на ресурса се маркира като остаряло.

ПУБЛИКУВАНЕ

Използва се за прехвърляне на потребителски данни към определен ресурс. Например в блоговете посетителите обикновено могат да въвеждат коментари за публикации в HTML формуляр, след което те се ПУБЛИКУВАТ на сървъра и се поставят на страницата. В този случай предадените данни (в примера с блогове, текстът на коментара) се включват в тялото на заявката. По същия начин файловете обикновено се качват чрез метода POST.

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

Ако резултатите от изпълнението са 200 (Добре) и 204 (Няма съдържание), съобщение за резултата от заявката трябва да бъде включено в тялото на отговора. Ако е създаден ресурс, сървърът ТРЯБВА да върне отговор 201 (Създаден) с URI на новия ресурс в заглавката Location.

Съобщението за отговор на сървъра към метода POST не се кешира.

СЛАГАМ

Използва се за зареждане на съдържанието на заявката към URI, посочен в заявката. Ако даден ресурс не съществува в дадения URI, сървърът го създава и връща статус 201 (Създаден). Ако ресурсът е променен, сървърът връща 200 (Добре) или 204 (Няма съдържание). Сървърът НЕ ТРЯБВА да игнорира невалидни заглавки Content-*, изпратени от клиента заедно със съобщението. Ако някое от тези заглавки не може да бъде разпознато или не е валидно при настоящите условия, тогава трябва да се върне код за грешка 501 (не е внедрено).

Основната разлика между методите POST и PUT е в разбирането на целите URI адреси на ресурси. Методът POST предполага, че посоченият URI ще обработи съдържанието, изпратено от клиента. Използвайки PUT, клиентът приема, че съдържанието, което се изтегля, съответства на ресурса, разположен на дадения URI.

Съобщенията за отговор на сървъра към метода PUT не се кешират.

КРЕПКА

Подобно на PUT, но се прилага само към фрагмент от ресурса.

ИЗТРИЙ

Изтрива посочения ресурс.

СЛЕДИ

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

СВЪРЗВАНЕ

За използване с прокси сървъри, които могат динамично да превключват към тунелен режим

ВРЪЗКА

Установява връзка между посочения ресурс и други.

ПРЕКРАТЯВАНЕ НА ВРЪЗКАТА

Премахва връзката на посочения ресурс с други.

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

Кодът на състоянието е част от първия ред на отговора на сървъра. Представлява цяло число от 3 арабски цифри. Първата цифра показва държавна класа. Кодът на отговора обикновено е последван от обяснителна фраза, разделена с интервал. английски език, което посочва причината за този конкретен отговор.

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

В момента има пет класа кодове за състояние.

1xx Информационен (руски) Информационен) Този клас съдържа кодове, които информират за процеса на прехвърляне. В HTTP/1.0 съобщенията с такива кодове трябва да се игнорират. В HTTP/1.1 клиентът трябва да е готов да приеме този клас съобщения като нормален отговор, но не е необходимо да изпраща нищо до сървъра. Самите съобщения от сървъра съдържат само началния ред на отговора и, ако е необходимо, няколко заглавни полета, специфични за отговора. Прокси сървърите трябва да изпращат такива съобщения по-нататък от сървъра към клиента. 2xx успех (руски) Успешно) Съобщения от този класинформира за случаи на успешно приемане и обработка на заявка на клиент. В зависимост от състоянието, сървърът може също да предаде заглавките и тялото на съобщението. 3xx пренасочване (руски) Пренасочване ) Кодовете за състояние от клас 3xx казват на клиента, че следващата заявка трябва да бъде направена към различен URI, за да успее операцията. В повечето случаи нов адреспосочено в полето Местоположение на заглавката. В този случай клиентът трябва, като правило, да направи автоматичен преход (jarl. пренасочване). Моля, имайте предвид, че при достъп до следващия ресурс можете да получите отговор от същия клас кодове. Възможно е дори да има дълга верига от пренасочвания, които, ако се извършват автоматично, биха създали прекомерно натоварване на оборудването. Затова разработчиците на HTTP протокола настоятелно препоръчват след втория пореден отговор да поискате потвърждение за пренасочване от потребителя (преди това се препоръчваше след 5-ия). Клиентът е отговорен за наблюдението на това, т.к текущия сървърможе да пренасочи клиента към ресурс на друг сървър. Клиентът трябва също да предотврати навлизането в кръгови пренасочвания. 4xx клиентска грешка (руски) Клиентска грешка) Кодовият клас 4xx е предназначен да показва грешки от страна на клиента. Когато се използват всички методи с изключение на HEAD, сървърът трябва да върне хипертекстово обяснение на потребителя в тялото на съобщението. За да запомните стойностите на кодовете от 400 до 417, има методи за илюстративна мнемоника 5xx Server Error (руски. грешка в сървъра) Кодове 5xx се разпределят за случаи на неуспешна операция по вина на сървъра. За всички ситуации, различни от използването на метода HEAD, сървърът трябва да включи в тялото на съобщението обяснение, което клиентът ще покаже на потребителя.

Заглавия

Основен текст на съобщението

Примери за HTTP диалог

Редовна GET заявка

Заявка на клиента:

ВЗЕМЕТЕ /wiki/ страница HTTP/1.1 Хост: ru.wikipedia.org Потребителски агент: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Приемане: текст/html Връзка: затваряне

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

HTTP/1.0 200 OK Дата: сряда, 11 февруари 2009 г. 11:20:59 GMT Сървър: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Последна промяна: сряда, 11 февруари 2009 г. 11:20:59 GMT Съдържание -Език: ru Тип на съдържанието: text/html; charset=utf-8 Дължина на съдържанието: 1234 Връзка: затваряне (следното е исканата страница в

Пренасочвания

Да кажем, че фиктивната компания Example Corp. има основен сайт на http://example.com и домейн с псевдоним example-corp.com. Клиентът изпраща заявка за страницата About към вторичния домейн (някои от заглавките са пропуснати):

Можете да посочите фрагменти в заглавката Location, както в този пример. Браузърът не е включил фрагмента в заявката, защото се интересува от целия документ. Но автоматично ще превърти страницата до фрагмента „контакти“ веднага щом я зареди. В тялото на отговора е поставен и кратък HTML документ с връзка, с помощта на която посетителят ще бъде отведен до целева страница, ако браузърът не превключи автоматично към него. Заглавката Content-Type съдържа характеристиките на това конкретно HTML обяснение, а не на документа, който се намира на целевия URL адрес.

Да кажем, че същата тази компания Example Corp. има няколко регионални офиса по целия свят. И за всяко представителство имат уебсайт със съответния ccTLD. Заявка за главната страница на основния сайт example.com може да изглежда така:

Сървърът взе под внимание заглавката Accept-Language и генерира отговор с временно пренасочване към руския сървър example.ru, като посочи неговия адрес в заглавката Location:

HTTP/1.x 302 Намерен Местоположение: http://www.example.ru/ Cache-Control: private Дата: Thu, 19 Feb 2009 11:08:01 GMT Сървър: Apache/2.2.6 Content-Type: text/html; charset=windows-1251 Дължина на съдържанието: 82 (празен ред) Пример Корп. Русия

Обърнете внимание на заглавката Cache-Control. Стойността "private" казва на други сървъри (предимно проксита), че отговорът може да бъде кеширан от страна на клиента. В противен случай е възможно следващите посетители от други държави винаги да отиват в различно представителство.

За пренасочване също се използват кодове за отговор (Вижте Други) и (Временно пренасочване).

Възобновяване и фрагментарно изтегляне

Да приемем, че фиктивна организация предлага да изтегли видеозапис от минала конференция от уебсайта на http://example.org/conf-2009.avi с обем приблизително 160 MB. Нека да разгледаме как се изтегля този файл в случай на повреда и как мениджърът за изтегляне ще организира многопоточно изтегляне на няколко фрагмента.

И в двата случая клиентите ще направят първата си заявка по следния начин:

GET /conf-2009.avi HTTP/1.0 Хост: example.org Accept: */* User-Agent: Mozilla/4.0 (съвместим; MSIE 5.0; Windows 98) Referer: http://example.org/

Заглавката Referer показва, че файлът е поискан от началната страница на сайта. Мениджърите за изтегляне обикновено също го посочват, за да емулират преход от страница на уебсайт. Без него сървърът може да отговори (Достъпът е забранен), ако заявките от други сайтове не са разрешени. В нашия случай сървърът върна успешен отговор:

HTTP/1.1 200 OK Дата: четвъртък, 19 февруари 2009 г. 12:27:04 GMT Сървър: Apache/2.2.3 Последна промяна: сряда, 18 юни 2003 г. 16:05:58 GMT ETag: "56d-9989200-1132c580" Съдържание -Тип: video/x-msvideo Съдържание-дължина: 160993792 Приемане на диапазони: байтовеВръзка: затворена (празен ред) (двоично съдържание на целия файл)

Заглавието Accept-Ranges информира клиента, че може да изисква фрагменти от сървъра, като посочва техните отмествания от началото на файла в байтове. Ако този хедър липсва, клиентът може да предупреди потребителя, че най-вероятно няма да е възможно да изтегли файла. Въз основа на стойността на заглавката Content-Length, мениджърът за изтегляне ще раздели целия обем на равни фрагменти и ще ги поиска отделно, организирайки няколко нишки. Ако сървърът не посочи размера, тогава клиентът няма да може да реализира паралелно изтегляне, но в същото време той ще може да продължи да изтегля файла, докато сървърът отговори (Requested Range Not Satisfiable).

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

GET /conf-2009.avi HTTP/1.0 Host: example.org Accept: */* User-Agent: Mozilla/4.0 (съвместим; MSIE 5.0; Windows 98) Обхват: байтове=88080384-Референт: http://example.org/

От сървъра не се изисква да помни какви и от кого са били предишните заявки и затова клиентът вмъкна отново заглавката на Referer, сякаш това беше първата му заявка. Посочената стойност на заглавката на Range казва на сървъра „да даде съдържанието от 88080384-ия байт до самия край“. В тази връзка сървърът ще върне следния отговор:

HTTP/1.1 206 Частично съдържаниеДата: четвъртък, 19 февруари 2009 г. 12:27:08 GMT Сървър: Apache/2.2.3 Последна промяна: сряда, 18 юни 2003 г. 16:05:58 GMT ETag: "56d-9989200-1132c580" Приемане на диапазони: байтове Обхват на съдържанието: байтове 88080384-160993791/160993792 Съдържание-дължина: 72913408Връзка: затворете Content-Type: video/x-msvideo (празен ред) (двоично съдържание от 84 мегабайта)

Заглавката Accept-Ranges вече не се изисква тук, тъй като клиентът вече знае за тази възможност на сървъра. Клиентът научава, че фрагмент се предава от кода (частично съдържание). Заглавката Content-Range съдържа информация за този фрагмент: номерата на началния и крайния байт, а след наклонената черта - общия размер на целия файл в байтове. Обърнете внимание на заглавката Content-Length - тя показва размера на тялото на съобщението, тоест предадения фрагмент. Ако сървърът върне няколко фрагмента, тогава Content-Length ще съдържа общия им обем.

Сега да се върнем към мениджъра за изтегляне. Знаейки общия размер на файла „conf-2009.avi“, програмата го раздели на 10 равни секции. Мениджърът ще зареди първоначалната при първата заявка, прекъсвайки връзката веднага щом достигне началото на втората. Другото ще поиска отделно. Например, 4-ти раздел ще бъде поискан със следните заглавки (някои от заглавките са пропуснати - вж. пълен примерпо-висок):

ВЗЕМЕТЕ /conf-2009.avi HTTP/1.0 Обхват: байтове=64397516-80496894

Отговорът на сървъра в този случай ще бъде както следва (някои от заглавките са пропуснати - вижте пълния пример по-горе):

HTTP/1.1 206 Частично съдържание Приемане на диапазони: байтове Обхват на съдържанието: байтове 64397516-80496894/160993792 Съдържание-дължина: 16099379 (празен ред) (двоично съдържание на част 4)

Ако такава заявка бъде изпратена до сървър, който не поддържа фрагменти, тя ще върне стандартен отговор (OK), както е показано в самото начало, но без заглавката Accept-Ranges.

Основни протоколни механизми

Частични GETs

HTTP ви позволява да поискате не цялото съдържание на ресурс наведнъж, а само определен фрагмент. Такива заявки се наричат частични GETs, възможността за тяхното изпълнение е незадължителна (но желателна) за сървърите. Частичните GET се използват главно за възобновяване на файлове и бързи паралелни изтегляния в множество нишки. Някои програми изтеглят заглавката на архива, показват вътрешната структура на потребителя и след това изискват фрагменти с посочените архивни елементи.

За да получи фрагмент, клиентът изпраща заявка до сървъра със заглавка Range, като в нея посочва необходимите диапазони от байтове. Ако сървърът не разбира частични заявки (игнорира заглавката Range), тогава той ще върне цялото съдържание със статус, както при обикновен GET. При успех сървърът връща отговор със състояние 206 (Частично съдържание) вместо код 200, включително заглавката Content-Range в отговора. Самите фрагменти могат да се предават по два начина:

Условно GET

Договаряне на съдържанието

Договаряне на съдържанието(Английски) Договаряне на съдържанието) - механизъм автоматично откриваненеобходим ресурс, когато има няколко различни типа версии на документи. Субектите на координация могат да бъдат не само сървърни ресурси, но и върнати страници със съобщения за грешка (и т.н.).

Има два основни вида одобрения:

• Управляван от сървър(Английски) Управляван от сървър).
• Водени от клиента(Английски) Управляван от агент).

И двата вида или всеки поотделно могат да се използват едновременно.

Основната спецификация на протокола (RFC 2616) също подчертава т.нар прозрачно одобрение(Английски) Прозрачни преговори) Как предпочитан варианткомбинации от двата вида. Последният механизъм не трябва да се бърка с независима технология Преговори за прозрачно съдържание (TCN, Руски Прозрачно договаряне на съдържанието , вижте RFC 2295), който не е част от HTTP протокола, но може да се използва с него. И двете имат значителни разлики в принципа на работа и самото значение на думата „прозрачен“ ( прозрачен). В HTTP спецификацията прозрачността означава, че процесът е невидим за клиента и сървъра, а в технологията TCN прозрачността означава достъпност пълен списъквъзможности за ресурси за всички участници в процеса на доставка на данни.

Управляван от сървър

Ако има множество версии на даден ресурс, сървърът може да анализира заглавките на заявката на клиента, за да произведе това, което смята, че е най-подходящата версия. Основните анализирани заглавки са Accept, Accept-Charset, Accept-Encoding, Accept-Languages ​​​​и User-Agent. Препоръчително е сървърът да включи заглавка Vary в отговора, указваща параметрите, по които съдържанието на искания URI се различава.

Географското местоположение на клиента може да се определи от отдалечения IP адрес.

Преговорите, управлявани от сървър, имат няколко недостатъка:

• Сървърът само предполага коя опция е най-предпочитана за краен потребител, но не може да знае какво точно е необходимо в момента (например версия на руски или английски).
• Изпратени са много заглавки на група за приемане, но малко ресурси с множество опции. Поради това оборудването изпитва прекомерно натоварване.
• Споделеният кеш е ограничен в способността си да произвежда един и същ отговор на идентични заявки от различни потребители.
• Предаването на Accept заглавки също компрометира поверителността на потребителя, като разкрива известна информация за предпочитанията на потребителя.

Водени от клиента

IN в такъв случайтипът съдържание се определя само от страна на клиента. За да направи това, сървърът връща със статус код 300 (Множество избори) или 406 (Неприемливо) списък с опции, от които потребителят избира подходящата. Съгласуването, ръководено от клиента, е добро, когато съдържанието варира значително общи параметри(например по език и кодиране) и се използва публичен кеш. Основен недостатък: допълнително натоварване, тъй като трябва да направите допълнителна заявка, за да получите желаното съдържание.

Прозрачно одобрение

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

Основната HTTP спецификация не описва в детайли прозрачния механизъм за договаряне.

Множество съдържание

Основна статия: йерархии с влагане на елементи един в друг. Типовете медии multipart/* се използват за обозначаване на множество съдържание. Работата с такива типове се извършва съгласно общите правила, описани в RFC 2046 (освен ако не е определено друго от конкретен тип медия). Ако получателят не знае как да се справи с типа, тогава той го третира по същия начин като multipart/mixed.

От страната на сървъра в отговор могат да се изпращат съобщения с множество съдържания при заявка на множество фрагменти от ресурси. В този случай се използва медийният тип multipart/byteranges.

Стандартен протокол за предаване на данни през World Wide Web-- това е HTTP (протокол за прехвърляне на хипертекст). Той описва съобщения, които могат да се обменят между клиенти и сървъри. Всяко взаимодействие се състои от единична ASCII заявка, последвана от единичен отговор, подобно на стандартния отговор на RFC 822 MIME. Всички клиенти и всички сървъри трябва да следват този протокол. Дефиниран е в RFC 2616.

Връзки

Обичайният начин браузърът да комуникира със сървъра е да установи TCP връзка към порт 80 на сървъра, въпреки че тази процедура не е формално задължителна. Стойността на използването на TCP е, че нито браузърите, нито сървърите трябва да се тревожат за загубени, дублирани или прекалено дълги съобщения и потвърждения. Всичко това се осигурява от TCP протокола.

В HTTP 1.0 след установяване на връзка се изпраща една заявка, на която се получава един отговор. След това TCP връзката беше прекратена. По това време типичната уеб страница се състоеше изцяло от HTML текст и този начин на взаимодействие беше адекватен. Въпреки това минаха няколко години и страницата съдържаше много икони, изображения и други декорации. Очевидно настройването на TCP връзка за предаване на една икона е разточително и твърде скъпо.

Това съображение доведе до създаването на протокола HTTP 1.1, който поддържа стабилни връзки. Това означаваше, че е възможно да се установи TCP връзка, да се изпрати заявка, да се получи отговор и след това да се предава и получава допълнителни исканияи отговори. По този начин режийните разходи, направени по време на постоянни инсталациии прекъсване на връзката. Също така стана възможно конвейерните заявки, т.е. изпращането на заявка 2 дори преди да пристигне отговорът на заявка 1.

Въпреки че HTTP е проектиран специално за използване в уеб технологиите, той умишлено е направен по-общ от необходимото, тъй като е предназначен за бъдеща употреба в обектно-ориентирани приложения. Поради тази причина, в допълнение към обикновените заявки към уеб страници, са разработени специални операции, наречени методи. Те дължат съществуването си на технологията SOAP. Всяка заявка се състои от един или повече ASCII низове, като първата дума е името на метода, който трябва да бъде извикан. Вградените методи са изброени в таблицата на фиг. 6. В допълнение към тези общи методи, различните обекти могат също да имат свои собствени специфични методи. Имената на методите са чувствителни към главни и малки букви, което означава, че методът GET съществува, но методът get не съществува.

Фигура 6 - Вградени методи за HTTP заявка

Методът GET изисква от сървъра страница (която по принцип е обект, но на практика обикновено е просто файл), кодирана според стандарта MIME. По-голямата част от заявките към сървъра са GET заявки.

Методът HEAD просто изисква заглавката на съобщението, без самата страница. Използвайки този метод, можете да разберете кога страницата е била последно модифицирана, за да съберете информация за индекса или просто да проверите функционалността на даден URL адрес.

Методът PUT е обратното на метода GET: той не чете, а записва страницата. Този метод ви позволява да създадете набор от уеб страници на отдалечен сървър. Тялото на заявката съдържа страницата. Може да е MIME кодиран. В този случай редовете след командата PUT могат да включват различни заглавки, като Content-Type или заглавки за удостоверяване, потвърждаващи правата на абоната върху исканата операция.

Методът POST е донякъде подобен на метода PUT. Той също така съдържа URL, но вместо да замени съществуващи данни, нови данни се „добавят“ (в даден момент в общ смисъл) към съществуващите. Това може да е публикуване на съобщение в конференция или добавяне на файл към електронно табло BBS реклами. На практика нито PUT, нито POST се използват широко.

Методът DELETE, не е изненадващо, изтрива страницата. Както при метода PUT, удостоверяването и разрешението за извършване на тази операция могат да играят специална роля тук. Дори ако потребителят има разрешение да изтрие страницата, няма гаранция, че методът DELETE ще изтрие страницата, защото дори ако отдалеченият HTTP сървър се съгласи, самият файл може да не бъде модифициран или преместен.

Методът TRACE е предназначен за отстраняване на грешки. Той казва на сървъра да изпрати обратно заявката. Този метод е особено полезен, когато заявките не се обработват правилно и клиентът иска да знае какъв вид заявка всъщност получава сървърът.

Методът CONNECT в момента не се използва. Запазено е за бъдеща употреба.

Методът OPTIONS позволява на клиента да попита сървъра за неговите свойства или за свойствата на конкретен файл.

В отговор на всяка заявка се получава отговор от сървъра, съдържащ статусен ред, както и евентуално допълнителна информация (например уеб страницата или част от нея). Редът за състояние може да съдържа трицифрен код за състояние, показващ дали заявката е била успешна или защо е неуспешна. Първата категория има за цел да раздели всички отговори на пет основни групи, както е показано в таблицата на фиг. 7. Кодове, започващи с 1 Aхх) рядко се използват в практиката. Кодовете, започващи с 2, означават, че заявката е обработена успешно и данните (ако са поискани) са изпратени. Кодовете 3xx казват на клиента да опита късмета си другаде - или използвайки различен URL адрес, или собствен кеш.

Фигура 7 - Групи от кодове за състояние, съдържащи се в отговорите на сървъра

Кодовете, започващи с 4, означават, че заявката е неуспешна по някаква причина, свързана с клиента: например е заявена несъществуваща страница или самата заявка е неправилна. И накрая, кодовете 5xx показват грешки на сървъра, дължащи се на програмна грешка или временно претоварване.

Пример за използване на HTTP

Тъй като HTTP е текстов протокол, взаимодействието със сървъра чрез терминал (който в този случай действа като противоположност на браузър) може да се организира доста просто. Просто трябва да установите TCP връзка към порт 80 на сървъра. Читателят е оставен да види сам как работи този скрипт (за предпочитане е да се изпълнява на UNIX система, тъй като някои други системи може да не показват състоянието на връзката). И така, последователността от команди е:

Фигура 8 - последователност от команди на HTTP протокол

Тази последователност от команди установява telnet връзка (т.е. TCP връзка) към порт 80 на уеб сървъра на IETF, намиращ се на www.ietf.org.

Резултатът от комуникационната сесия се записва в лог файл, който след това може да бъде прегледан. Следва командата GET. Посочва се името на искания файл и протоколът за предаване. Следва необходимият ред със заглавката Host. Празният ред, който го следва, също е задължителен. Той сигнализира на сървъра, че заглавките на заявката са изчерпани. Командата за затваряне (това е програма на telnet) затваря връзката.

Регистрационният файл на връзката, log, може да се види с помощта на всеки текстов редактор. Трябва да започне приблизително както е показано в списъка на Фигура 8, освен ако през това време не е имало промени на уебсайта на IETF.

Фигура 9 - Начало на изхода на файла “www.ietf.org/rfc.html”

Първите три реда в този списък са генерирани от програмата telnet, а не от отдалечения сайт. Но редът, започващ с HTTP/1.1, вече е IETF отговор, което показва, че сървърът иска да комуникира с вас, използвайки протокола HTTP/1.1. Това е последвано от поредица от заглавки и накрая съдържанието на самия заявен файл. ETag заглавка, която е уникален идентификаторстраници, свързани с кеширане и X-Pad -- нестандартен хедър, което помага за справяне с грешки в браузъра.

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 заявкасъдържа актуализирани данни.

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

Тези методи са най-популярните и най-често използвани различни инструментии рамки. В някои случаи ПЪТ и ИЗТРИВАНЕ на заявкиизпратено чрез изпращане на 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.

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

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

General-header = Cache-Control | Връзка | Дата | Прагма | Трейлър | Трансфер-кодиране | Надграждане | Чрез | Внимание

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

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

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

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

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

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

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

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

Заглавка на обект = Разрешаване | Кодиране на съдържание | Съдържание-Език | Дължина на съдържанието | Съдържание-Местоположение | Съдържание-MD5 | Обхват на съдържание | Тип съдържание | Изтича | Последно модифициран

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

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

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

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

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

Ред за заявка = Метод SP URI SP HTTP-версия CRLF Метод = "ОПЦИИ" | "ГЛАВА" | "ВЗЕМЕТЕ" | "ПОСТ" | "ПОСТАВЕТЕ" | "ИЗТРИВАНЕ" | "ТРЕЙС"

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-Charset | Accept-Encoding | Приемане на език | Упълномощаване | Очаквайте | От | Домакин | Ако съвпадение | If-Modified-Since | Ако-няма съвпадение | Ако диапазон | If-Unmodified-Since | Макс-напред | Прокси-упълномощаване | Обхват | Референт | TE | Потребителски агент

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

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

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

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

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

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

HTTP/1.1 200 OK

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

Response-header = Приемане-диапазони | Възраст | ETag | Местоположение | Прокси-удостоверяване | Повторен опит-след | Сървър | Променете | WWW-удостоверяване

• Възраст е времето в секунди, когато съобщението е създадено на сървъра.
• 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 протокола. Втората част ще съдържа още повече интересни факти и примери.