Протоколот за пренос на хипертекст (англиски: Hypertext Transfer Protocol, скр. HTTP) е мрежен протокол. HTTP е основа за комуникација на World Wide Web. Создаден е како средство за објавување на HTML страници. Развивањето на стандардот е координирано од (IETF) Internet Engineering Task Force и World Wide Web Consortium.

За HTTP

HTTP е протокол за комуникација помеѓу опслужувачот и клиентот, кој функционира на принцип барање-одговор. HTTP клиентот, кој обично е прелистувач, иницира пренос на податоци по создавањето на TCP / IP врска со оддалечен опслужувач на одредена порта. Клиентот го поднесува HTTP барањето на опслужувачот. Опслужувачот кој содржи податоци, обезбедува ресурси, како што се HTML податотеки, или врши други работи во име на клиентот, и на крај враќа одговор порака на клиентот. А одговор на проектот содржи информации за статусот на барањето и може да содржи барања за клиентот.

Историја

HTTP бил измислен од страна на Тим Бернерс-Ли со адреси и HTML за да се создаде World Wide Web. Во тоа време, File Transfer Protocol (FTP) е веќе достапен за пренос на податотеки, но тој не можеше да поднесе поимот на формат на податоци како воведен од страна на повеќенаменското Интернет пошта Екстензии (мимика). Првата верзија на HTTP беше многу основни, но веќе обезбедија поддршка за MIME заглавја да се опише на податоци пренесени. Оваа прва верзија е сè уште се користи делумно во 2007 година, познат под името HTTP/0.9.

Во мај 1996 година, HTTP/1.0 на крајот стана стандард во IETF и е опишана во RFC 1945. Оваа верзија на HTTP поддржува виртуелни опслужувачи, кеш за управување и за идентификација.

Во јануари 1997 година, HTTP/1.1 е опишана во RFC 2068 ИЕТФ, RFC 2616 и во јуни 1999 година. Оваа верзија носи поддршка за pipelined трансфер и преговори за типот на содржина (формат на податоци, јазикот).

Од клиентот до опслужувачот

Врската помеѓу клиентот и опслужувачот не е секогаш лесна, може да има машини кои користат средно реле:

А прокси (посредник или) да ги менувате реакции и барања кои ги добива и да управува со кеш на ресурси побара.
А портал (или портал) е средство за измена на протокол се користи.
А тунел пренесува нивните барања и одговори без никакви измени, или кеширање.

Метод

Страна на HTTP протоколот, методот е команда да одредува видот на барањето, односно да се каже, го прашува опслужувачот да се изврши некоја акција. Во општата акција се однесува на ресурс идентификувани од страна на URL-то што следи името на методот.

GET

Ова е најчестиот метод за барање ресурс. А ДОБИВАТЕ барање нема ефект на ресурси, би требало да биде можно да се повтори на барање без ефект.

HEAD

Овој метод бара само информација за ресурс, без да се бара ресурсот себе.

POST

Овој метод треба да се користи за додавање на нов извор (порака на форум или напис во едно мрежно место). На адреса се испорачува на адреса на ресурси во врска со новиот ресурс (како што се адреса на форум или мрежно место) и не ја отворам податотеката на новосоздадената ресурс.

ОПЦИИ

    Овој метод овозможува комуникација опции за ресурс или опслужувачот воопшто.

CONNECT

Овој метод овозможува да се користи прокси како комуникациска тунел.

Трага

Овој метод бара од опслужувач за да се врати она што го добил со цел да ги тестираат и вршење дијагностика на врската.

=Ставете

Овој метод може да ја замени или да додадете ресурси на опслужувачот. На адреса дадена е дека на ресурс.

DELETE

Овој метод го отстранува ресурс од опслужувачот.

Овие последниве две методи обично бараат привилигиран пристап.

Некои опслужувачи овозможи алтернативни методи на управување со ресурсите на опслужувачот (на пр претпоставка).

Идентификација

HTTP овозможува идентификација на посетителот со испраќање име и лозинка. Има два модови: Основни и билтени (RFC 2617). Првиот метод го испраќа лозинка во текстот јасно, и затоа треба да се користи со HTTPS. Вториот начин ви дозволува идентификација без пренесување на лозинка во јасно. За идентификација е, сепак, често се изведуваат од страна на некоја апликација слој над HTTP.

Верзии

HTTP 0.9

На почетокот на World Wide Web, што беше планирано да додадете капацитет за содржината на HTTP преговори, цртање посебно на пантомима. Во меѓувреме, на HTTP 0.9 е крајно едноставно.

1. HTTP клиент врска 2. Испраќање на GET методот барање 3. HTTP опслужувач одговор 4. опслужувачот затвора врската да го сигнализира крајот на одговор.

Пребарување:

ГЕТ / станица.html

GET методата е можно само една. опслужувачот признава дека се занимаваат со HTTP 0.9 верзија е дека не е одреден по URI.

Одговор:

<html> <head> <title> Пример </ title> </ head> <body> Ако ја изберете оваа е пример страница.

</ Body> </ html> Како одговор на HTTP 0.9, опслужувачот испраќа содржини директно на одговорот, без метаподатоци. Никогаш не треба да се однесуваат добро за HTTP барањата од повисоко.

Не барај верзии пред 0,9 на HTTP: тие не постојат, бидејќи за HTTP 0.9 беше првично не бројот на верзијата. Го зеде наградата кога HTTP 1.0 е надвор.

HTTP 1.0

HTTP 1.0, опишан во RFC 1945 година, предвидува користење на заглавија инспириран од MIME. Врската на управување е идентична со HTTP 0.9: клиентот се поврзува, испраќа барање, опслужувачот одговара и ја затвора врска веднаш.

HTTP барање има следниот формат: Командната линија (команда, URL, протокол верзија)

     Заглавието барање
     [празна линија]
     Барам тело

HTTP одговорите имаат следниот формат:

Статус линија (верзија, код-Reply-текст одговор) Како одговор на ова заглавје [празна линија] Одговор тело Пребарување:

ГЕТ / станица.html HTTP/1.0 Домаќин: example.com Referer: http://example.com/ Корисникот Агент: CERN-LineMode/2.15 libwww/2.17b3

Верзијата на HTTP е одреден по URI. Во пријавата мора да се заврши со двојна линија (CRLFCRLF). HTTP 1.0 исто така поддржува и POST методи и главата. Таму е употребата на заглавјата инспириран од MIME за пренос на податоците:

Домаќинот Одредува веб засегнати од прашањето, која е неопходна за опслужувачко вдомување на повеќе мрежни места на истата IP-адреса (името врз основа виртуелен домаќин, виртуелен хост име врз основа). Тоа е само насловот навистина важно. Referer Специфицира адреса на документот што го даде линк до бараниот ресурс. Овој наслов му овозможува на администратори да се види таму каде што посетителите доаѓаат од. Корисникот Агент Укажува на софтверот што се користи за да се поврзиш. Тоа е обично прелистувач или роботот.

Одговор: HTTP/1.0 200 OK Датум: Fri, 31 ДЕКЕМВРИ 1999 23:59:59 GMT опслужувач: Apache/0.8.4 Content-Type: text / html Content-Должина: 59 Истекува на: чет, 1 јануари 2000 00:59:59 GMT Последен-промена: пет, 9 август 1996 година 02:21:40 GMT

<title> Пример </ title> Ако ја изберете оваа е пример страница.

Во првиот ред се поставува статус HTTP код (200 во овој случај).

Датум Времето во кое е генерирана порака. опслужувач Укажува на кој модел на HTTP опслужувач на одговори на барањето. Должина содржина Ја одредува големината во бајти на ресурс. Content-Type Укажува на MIME типот на ресурс. Истекува Го одредува времето после кое ресурси треба да се смета застарени овозможува прелистувачи за да се утврди колку долго да се задржи ресурс кеш. Последен Изменето Покажува последната модификација денот на бараниот ресурс.

HTTP 1.1

HTTP 1.1 е опишан од RFC 2616 кој го прави застарени RFC 2068. Разликата со HTTP 1.0 е подобро управување со кеш. Домаќинот на заглавието е задолжително во кверија.

Главните преокупации на првите две верзии на HTTP се прво на голем број на врски при вчитување на комплексни страница (кои содржат илјадници слики или анимации) и второ, на отворањето на време врска помеѓу клиентот и опслужувачот (воспоставување на TCP врска е време трипати повеќе од латенција помеѓу клиентот и опслужувачот). Експериментите на постојаните врски, сепак, беа извршени со HTTP 1.0 (вклучувајќи го и користењето на насловот Врската: Чувајте-Alive), но ова е завршена со HTTP 1.1. По default, HTTP 1,1 користи упорни врски, т.е. врската не е затворен веднаш по барањето, но уште е на располагање за нов пребарување. Ова е често нарекуван задржи-жив функционалност. Тоа исто така е дозволен на клиентот да испрати повеќе HTTP барања на истата врска без да се чека за одговор. Оваа функција се нарекува групирање. Постојани поврзувања овозможува побрзо вчитување на страниците со повеќе ресурси, со истовремено намалување на мрежата на товарот.

На управувањето со упорни врска се постапува од страна на поврзување насловот.

HTTP 1.1 поддржува содржина преговори. На HTTP 1.1 клиентот може да го придружуваат барањето за ресурс насловот укажува кои јазици и форматите за податоци најпосакувана. Овие заглавија, чии имиња почнуваат со-Прифати.

Дополнителни хедери се поддржани од страна на HTTP 1.1: Врска Овој наслов може да бидат испратени од страна на клиентот или опслужувачот и содржи список на имиња за одредување на опциите за користење со сегашната врска. Ако има опција параметри овие се специфицирани од страна на заглавието на истото име како опција (Не-Alive на пример, да одредите максималниот број на барања за врска). Кликнете на името е резервиран да се каже дека врската треба да биде затворена по обработката на тековната барање. Прифати Овој наслов листи на MIME типови на содржини прифатена од страна на клиентите. Ѕвездата карактер * може да се користи за одредување на сите видови / поттипови. Прифати-Множзнаци Одредува карактерот енкодирања прифатени. Прифати-јазик Одредува јазици прифатени.

Редоследот на приоритетот за секоја опција (тип, кодирање или јазик) е определен од додате параметар q содржат децимална вредност помеѓу 0 (неприфатливо) и 1 (прифатливо) вклучени (3 цифри по запирката), еднаква на 1 стандардно .

Поддршка за постојаните врски, исто така, треба да работат во случаите каде што од големината на ресурси не е однапред познат (динамички генерирани од страна на ресурси на опслужувачот, надворешна текови на опслужувачот, ...).

За ова, назначен chunked трансфер кодирање се користи за пренос на ресурси piecewise последователни пред секоја линија од текст со давање на големината на тоа во хексадецимални. Преносот завршува кога парче од нула големина, каде што последната заглавја може да биде испратена.

Дополнителни хедери во врска со овој трансфер кодирање се: Трансфер-Encoding Одредува трансфер кодирање. Единствената вредност, дефинирана од RFC 2616 е chunked.

Трејлер Список на сите заглавија се појавува после последната трошка префрлени. ТЕ Испратени од страна на клиентот да ја наведе содржината кодирање поддржана (Content-Encoding не е исто како трансфер-Кодирање chunked е нужно поддржан од страна на клиентите и опслужувачите за спроведување на HTTP/1.1 стандард), и одредува дали клиентот поддржува во Заглавието Кориснички шлепери со додавање на листата.

HTTPS

HTTPS (обезбедени со "С", или "безбедна ") е едноставен Комбинацијата на HTTP со слој на енкрипција како SSL или TLS.

Тоа им овозможува на посетителите да се потврди идентитетот на мрежното место кое се пристапува преку сертификат за автентикација. Тоа го гарантира доверливост и интегритет на податоците доставена од страна на корисникот (вклучувајќи информации внесени во форми) и се добива од опслужувачот.

Тоа е генерално се користи за онлајн финансиски трансакции: електронската трговија, интернет банкарство, брокерски онлајн, итн. Тоа е исто така се користи за пребарување на приватни податоци, како што се пораки, на пример.

По default, HTTPS опслужувачите се поврзани со TCP порта 443.

HTTPS и пиратеријата

Безбедноста на информациите пренесени преку HTTPS се заснова на употреба на алгоритам за шифрирање и на сертификатот за автентичност.

Претпоставувајќи дека корисниците ретко наведете протоколот тип во URL (HTTP е избрана по дифолт) и едноставно следете ги врските, безбедносната истражувач разви напад од таков вид човек во средината да се заобиколат HTTPS енкрипција [1]. Напаѓачот се наоѓа помеѓу клиентот и опслужувачот и промена на линкот https: http:, па на клиентот праќа податоци преку обичен HTTP и HTTPS не. Овој тип на напад е претставен од Moxie Marlinspike на Blackhat конференција 2009 година [2]. Во текот на оваа конференција се претстави не само на функционирањето на напад, но исто така и некои статистика за потрошувачката. Тој успеал да се опорави стотици идентификатори, лични информации и броеви на кредитни картички во 24 часа, никој не се сомнева дека сегашните напади.

HSTS

Види детална статија Строга HTTP транспорт безбедност

Строги HTTP транспорт безбедност (HSTS) е механизам предложи безбедносна политика, дозволувајќи им на опслужувачот да го извести корисникот агенс (како прелистувач) компатибилен, тоа мора да комуницирате со неа на користење на безбедна врска (како Https). Политиката е соопштено на корисникот агент опслужувачот преку HTTP одговорот во заглавието поле со име "Строга-Превоз-безбедност". Политиката одредува на еден временски период за време на која и прелистувачот кој само што треба да пристапи до опслужувачот безбедно.

Пример за работа на HTTP

Ова е пример за разговор меѓу HTTP клиент и HTTP опслужувач на www.example.com, порта 80.

Клиент - прашање

GET /index.html HTTP/1.1 Host: www.example.com

Опслужувач-одговор

HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8

Надворешни врски

„Историја на промената на HTTP“. W3.org. Посетено на 1 август 2010. (англиски)
„Прблеми при изработка на HTTP“. W3.org. Посетено на 1 август 2010. (англиски)
„Класични документи за HTTP“. W3.org. 14 мај 1998. Посетено на 1 август 2010. (англиски)

Протокол за пренос на хипертекст

Содржина