三场不胜！国安一到客场就萎了 靠工体争四如做

Ukázka HTTP po?adavku a odpovědi p?es Telnet v terminálu Ubuntu.

百度 其次要围绕当地所需帮助改善民生。

HyperText Transfer Protocol (HTTP) je internetovy protokol ur?eny pro komunikaci s WWW servery. Slou?í pro p?enos hypertextovych dokument? ve formátu HTML, XML, i jinych typ? soubor?. Pou?ívá obvykle port TCP/80, verze 1.1 protokolu je definována v RFC 2616. Spole?ně s elektronickou po?tou je HTTP nejvíce pou?ívanym protokolem, ktery se zaslou?il o obrovsky rozmach internetu.

Je v?ak pou?íván i pro p?enos dal?ích informací. Pomocí roz?í?ení MIME umí p?ená?et jakykoli soubor (podobně jako e-mail), pou?ívá se spole?ně s formátem XML pro tzv. webové slu?by (spou?tění vzdálenych aplikací) a pomocí aplika?ních bran zp?ístupňuje i dal?í protokoly, jako je nap?. FTP nebo SMTP.

HTTP pou?ívá jako některé dal?í aplikace tzv. jednotny lokátor prost?edk? (URL, Uniform Resource Locator), ktery specifikuje jednozna?né umístění nějakého zdroje v Internetu.

Samotny protokol HTTP neumo?ňuje ?ifrování ani zabezpe?ení integrity dat. Pro zabezpe?ení HTTP se ?asto pou?ívá TLS spojení nad TCP. Toto pou?ití je ozna?ováno jako HTTPS.

?innost protokolu

Protokol funguje zp?sobem dotaz-odpově?. U?ivatel (pomocí programu, obvykle internetového prohlí?e?e) po?le serveru dotaz ve formě ?istého textu, obsahujícího ozna?ení po?adovaného dokumentu, informace o schopnostech prohlí?e?e apod. Server poté odpoví pomocí několika ?ádk? textu popisujících vysledek dotazu (zda se dokument poda?ilo najít, jakého typu dokument je atd.), za kterymi následují data samotného po?adovaného dokumentu.

Pokud u?ivatel bude mít po chvíli dal?í dotaz na stejny server (nap?. proto, ?e u?ivatel v dokumentu kliknul na hypertextovy odkaz), bude se jednat o dal?í, nezávisly dotaz a odpově?. Z hlediska serveru nelze poznat, jestli tento druhy dotaz jakkoli souvisí s p?edchozím. Kv?li této vlastnosti se protokolu HTTP ?íká bezestavovy protokol – protokol neumí uchovávat stav komunikace, dotazy spolu nemají souvislost. Tato vlastnost je nep?íjemná pro implementaci slo?itěj?ích proces? p?es HTTP (nap?. internetovy obchod pot?ebuje uchovávat informaci o identitě zákazníka, o obsahu jeho ?nákupního ko?íku“ apod.). K tomuto ú?elu byl protokol HTTP roz?í?en o tzv. HTTP cookies, které umo?ňují serveru uchovávat si informace o stavu spojení na po?íta?i u?ivatele.

Ukázka komunikace

U?ivatelsky program (klient) se p?ipojí na server cs.wikipedia.org a za?le následující dotaz:

GET /wiki/Wikipedie HTTP/1.1
Host: cs.wikipedia.org
User-Agent: Opera/9.80 (Windows NT 5.1; U; cs) Presto/2.5.29 Version/10.60
Accept-Charset: UTF-8,*

Tímto dotazem ?ádá o dokument /wiki/Wikipedie na serveru cs.wikipedia.org, sděluje svou toto?nost (Opera verze 10.60) a oznamuje, ?e podporuje kódování UTF-8 (ve skute?ném dotazu je podobnych informací je?tě více, toto je zjednodu?eny p?íklad).

Server pak odpoví:

HTTP/1.0 200 OK
Date: Fri, 15 Oct 2004 08:20:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.8
X-Powered-By: PHP/4.3.8
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: cs
Content-Type: text/html; charset=utf-8

První ?ádek odpovědi je stavovy ?ádek obsahující verzi protokolu a informaci, zda byl dotaz úspě?ny ve stylu FTP (?200 OK“), dal?í ?ádky jsou hlavi?ky, za nimi následuje jeden prázdny ?ádek (ozna?ující konec hlavi?ek) a po?adovany soubor. Hlavi?ky obsahují datum a ?as vy?ízení dotazu, popis serveru, informace o typu vráceného dokumentu (MIME typ text/html v kódování UTF-8) a dal?í informace.

Verze HTTP

Nejstar?í verze protokolu HTTP byla zpětně ozna?ena ?íslem verze 0.9 a její popis z roku 1991 lze nalézt na webu w3.org. Pou?ívala pouze metodu GET s jedinym parametrem, a to názvem po?adovaného dokumentu. Server jako odpově? vrátil p?ímo po?adovany dokument bez hlavi?ek (HTTP/… 200 OK…) uvedené v p?edchozí kapitole. P?ípadná chybová hlá?ení vracel server také ve formě HTML dokumentu. Kv?li svym omezením byl rychle nahrazen postupně vyvíjenym protokolem HTTP/1.0.

První popisy protokolu HTTP/1.0 byly publikovány ji? v roce 1992, definitivní standard byl vydán v květnu 1996 jako RFC 1945. Protokol zavádí stavovy ?ádek v odpovědi, HTTP hlavi?ky v po?adavku i odpovědi, nové metody HEAD a POST, a pro rozli?ení typu dokument? pou?ívá MIME.

HTTP/1.1 bylo p?vodně popsáno v RFC 2068 (leden 1997), v ?ervnu 1999 nahrazeno RFC 2616. Tato verze umo?ňuje mimo jiné provozovat více WWW server? na jedné adrese, p?enos více soubor? po sobě v jednom spojení a udr?ování TCP spojení (tzv. keep-alive connection). Dále p?idává dal?í metody OPTIONS, PUT, DELETE, TRACE a CONNECT.

Existuje experimentální roz?í?ení PEP (Protocol Extension Protocol, nebo RFC 2774), které bylo jeden ?as ozna?ováno jako HTTP/1.2, ale v praxi se z?ejmě nepou?ívá.

HTTP/2 je verze protokolu p?ijatá 14. května 2015 jako RFC 7540. Podíl server?, které jsou schopny komunikovat touto verzí HTTP, v zá?í roku 2018 p?ekro?il 30 %., podíl na provozu stoupá a je zatím v ?ádu jednotek procent.

HTTP/3 je nově vyvíjená verze protokolu, ozna?ovaná také ?HTTP over QUIC“, která byla publikována jako Internet draft dne 24. ?íjna 2018.

Dotazovací metody

HTTP definuje několik metod, které se mají provést nad uvedenym objektem (dokumentem). <metoda> <objekt> HTTP/<verze>

GET

Po?adavek na uvedeny objekt se zasláním p?ípadnych dat (proměnné prohlí?e?e, session id, …). Vychozí metoda p?i po?adavku na zobrazení hypertextovych stránek, RSS feed? aj. Celkově nejpou?ívaněj?í.

HEAD

Metoda podobná GET, av?ak nep?edává data. Poskytne pouze metadata o po?adovaném cíli (velikost, typ, datum změny, …).

POST

Odesílá u?ivatelská data na server. Pou?ívá se nap?íklad p?i odesílání formulá?e na webu. S p?edanym objektem se pak zachází podobně jako p?i metodě GET. Data m??e odesílat i metoda GET, metoda POST se v?ak pou?ívá pro p?íli? velky objem dat (víc ne? 512 bajt?, co? je velikost po?adavku GET), nebo pokud není vhodné p?ená?ená data zobrazit jako sou?ást URL (data p?edávaná metodou POST jsou obsa?ena v HTTP po?adavku).

PUT

Nahraje data na server. Objekt je jméno vytvá?eného souboru. Pou?ívá se velmi z?ídka, pro nahrávání dat na server se bě?ně pou?ívá FTP nebo SCP/SSH.

DELETE

Sma?e uvedeny objekt ze serveru. K tomu je zapot?ebí jistych oprávnění stejně jako u metody PUT.

TRACE

Ode?le kopii obdr?eného po?adavku zpět odesílateli, tak?e klient m??e zjistit, co na po?adavku mění nebo p?idávají servery, kterymi po?adavek prochází.

OPTIONS

Dotaz na server, jaké podporuje metody.

CONNECT

Spojí se s uvedenym objektem p?es uvedeny port. Pou?ívá se p?i pr?chodu skrze proxy pro ustanovení kanálu SSL.

Bezpe?né metody

Na tuto kapitolu je p?esměrováno heslo Bezpe?ná metoda.

Některé metody (nap?íklad, HEAD, GET,OPTIONS a TRACE) jsou definovány jako bezpe?né, co? znamená, ?e jsou ur?eny pouze k získávání informací a neměly by změnit stav serveru: Bezpe?né z pohledu změny dat, tedy Pouze ke ?tení (read only). Jinymi slovy, neměly by mít vedlej?í ú?inky, mimo relativně ne?kodnych ú?ink?, jako je protokolování, ukládání do vyrovnávací paměti, které slou?í pro bannerové reklamy, p?ípadně zvy?ování web counter. Tvorba libovolnych GET po?adavk? bez ohledu na souvislost aplikace m??e byt proto pova?ována za bezpe?nou.

Naproti tomu metody jako POST, PUT a DELETE jsou ur?eny pro akce, které mohou zp?sobovat ne?ádoucí ú?inky t?eba na serveru: k zápisu (write). Tyto metody jsou proto obvykle pou?ívány v souladu webovych robot? nebo webového prohledáva?e, některé, které neodpovídají, obvykle podávají ?ádosti bez ohledu na kontext nebo d?sledky.

Navzdory stanovené bezpe?nosti GET po?adavk?, v praxi jejich zpracování na serveru není technicky omezeno ?ádnym zp?sobem. Proto m??e neopatrnym nebo záměrnym programováním zp?sobit netriviální změny na serveru. Toto se nedoporu?uje, proto?e to m??e zp?sobit problémy pro webovou mezipamě?, vyhledáva??m a jinym automatickym prost?edk?m, které mohou zp?sobovat ne?ádoucí změny na serveru.

Kromě toho jsou metody TRACE, TRACK a DEBUG některymi profesionály v oblasti bezpe?nosti pova?ovány za potenciálně ?nebezpe?né“ (z pohledu útoku na server, jiny pohled), proto?e mohou byt pou?ity úto?níky k získání informací, nebo k obejití bezpe?nostní kontroly p?i útocích. Bezpe?nostní softwarové nástroje, jako je Tenable Nessus a Microsoft URLScan informují o p?ítomnosti těchto metod jako bezpe?nostních problémech.

Idempotentní metody

Na tuto kapitolu je p?esměrováno heslo Idempotentní metoda.

Metody PUT a DELETE jsou definovány jako idempotentní, co? znamená, ?e více toto?nych po?adavk? by mělo mít stejny ú?inek jako jeden po?adavek: ?Idempotence 1“. Ji? zmíněné metody GET, HEAD, OPTIONS a TRACE, jsou p?edepsány jako bezpe?né, tedy jsou idempotentní implicitně, kdy? data v?bec nemění: ?Idempotence 0“.

Oproti tomu metoda POST idempotentní byt nutně nemusí: Zaslání shodného POST po?adavku vícekrát m??e stav na serveru ovlivňovat opakovaně a zp?sobit tak i ne?ádoucí ú?inky.

V některych p?ípadech m??e byt opakování stejného po?adavku vhodné a ?ádoucí, vět?inou to v?ak byvá zdroj problém?: Nap?íklad kdy? si u?ivatel neuvědomí, ?e jeho ?innost bude mít za následek odeslání dal?í ?ádosti na server, potom nedostane p?imě?enou odpově?, ?e jeho první ?ádost byla úspě?ná, typicky p?i zdvojeném kliknutí na tla?ítko. I kdy? webové prohlí?e?e mohou zobrazovat upozornění v dialogovych oknech a tím u?ivatele varovat, v některych p?ípadech se nap?íklad i pouhym aktualizováním stránky stejny po?adavek ode?le znovu, co? u? m??e zp?sobit problém.

Nedodr?ení ú?elu metod

Zda je metoda idempotentní ?i bezpe?ná není ur?eno protokolem ani webovym serverem. Technicky vskutku je mo?né psát webové aplikace s takovymi vnit?ními mechanismy, ?e nap?íklad databázové operace INSERT, ?i jiné neidempotentní akce, budou spou?těny voláním metodou GET, ?i jiné HTTP metody, která bě?ně byvá pova?ována za bezpe?nou. Jen?e ignorováním doporu?ení na bezpe?nost/idempotentnost metod riskujeme ne?ádoucí následky, kdy u?ivatel p?edpokládá, ?e opakování stejného po?adavku bezpe?né je. Ale ono není, a dojde k nechtěnému zpracování.

Je tedy vhodné nejen vycházet vst?íc o?ekáváním u?ivatel?, ba dokonce riziku nepochopení, nejednozna?nosti a st?etu nevyjád?enych p?edpoklad? ji? v zárodku p?edcházet, a to volbou vhodné architektury a technologie, které by p?edcházení v?bec umo?ňovaly.

Zabezpe?ené HTTP

Existují dvě metody zabezpe?eného http p?ipojení: HTTPS URI a nadstavba HTTP 1.1 p?edstavená v RFC 2817. Druhou metodu ov?em zatím prohlí?e?e moc nepodporují, tak?e HTTPS se k vytvo?ení zabezpe?ené komunikace pou?ívá nej?astěji.

HTTPS URI

Je syntakticky identické jako http, pouze p?idává signalizaci prohlí?e?i, aby pou?il ?ifrovací metodu SSL/TLS k p?enosu dat. SSL je vhodné pro HTTP, proto?e doká?e poskytnout ochranu p?enosu, i kdy? je pouze jedna strana komunikace ově?ená. Typicky je ově?en pouze server (nap?. u?ivatel potvrdí certifikát). Aby pomocí HTTPS bylo mo?né rozli?ovat virtuální servery, existuje roz?í?ení SNI.

HTTP 1.1 Aktualizovaná hlavi?ka

HTTP 1.1 p?edstavilo podporu pro aktualizaci hlavi?ky. Klient za?íná komunikaci prostym textem, ktery je později nahrazen TLS. Bu? server nebo klient mohou vy?adovat (na po?ádání), aby byla komunikace p?evedena na zabezpe?enou. Nejbě?něji klient za?íná prostym textem a to je následováno po?adavkem serveru na p?evod na zabezpe?enou komunikaci. Vypadá to následovně:

Klient:

GET /encrypted-area HTTP/1.1
Host: www.example.com

Server:

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

Server vrátí kód 426, proto?e kódy za?ínající ?ty?kou zna?í selhání klienta (viz seznam http status kód?)

Vyhody pou?ití této metody zabezpe?ení spo?ívají v:

• odstraňuje problematické p?esměrování a p?episování URL adresy na straně serveru
• umo?ňuje virtuální hosty (na jedné IP adrese více doménovych jmen) na zabezpe?enych serverech

Slabina této metody je v tom, ?e po?adavek na zabezpe?eny http p?enos nem??e byt specifikován v URI. V praxi je pak (neově?eny) server zodpovědny za aktivaci zabezpe?ené komunikace, místo aby za ni byl odpovědny (ově?eny) klient.

Odkazy

Související ?lánky

• Basic access authentication – jednoduchá autentizace v rámci HTTP protokolu
• Stavové kódy HTTP
• HTTP/2
• HTTP/3

Externí odkazy

• Obrázky, zvuky ?i videa k tématu Hypertext Transfer Protocol na Wikimedia Commons
• Slovníkové heslo http ve Wikislovníku

Autoritní data	TDKIV: 000000615 BNF: cb12556450f (data) GND: 4479982-2 LCCN: sh97000529 NLI: 987007549387405171

Portály: Internet