Hypertext Transfer Protocol - Hypertext Transfer Protocol

Hypertext Transfer Protocol
HTTP logo.svg
Mezinárodní standardRFC 1945 HTTP / 1.0 (1996)

RFC 2616 HTTP / 1.1 (1999)
RFC 7540 HTTP / 2 (2015)
RFC 7541 Komprese záhlaví (2, 2015)
RFC 7230 Syntaxe a směrování zpráv (1.1, 2014)
RFC 7231 Sémantika a obsah (1.1, 2014)
RFC 7232 Podmíněné žádosti (1.1, 2014)
RFC 7233 Požadavky na rozsah (1.1, 2014)
RFC 7234 Ukládání do mezipaměti (1.1, 2014)

RFC 7235 Ověření (1.1, 2014)
Vyvinulzpočátku CERN; IETF, W3C
Představený1991; Před 29 lety (1991)
HTTP
Vyžádejte si metody
Pole záhlaví
Stavové kódy
Bezpečnostní metody řízení přístupu
Zranitelnosti zabezpečení
Sada internetového protokolu
Aplikační vrstva
Transportní vrstva
Internetová vrstva
Propojit vrstvu

The Hypertext Transfer Protocol (HTTP) je aplikační vrstva protokol pro distribuovaný, kolaborativní, hypermediální informační systémy.[1] HTTP je základem datové komunikace pro Celosvětová Síť, kde Hyper-textový dokumenty zahrnují hypertextové odkazy k dalším zdrojům, ke kterým má uživatel snadný přístup, například pomocí a myš klikněte nebo klepnutím na obrazovku ve webovém prohlížeči.

Vývoj protokolu HTTP byl zahájen uživatelem Tim Berners-Lee na CERN v roce 1989. Vývoj raného protokolu HTTP Žádosti o komentáře (RFC) byla koordinovaná snaha Pracovní skupina pro internetové inženýrství (IETF) a World Wide Web Consortium (W3C), s prací později přesunutou na IETF.

HTTP / 1.1 byl poprvé dokumentován v RFC  2068 v roce 1997. Tato specifikace byla zastaralá RFC  2616 v roce 1999, který byl rovněž nahrazen RFC  7230 rodina RFC v roce 2014.

HTTP / 2 je efektivnější vyjádření sémantiky protokolu HTTP „on the wire“ a bylo zveřejněno v roce 2015; nyní je podporován prakticky všemi webovými prohlížeči[2] a hlavní webové servery Zabezpečení transportní vrstvy (TLS) pomocí Vyjednávání protokolu aplikační vrstvy (ALPN)[3] kde TLS 1.2 nebo novější je vyžadován.[4][5]

HTTP / 3 je navrhovaným nástupcem protokolu HTTP / 2,[6][7] který se již na webu používá (ve výchozím nastavení povoleno nejpozději Operační Systém Mac ), použitím UDP namísto TCP pro podkladový transportní protokol. Stejně jako HTTP / 2 nezastarává předchozí hlavní verze protokolu. Byla přidána podpora pro HTTP / 3 Cloudflare a Google Chrome v září 2019,[8][9] a lze je povolit ve stabilních verzích prohlížeče Chrome a Firefox.[10]

Technický přehled

URL počínaje schématem HTTP a WWW štítek názvu domény

HTTP funguje jako vyžádat odpověď protokol ve výpočetním modelu klient – ​​server. A webový prohlížeč, například, může být klient a aplikace spuštěná v počítači hosting A webová stránka může být serveru. Klient odešle protokol HTTP žádost zprávu na server. Server, který poskytuje zdroje jako HTML soubory a další obsah nebo vykonává jiné funkce jménem klienta, vrací a Odezva zpráva klientovi. Odpověď obsahuje informace o stavu dokončení požadavku a může také obsahovat požadovaný obsah v těle zprávy.

Příkladem webového prohlížeče je webový prohlížeč uživatelský agent (UA). Mezi další typy uživatelských agentů patří indexovací software používaný poskytovateli vyhledávání (webové prohledávače ), hlasové prohlížeče, mobilní aplikace, a další software který přistupuje, spotřebovává nebo zobrazuje webový obsah.

HTTP je navržen tak, aby umožnil prostředním síťovým prvkům zlepšit nebo povolit komunikaci mezi klienty a servery. Webové stránky s vysokým provozem často těží webová mezipaměť servery, které doručují obsah jménem upstream servery zlepšit dobu odezvy. Webové prohlížeče ukládají do mezipaměti dříve přístupné webové zdroje a pokud je to možné, opakovaně je využívají ke snížení síťového provozu. HTTP proxy servery na soukromá síť hranice mohou usnadnit komunikaci klientům bez globálně směrovatelné adresy předáváním zpráv s externími servery.

HTTP je aplikační vrstva protokol navržený v rámci Sada internetového protokolu. Jeho definice předpokládá základní a spolehlivé transportní vrstva protokol,[11] a protokol kontroly přenosu (TCP) se běžně používá. HTTP však lze upravit tak, aby používal nespolehlivé protokoly, jako je Protokol uživatele Datagram (UDP), například v HTTPU a Simple Service Discovery Protocol (SSDP).

Prostředky HTTP jsou identifikovány a umístěny v síti pomocí Jednotné vyhledávače zdrojů (URL) pomocí Jednotné identifikátory zdrojů (URI) schémata http a https. Jak je definováno v RFC  3986, URI jsou kódovány jako hypertextové odkazy v HTML dokumenty tak, aby tvořily vzájemně propojené Hyper-textový dokumenty.

HTTP / 1.1 je revize původního protokolu HTTP (HTTP / 1.0). V protokolu HTTP / 1.0 samostatný spojení na stejný server je vytvořen pro každý požadavek na prostředek. HTTP / 1.1 může opakovaně použít připojení ke stažení obrázků, skripty, šablony stylů, atd po doručení stránky. Komunikace HTTP / 1.1 proto zažívá méně latence protože navázání připojení TCP představuje značnou režii.

Dějiny

Tim Berners-Lee

Termín Hyper-textový byl vytvořen Ted Nelson v roce 1965 v Projekt Xanadu, který byl zase inspirován Vannevar Bush vize 30. let vyhledávání a správy informací na bázi mikrofilmů "memex „systém popsaný v jeho eseji z roku 1945“Jak si můžeme myslet ". Tim Berners-Lee a jeho tým v CERN jsou připočítáni s vynálezem původního protokolu HTTP, spolu s HTML a související technologií pro webový server a textový webový prohlížeč. Berners-Lee poprvé navrhl projekt „WorldWideWeb“ v roce 1989 - nyní známý jako Celosvětová Síť. První verze protokolu měla pouze jednu metodu, a to GET, která by vyžadovala stránku ze serveru.[12] Odpověď ze serveru byla vždy stránka HTML.[13]

První dokumentovaná verze protokolu HTTP byla HTTP V0.9 (1991). Dave Raggett vedl pracovní skupinu HTTP (HTTP WG) v roce 1995 a chtěl rozšířit protokol o rozšířené operace, rozšířené vyjednávání, bohatší metainformace, spojené s bezpečnostním protokolem, který se stal efektivnějším přidáním dalších metod a pole záhlaví.[14][15] RFC  1945 oficiálně představen a uznán protokol HTTP V1.0 v roce 1996.

Pracovní skupina HTTP plánovala vydat nové standardy v prosinci 1995[16] a podpora pre-standard HTTP / 1.1 na základě pak se vyvíjející RFC  2068 (nazvaný HTTP-NG) byl rychle přijat hlavními vývojáři prohlížečů počátkem roku 1996. Přijetí nových prohlížečů koncovými uživateli bylo rychlé. V březnu 1996 jedna webhostingová společnost uvedla, že více než 40% prohlížečů používaných na internetu vyhovuje protokolu HTTP 1.1. Stejná webhostingová společnost uvedla, že do června 1996 bylo 65% všech prohlížečů přistupujících k jejich serverům kompatibilní s protokolem HTTP / 1.1.[17] Standard HTTP / 1.1, jak je definován v RFC  2068 byla oficiálně vydána v lednu 1997. Vylepšení a aktualizace standardu HTTP / 1.1 byly vydány pod RFC  2616 v červnu 1999.

V roce 2007 Pracovní skupina HTTP byl zčásti vytvořen za účelem revize a vyjasnění specifikace HTTP / 1.1. V červnu 2014 vydala WG aktualizovanou šestidílnou specifikaci, která zastarala RFC  2616:

  • RFC  7230, HTTP / 1.1: Syntaxe a směrování zpráv
  • RFC  7231, HTTP / 1.1: Sémantika a obsah
  • RFC  7232, HTTP / 1.1: Podmíněné požadavky
  • RFC  7233, HTTP / 1.1: Požadavky na rozsah
  • RFC  7234, HTTP / 1.1: Ukládání do mezipaměti
  • RFC  7235, HTTP / 1.1: Ověření

HTTP / 2 byl publikován jako RFC  7540 v květnu 2015.

RokVerze HTTP
19910.9
19961.0
19971.1
20152.0
Koncept (2020)3.0

Relace HTTP

Relace HTTP je sled transakcí síťových požadavků a odpovědí. Klient HTTP iniciuje požadavek vytvořením protokol kontroly přenosu (TCP) připojení ke konkrétnímu přístav na serveru (obvykle port 80, příležitostně port 8080; viz Seznam čísel portů TCP a UDP ). Server HTTP naslouchající na tomto portu čeká na zprávu požadavku klienta. Po přijetí požadavku server odešle zpět stavový řádek, například „HTTP / 1.1 200 OK“, a vlastní zprávu. Tělo této zprávy je obvykle požadovaný zdroj, i když může být také vrácena chybová zpráva nebo jiné informace.[1]

Trvalé připojení

Hlavní článek: Trvalé připojení HTTP

V HTTP / 0.9 a 1.0 je připojení uzavřeno po jednom páru požadavek / odpověď. V protokolu HTTP / 1.1 byl zaveden mechanismus udržování při životě, kdy bylo možné připojení znovu použít pro více než jeden požadavek. Takový trvalé připojení snížit požadavek latence znatelně proto, že klient po odeslání prvního požadavku nemusí znovu vyjednávat připojení TCP 3-Way-Handshake. Dalším pozitivním vedlejším účinkem je, že obecně se spojení časem zrychlí kvůli TCP pomalý start -mechanismus.

Verze 1.1 protokolu také provedla vylepšení optimalizace šířky pásma pro HTTP / 1.0. Například zaveden protokol HTTP / 1.1 blokové kódování přenosu umožnit streamování obsahu na trvalých připojeních spíše než ukládání do vyrovnávací paměti. Zřetězení protokolu HTTP dále zkracuje dobu zpoždění a umožňuje klientům odeslat více požadavků před čekáním na každou odpověď. Další dodatek k protokolu byl obsluha bajtů, kde server vysílá pouze část prostředku výslovně požadovanou klientem.

Stav relace HTTP

HTTP je a bezstavový protokol. Bezstavový protokol nevyžaduje HTTP server uchovat informace nebo stav o každém uživateli po dobu trvání několika požadavků. Někteří však webové aplikace implementovat státy nebo relace na straně serveru pomocí například HTTP cookies nebo skryté proměnné v rámci webové formuláře.

Ověřování HTTP

HTTP poskytuje více schémat autentizace, jako je základní ověřování přístupu a ověřování přístupu digest které fungují prostřednictvím mechanismu výzvy a odpovědi, přičemž server identifikuje a vydá výzvu před poskytnutím požadovaného obsahu.

HTTP poskytuje obecný rámec pro řízení přístupu a autentizaci prostřednictvím rozšiřitelné sady schémat autentizace výzva-odpověď, které může server použít k napadení požadavku klienta a klient k poskytnutí ověřovacích informací.[18]

Ověřovací sféry

Specifikace ověřování HTTP také poskytuje libovolný konstrukt specifický pro implementaci pro další dělení prostředků společných pro daný kořen URI. Řetězec hodnoty sféry, pokud je přítomen, je kombinován s kanonickým kořenovým identifikátorem URI, aby vytvořil součást prostoru ochrany výzvy. To ve skutečnosti umožňuje serveru definovat samostatné obory ověřování pod jedním kořenovým identifikátorem URI.[18]

Formát zprávy

Viz také: Seznam polí záhlaví HTTP

Klient odešle žádosti na server a server odešle odpovědi.

Vyžádejte si zprávu

Zpráva požadavku se skládá z následujících položek:

  • řádek požadavku (např. ZÍSKAT /images/logo.png HTTP / 1.1, který požaduje zdroj s názvem /images/logo.png ze serveru)
  • pole záhlaví požadavku (např., Přijmout jazyk: en)
  • prázdný řádek
  • volitelný tělo zprávy

Řádek požadavku a další pole záhlaví musí končit znakem (tj. A.) návrat vozíku znak následovaný a posuv řádku charakter). Prázdný řádek se musí skládat pouze z a žádného jiného mezery.[19] V protokolu HTTP / 1.1 všechna pole záhlaví kromě Hostitel jsou volitelné.

Řádek požadavku obsahující pouze název cesty je přijímán servery, aby byla zachována kompatibilita s klienty HTTP před specifikací HTTP / 1.0 v RFC  1945.[20]

Vyžádejte si metody

Požadavek HTTP 1.1 vytvořený pomocí telnetu. The žádost zpráva, Odezva část záhlaví a tělo odpovědi jsou zvýrazněny.

HTTP definuje metody (někdy označované jako slovesa, ale nikde ve specifikaci to nezmiňuje sloveso, ani není OPTIONS nebo HEAD sloveso) k označení požadované akce, která má být provedena na identifikovaném zdroji. Co tento prostředek představuje, ať už existující data nebo data generovaná dynamicky, závisí na implementaci serveru. Prostředek často odpovídá souboru nebo výstupu spustitelného souboru umístěného na serveru. Specifikace HTTP / 1.0[21] definoval metody GET, HEAD a POST a specifikaci HTTP / 1.1[22] přidáno pět nových metod: OPTIONS, PUT, DELETE, TRACE a CONNECT. Zadáním v těchto dokumentech je jejich sémantika dobře známá a lze na ně záviset. Libovolný klient může použít libovolnou metodu a server lze nakonfigurovat tak, aby podporoval libovolnou kombinaci metod. Pokud je metoda meziproduktem neznámá, bude považována za nebezpečnou a neidempotentní metoda. Počet metod, které lze definovat, není nijak omezen, což umožňuje specifikovat budoucí metody bez narušení stávající infrastruktury. Například, WebDAV definováno sedm nových metod a RFC  5789 specifikoval NÁPLAST metoda.

Názvy metod rozlišují velká a malá písmena.[23][24] To je na rozdíl od názvů polí záhlaví HTTP, která nerozlišují velká a malá písmena.[25]

DOSTAT
Metoda GET požaduje reprezentaci zadaného zdroje. Žádosti využívající GET by měly být pouze načíst data a neměl by mít žádný další účinek. (To platí i pro některé další metody HTTP.)[1] The W3C zveřejnil pokyny k tomuto rozlišení a řekl: „webová aplikace design by měl být informován výše uvedenými zásadami, ale také příslušnými omezeními. “[26] Vidět bezpečné metody níže.
HLAVA
Metoda HEAD požádá o odpověď identickou s odpovědí požadavku GET, ale bez těla odpovědi. To je užitečné pro načítání metainformací zapsaných v hlavičkách odpovědí, aniž byste museli přenášet celý obsah.
POŠTA
The Metoda POST požaduje, aby server přijal entitu uzavřenou v požadavku jako nového podřízeného subjektu webový zdroj identifikovaný URI. Data POSTed mohou být například anotací pro stávající zdroje; zpráva pro vývěsku, diskusní skupinu, seznam adresátů nebo vlákno komentářů; blok dat, který je výsledkem odeslání a webový formulář k procesu zpracování dat; nebo položku, kterou chcete přidat do databáze.[27]
DÁT
Metoda PUT požaduje, aby byla uzavřená entita uložena pod dodanou URI. Pokud URI odkazuje na již existující zdroj, je upraven; pokud URI neodkazuje na existující prostředek, může server vytvořit prostředek s tímto URI.[28]
VYMAZAT
Metoda DELETE odstraní zadaný prostředek.
STOPA
Metoda TRACE odráží přijatý požadavek, aby klient mohl vidět, jaké (pokud nějaké) změny nebo doplňky byly provedeny zprostředkujícími servery.
MOŽNOSTI
Metoda OPTIONS vrací metody HTTP, které server podporuje pro zadanou URL. To lze použít ke kontrole funkčnosti webového serveru požadavkem '*' místo konkrétního zdroje.
PŘIPOJIT
[29] Metoda CONNECT převádí připojení požadavku na transparentní TCP / IP tunel, obvykle k usnadnění SSL -šifrovaná komunikace (HTTPS) prostřednictvím nezašifrované HTTP proxy.[30][31] Vidět Metoda HTTP CONNECT.
NÁPLAST
Metoda PATCH aplikuje na prostředek částečné úpravy.[32]

Všechny univerzální servery HTTP jsou vyžadovány k implementaci alespoň metod GET a HEAD a všechny ostatní metody jsou podle specifikace považovány za volitelné.[33]

Bezpečné metody

Některé metody (například GET, HEAD, OPTIONS a TRACE) jsou podle konvence definovány jako bezpečný, což znamená, že jsou určeno pouze pro vyhledávání informací a neměla by měnit stav serveru. Jinými slovy by neměli vedlejší efekty, kromě relativně neškodných účinků, jako je protokolování, ukládání do mezipaměti webu, poskytování bannerové reklamy nebo zvyšování a webový pult. Vytváření libovolných požadavků GET bez ohledu na kontext stavu aplikace by proto mělo být považováno za bezpečné. To však není normou nařízeno a výslovně se připouští, že to nelze zaručit.

Naproti tomu metody jako POST, PUT, DELETE a PATCH jsou určeny pro akce, které mohou způsobit vedlejší účinky buď na serveru, nebo externí vedlejší účinky, jako například finanční transakce nebo přenos e-mailem. Takové metody se proto obvykle nepoužívají přizpůsobováním webové roboty nebo webové prohledávače; někteří, kteří neodpovídají, mají sklon podávat žádosti bez ohledu na kontext nebo důsledky.

Přes předepsanou bezpečnost DOSTAT v praxi není jejich zpracování serverem technicky nijak omezeno. Nedbalé nebo záměrné programování proto může na serveru způsobit netriviální změny. To se nedoporučuje, protože by to mohlo způsobit problémy ukládání do mezipaměti webu, vyhledávače a další automatizovaní agenti, kteří mohou na serveru provádět nechtěné změny. Web může například umožnit odstranění zdroje prostřednictvím adresy URL, jako je http://example.com/article/1234/delete, které, pokud je libovolně načteno, dokonce pomocí DOSTAT, jednoduše odstraní článek.[34]

Jedním z příkladů toho, co se v praxi stalo, bylo krátkodobé Google Web Accelerator beta, který předem načetl libovolné adresy URL na stránce, kterou si uživatel prohlížel, což způsobilo automatické změny nebo smazání záznamů hromadně. Beta byla pozastavena jen několik týdnů po svém prvním vydání, po rozsáhlé kritice.[35][34]

Idempotentní metody a webové aplikace

Metody PUT a DELETE jsou definovány jako idempotentní, což znamená, že více identických požadavků by mělo mít stejný účinek jako jeden požadavek. Metody GET, HEAD, OPTIONS a TRACE, které jsou předepsány jako bezpečné, by také měly být idempotentní, protože HTTP je bezstavový protokol.[1]

Naproti tomu metoda POST nemusí být nutně idempotentní, a proto může odesílání identického požadavku POST vícekrát dále ovlivnit stav nebo způsobit další vedlejší účinky (například finanční transakce ). V některých případech to může být žádoucí, ale v jiných případech to může být způsobeno nehodou, například když si uživatel neuvědomuje, že jeho akce bude mít za následek odeslání dalšího požadavku, nebo neobdržel adekvátní zpětnou vazbu, že jeho první požadavek byl úspěšný. Zatímco internetové prohlížeče může ukázat výstražná dialogová okna varovat uživatele v některých případech, kdy opětovné načtení stránky může znovu odeslat požadavek POST, je obecně na webové aplikaci, aby řešila případy, kdy by požadavek POST neměl být odeslán více než jednou.

Všimněte si, že to, zda je metoda idempotentní, protokol nebo webový server nevynucuje. Je perfektně možné napsat webovou aplikaci, ve které (například) je spuštěn GET nebo jiný požadavek vložení databáze nebo jiná neidempotentní akce. Ignorování tohoto doporučení však může mít nežádoucí důsledky, pokud a uživatelský agent předpokládá, že opakování stejného požadavku je bezpečné, pokud není.

Bezpečnostní

Metodu TRACE lze použít jako součást třídy útoků známých jako trasování mezi weby; z tohoto důvodu je běžnou bezpečnostní radou zakázat ji v konfiguraci serveru.[36] Microsoft IIS podporuje proprietární metodu „TRACK“, která se chová podobně a která se rovněž doporučuje deaktivovat.[36]

Zabezpečení metod HTTP
Metoda HTTPRFCŽádost má těloOdpověď má těloBezpečnýIdempotentníUkládatelné do mezipaměti
DOSTATRFC  7231VolitelnýAnoAnoAnoAno
HLAVARFC  7231VolitelnýNeAnoAnoAno
POŠTARFC  7231AnoAnoNeNeAno
DÁTRFC  7231AnoAnoNeAnoNe
VYMAZATRFC  7231VolitelnýAnoNeAnoNe
PŘIPOJITRFC  7231VolitelnýAnoNeNeNe
MOŽNOSTIRFC  7231VolitelnýAnoAnoAnoNe
STOPARFC  7231NeAnoAnoAnoNe
NÁPLASTRFC  5789AnoAnoNeNeNe

Zpráva s odpovědí

Zpráva s odpovědí se skládá z následujících položek:

  • stavový řádek, který obsahuje stavový kód a důvodová zpráva (např. HTTP / 1,1 200 OK, což znamená, že požadavek klienta byl úspěšný)
  • pole záhlaví odpovědi (např. Typ obsahu: text / html)
  • prázdný řádek
  • volitelný tělo zprávy

Stavový řádek a další pole záhlaví musí všechna končit . Prázdný řádek se musí skládat pouze z a žádného jiného mezery.[19] Tento přísný požadavek na je poněkud uvolněn v tělech zpráv pro konzistentní použití jiných systémových konců řádků, jako je nebo samostatně.[37]

Stavové kódy

Viz také: Seznam stavových kódů HTTP

V HTTP / 1.0 a od té doby se první řádek odpovědi HTTP nazývá stavový řádek a obsahuje číselnou hodnotu stavový kód (jako "404 ") a textové důvodová fráze (například „Nenalezeno“). Způsob, jakým uživatelský agent zpracovává odpověď závisí především na kódu a sekundárně na druhém pole záhlaví odpovědi. Lze použít vlastní stavové kódy, protože pokud uživatelský agent narazí na kód, který nerozpozná, může k určení obecné třídy odpovědi použít první číslici kódu.[38]

Standardní rozumové fráze jsou pouze doporučení a lze je nahradit "místními ekvivalenty" na web Developer dle vlastního uvážení. Pokud stavový kód indikoval problém, může agent uživatele zobrazit důvodová fráze uživateli poskytnout další informace o povaze problému. Standard také umožňuje, aby se uživatelský agent pokusil interpretovat důvodová fráze, i když to může být nerozumné, protože standard výslovně stanoví, že stavové kódy jsou strojově čitelné a rozumové fráze jsou čitelné člověkem. Stavový kód HTTP je primárně rozdělen do pěti skupin pro lepší vysvětlení požadavků a odpovědí mezi klientem a serverem, jak jsou pojmenovány:

  • Informační 1XX
  • Úspěšný 2XX
  • Přesměrování 3XX
  • Chyba klienta 4XX
  • Chyba serveru 5XX

Šifrovaná připojení

Nejpopulárnějším způsobem navázání šifrovaného připojení HTTP je HTTPS.[39] Existují také dvě další metody pro navázání šifrovaného připojení HTTP: Secure Hypertext Transfer Protocol a pomocí Záhlaví upgradu HTTP / 1.1 k upgradu na TLS. Podpora těchto dvou prohlížečů však téměř neexistuje.[40][41][42]

Příklad relace

Níže je ukázka konverzace mezi klientem HTTP a spuštěným serverem HTTP www.example.com, port 80.

Žádost klienta

DOSTAT / HTTP/1.1Hostitel: www.example.com

Za požadavkem klienta (skládajícím se v tomto případě z řádku požadavku a pouze jednoho pole záhlaví) následuje prázdný řádek, takže požadavek končí dvojitým novým řádkem, každý v podobě návrat vozíku následuje a posuv řádku. Pole „Hostitel“ rozlišuje mezi různými DNS jména, která sdílejí jeden IP adresa, umožňující pojmenování virtuální hosting. I když je volitelný v HTTP / 1.0, je povinný v HTTP / 1.1. („/“ Znamená /index.html, pokud existuje.)

Odpověď serveru

HTTP/1.1 200 OKdatum: Po, 23. května 2005, 22:38:34 GMTTyp obsahu: text / html; znaková sada = UTF-8Délka obsahu: 155Naposledy změněno: St, 8. ledna 2003 23:11:55 GMTServer: Apache / 1.3.3.7 (Unix) (Red-Hat / Linux)ETag: „3f80f-1b6-3e1cb03b“Přijměte rozsahy: bajtůSpojení: zavřít<html>  <hlava>    <titul>Ukázková stránka</titul>  </hlava>  <tělo>    <p>Ahoj světe, jedná se o velmi jednoduchý dokument HTML.</p>  </tělo></html>

The ETag Pole záhlaví (značka entity) se používá k určení, zda je verze požadovaného prostředku v mezipaměti identická s aktuální verzí prostředku na serveru. Typ obsahu specifikuje Typ internetového média dat přenášených zprávou HTTP, zatímco Délka obsahu označuje jeho délku v bajtech. Protokol HTTP / 1.1 webový server publikuje svoji schopnost reagovat na požadavky na určité bajtové rozsahy dokumentu nastavením pole Rozsahy přijetí: bajty. To je užitečné, pokud klient potřebuje pouze určité části[43] zdroje odeslaného serverem, který je volán obsluha bajtů. Když Připojení: zavřít je odeslán, to znamená, že webový server zavře TCP připojení okamžitě po přenosu této odpovědi.

Většina řádků záhlaví je volitelná. Když Délka obsahu chybí délka je určena jinými způsoby. Zakódované přenosové kódování používá k označení konce obsahu velikost bloku 0. Identita kódování bez Délka obsahu čte obsah, dokud není soket uzavřen.

A Kódování obsahu jako gzip lze použít ke kompresi přenášených dat.

Podobné protokoly

  • The Gopherův protokol je protokol pro doručování obsahu, který byl na počátku 90. let nahrazen protokolem HTTP.
  • The SPDY protokol je alternativou k HTTP vyvinutému na Google, nahrazen HTTP / 2.

Viz také

HTTP
Vyžádejte si metody
Pole záhlaví
Stavové kódy
Bezpečnostní metody řízení přístupu
Zranitelnosti zabezpečení

Reference

  1. ^ A b C d Fielding, Roy T .; Gettys, James; Mogul, Jeffrey C .; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J .; Berners-Lee, Tim (červen 1999). Hypertext Transfer Protocol - HTTP / 1.1. IETF. doi:10.17487 / RFC2616. RFC 2616.
  2. ^ „Mohu použít ... Tabulky podpory pro HTML5, CSS3 atd.“. caniuse.com. Citováno 2020-06-02.
  3. ^ „Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension“. IETF. Červenec 2014. RFC  7301.
  4. ^ Belshe, M .; Peon, R .; Thomson, M. „Hypertext Transfer Protocol verze 2, použití funkcí TLS“. Citováno 2015-02-10.
  5. ^ Benjamin, David. „Používání protokolu TLS 1.3 s HTTP / 2“. tools.ietf.org. Citováno 2020-06-02. To snižuje bariéru pro nasazení protokolu TLS 1.3, což je zásadní vylepšení zabezpečení oproti protokolu TLS 1.2.
  6. ^ Bishop, Mike (9. července 2019). „Hypertext Transfer Protocol verze 3 (HTTP / 3)“. tools.ietf.org. draft-ietf-quic-http-22. Citováno 2019-08-16.
  7. ^ Cimpanu, Catalin. „HTTP-over-QUIC to be renamed HTTP / 3 | ZDNet“. ZDNet. Citováno 2018-11-19.
  8. ^ Cimpanu, Catalin (26. září 2019). „Cloudflare, Google Chrome a Firefox přidávají podporu protokolu HTTP / 3“. ZDNet. Citováno 27. září 2019.
  9. ^ „HTTP / 3: minulost, přítomnost a budoucnost“. Blog Cloudflare. 2019-09-26. Citováno 2019-10-30.
  10. ^ „Firefox Nightly podporuje HTTP 3 - Obecné - Komunita Cloudflare“. 2019-11-19. Citováno 2020-01-23.
  11. ^ "Celkový provoz". RFC 2616. p. 12. sek. 1.4. doi:10.17487 / RFC2616. RFC 2616.
  12. ^ Berners-Lee, Tim. „HyperText Transfer Protocol“. World Wide Web Consortium. Citováno 31. srpna 2010.
  13. ^ Tim Berners-Lee. „Původní HTTP definovaný v roce 1991“. World Wide Web Consortium. Citováno 24. července 2010.
  14. ^ Raggett, Dave. „Dave Raggett's Bio“. World Wide Web Consortium. Citováno 11. června 2010.
  15. ^ Raggett, Dave; Berners-Lee, Tim. „Pracovní skupina protokolu pro přenos hypertextu“. World Wide Web Consortium. Citováno 29. září 2010.
  16. ^ Raggett, Dave. „Plány HTTP WG“. World Wide Web Consortium. Citováno 29. září 2010.
  17. ^ „HTTP / 1.1“. Slovník pojmů Webcom.com. Archivovány od originál dne 21. 11. 2001. Citováno 2009-05-29.
  18. ^ A b Fielding, Roy T .; Reschke, Julian F. (červen 2014). Hypertext Transfer Protocol (HTTP / 1.1): Ověření. IETF. doi:10.17487 / RFC7235. RFC 7235.
  19. ^ A b „Zpráva HTTP“. RFC 2616. p. 31. sek. 4. doi:10.17487 / RFC2616. RFC 2616.
  20. ^ „Apache Week. HTTP / 1.1“. 090502 apacheweek.com
  21. ^ Berners-Lee, Tim; Fielding, Roy T .; Nielsen, Henrik Frystyk. „Definice metod“. Hypertext Transfer Protocol - HTTP / 1.0. IETF. 30–32. sek. 8. doi:10.17487 / RFC1945. RFC 1945.
  22. ^ „Definice metod“. RFC 2616. str. 51–57. sek. 9. doi:10.17487 / RFC2616. RFC 2616.
  23. ^ „RFC-7210 oddíl 3.1.1“. Tools.ietf.org. Citováno 2019-06-26.
  24. ^ „RFC-7231 oddíl 4.1“. Tools.ietf.org. Citováno 2019-06-26.
  25. ^ „RFC-7230 oddíl 3.2“. Tools.ietf.org. Citováno 2019-06-26.
  26. ^ Jacobs, Ian (2004). „URI, adresovatelnost a použití HTTP GET a POST“. Hledání skupiny technické architektury. W3C. Citováno 26. září 2010.
  27. ^ "POŠTA". RFC 2616. p. 54. sek. 9.5. doi:10.17487 / RFC2616. RFC 2616.
  28. ^ "DÁT". RFC 2616. p. 55. s 9.6. doi:10.17487 / RFC2616. RFC 2616.
  29. ^ "PŘIPOJIT". Hypertext Transfer Protocol - HTTP / 1.1. IETF. Června 1999. str. 57. s 9.9. doi:10.17487 / RFC2616. RFC 2616. Citováno 23. února 2014.
  30. ^ Khare, Rohit; Lawrence, Scott (květen 2000). Upgradování na TLS v rámci HTTP / 1.1. IETF. doi:10.17487 / RFC2817. RFC 2817.
  31. ^ „Poznámka k chybě zabezpečení VU # 150227: Výchozí konfigurace HTTP proxy umožňují libovolná připojení TCP“. US-CERT. 2002-05-17. Citováno 2007-05-10.
  32. ^ Dusseault, Lisa; Snell, James M. (březen 2010). PATCH metoda pro HTTP. IETF. doi:10.17487 / RFC5789. RFC 5789.
  33. ^ "Metoda". RFC 2616. p. 36 sec. 5.1.1. doi:10.17487 / RFC2616. RFC 2616.
  34. ^ A b Ediger, Brad (21.12.2007). Advanced Rails: Vytváření průmyslových webových aplikací v rekordním čase. O'Reilly Media, Inc. str. 188. ISBN  978-0596519728. Častou chybou je použití GET pro akci, která aktualizuje prostředek. [...] Tento problém se do očí veřejnosti Rails dostal v roce 2005, kdy byl vydán Google Web Accelerator.
  35. ^ Cantrell, Christian (06.06.2005). „Co jsme se naučili od Google Web Accelerator?“. Blogy Adobe. Adobe. Archivovány od originál dne 19. 8. 2017. Citováno 2018-11-19.
  36. ^ A b „Cross Site Tracing“. OWASP. Citováno 2016-06-22.
  37. ^ „Kanonizace a výchozí nastavení textu“. RFC 2616. sek. 3.7.1. doi:10.17487 / RFC2616. RFC 2616.
  38. ^ „Stavový řádek“. RFC 2616. p. 39. sek. 6.1. doi:10.17487 / RFC2616. RFC 2616.
  39. ^ Canavan, John (2001). Základy zabezpečení sítí. Norwood, MA: Artech House. 82–83. ISBN  9781580531764.
  40. ^ Zalewski, Michal. „Příručka zabezpečení prohlížeče“. Citováno 30. dubna 2015.
  41. ^ „Chromium Issue 4527: implement RFC 2817: Upgrading to TLS within HTTP / 1.1“. Citováno 30. dubna 2015.
  42. ^ „Mozilla Bug 276813 - [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1“. Citováno 30. dubna 2015.
  43. ^ Luotonen, Ari; Franks, John (22. února 1996). Rozšíření načítání rozsahu bajtů na HTTP. IETF. I-D draft-ietf-http-range-retrieval-00.
  44. ^ Nottingham, Mark (říjen 2010). Propojení webu. IETF. doi:10.17487 / RFC5988. RFC 5988.
  45. ^ „Hypertext Transfer Protocol Bis (httpbis) - charta“. IETF. 2012.


externí odkazy