Tento protokol byl později formálně definován jako protokol http verze
0.9 (RFC 1945). Brzy se ukázalo, že natolik jednoduchý protokol nestačí. Pro
přenos atributů dokumentu bylo nezbytné doplnit tělo dokumentu doprovodnými
hlavičkami. Pro přenos atributů dokumentu bylo využito již existujícího
standardu Multipurpose Internet Mail Extensions (MIME, RFC1521) pro
přenos dokumentů elektronickou poštou. Princip funkce protokolu zůstal nezměněn
a tak vznikl protokol http verze 1.0 (RFC 1945). Pro kompatibilitu
s původním protokolem byl zachován začátek prvního řádku požadavku:
První řádek požadavku klienta byl doplněn o číslo verze protokolu http, kterou klient zvládá. Rovněž první řádek odpovědi serveru obsahuje číslo verze protokolu http, kterou zvládá server, a tak se mohou server i klient domluvit s protějšky, které komunikují jinou verzí protokolu. Na dalších řádcích požadavku i odpovědi následují hlavičky, které jsou ukončeny prvním prázdným řádkem. Protokol http verze 1.0 definuje pouze požadavky GET, HEAD a POST. Požadavek GET slouží k získání požadovaného dokumentu a byl ilustrován na předcházejících příkladech. Požadavkem HEAD může klient získat hlavičky odpovědi serveru, které by server zaslal při požadavku GET na daný dokument. Klient tak může z těchto hlaviček zjistit, zda se dokument od posledního přenosu nezměnil.
Požadavkem POST může klient předat data serveru. Data následují za prvním prázdným řádkem po hlavičkách požadavku. Většinou se jedná o data předaná jako odpověď na formulář. U tohoto požadavku musí klient správně signalizovat délku předaných dat hlavičkou Content-Length, protože server nemůže jiným způsobem rozpoznat konec dat. Server hlavičku Content-Length generovat nemusí, protože klient rozezná konec dat podle toho, že server ukončil spojení. Klient ale v tomto případě nepozná, zda byl přenos dokončen celý.
Protokol je rozšířen o požadavky uložení dokumentu na server (PUT) a zrušení dokumentu (DELETE). Další typy požadavků zůstávají volitelným rozšířením: modifikace dokumentu (PATCH), vytvoření vazby (LINK) a zrušení vazby (UNLINK). Poslední dva požadavky by společně s vhodným zpracováním mohly vyřešit principiální nedostatek systému WWW, údržbu konzistence odkazů. Server by mohl při vložení dokumentů zaregistrovat všechny odkazy z dokumentu a při případných přesunech a rušení varovat uživatele.
Udržované spojení bylo zavedeno jako volitelné rozšíření již v protokolu
http verze 1.0, ale vzhledem k problémům v některých
implementacích (např. Netscape 2.0) se příliš nerozšířilo. Mezi mechanismy
udržovaného spojení v obou verzích protokolu je zásadní rozdíl. Zatímco u
protokolu 1.0 bylo udržované spojení volitelným rysem a muselo být při každém
požadavku znovu požadováno a potvrzováno, u protokolu http verze 1.1 je
implicitní a naopak musí být explicitně signalizováno ukončení spojení. Rozdíl
si ukážeme na příkladu přenosu dokumentu a vloženého obrázku. První příklad je
pro protokol http verze 1.0 s udržovaným spojením. Klient, který
požaduje trvalé spojení se serverem, musí zaslat v požadavku hlavičku
Connection s hodnotou keep-alive:
Pokud server odpoví hlavičkou Keep-Alive, může klient zaslat další požadavek po
stejném spojení. Hodnota parametru timeout určuje, jak dlouho bude spojení
udržováno, pokud klient nezašle do té doby další požadavek. Hodnota max je
maximální počet požadavků, kolik může klient v rámci udržovaného spojení
zaslat. Požadavek na udržení spojení musí být opakován při každém dalším
požadavku. Pokud některý požadavek klienta hlavičku Connection neobsahuje,
server uzavře spojení po odeslání odpovědi.
Zatímco u udržovaného spojení protokolu http verze 1.0 musel klient
vyčkat s dalším požadavkem až do odpovědi serveru na předcházející
požadavek, protože do té doby nevěděl, zda server udržované spojení povolí, u
protokolu verze 1.1 mohou být požadavky i odpovědi odesílány bez čekání na
dokončení předchozího požadavku nebo odpovědi (pipelining). Díky tomu
může klient vyslat požadavky na všechny vložené obrázky v jednom paketu a
stejně tak server může shromáždit krátké odpovědi do několika málo delších
paketů. První měření a testy ukazují, že tak lze uspořit oproti protokolu
http verze 1.0 až 90 % paketů putujících po síti mezi klientem a
serverem:
U prvního požadavku musí klient vyčkat, až dostane od serveru první stavový
řádek, ze kterého pozná, že server komunikuje protokolem http verze 1.1.
Pak už může posílat další požadavky asynchronně, bez čekání na odpověď na
předchozí požadavky. Pokud klient i server zvládají protokol verze 1.1, je
spojení mezi klientem a serverem udržováno až do vypršení časového limitu nebo
do explicitního uzavření. Explicitní uzavření je signalizováno hlavičkou
Connection.
HTTP/1.1 200 OK<CR><LF> Transfer-Encoding: chunked<CR><LF> <CR><LF> 1A4C<CR><LF> délka 1. části hexadecimálně text obsah 1. části ... <CR><LF> konec 1. části 2F8<CR><LF> délka 2. části text obsah 2. části ... <CR><LF> konec 2. části 0<CR><LF> prázdná poslední část (konec) Content-MD5: 9c9e5132e291fea3fd4cebb6c2e64f9a<CR><LF> <CR><LF>Část je ukončena prázdným řádkem. Po něm může následovat další část uvozená délkou nebo prázdná poslední část s délkou 0. Za poslední částí dokumentu mohou následovat některé dodatečné hlavičky. Například charakteristika dokumentu může být počítána algoritmem MD5 průběžně a uvedena až na konci odpovědi.
AddLanguage cs czech # cs je identifikátor jazyka AddLanguage en eng # czech je přípona souboruKlient může požádat o konkrétní jazykovou mutaci dokumentu explicitně, doplněním postfixu jména souboru do URL (např. index.html.czech), ale jak lze vidět z uvedené konfigurace, tento postfix nemusí odpovídat oficiální identifikaci jazyka. Většinou se sice volí přípona souborů stejná jako identifikátor jazyka, ale nemusí to být pravidlem. Podstatně pohodlnější je pro uživatele implicitní volba jazyka, nastavením preferencí v prohlížeči. Prohlížeč pak přidává do požadavků hlavičku Accept-Language, ve které sděluje serveru preferovaný jazyk. V tomto případě ovšem musí sever vyhledat vhodnou jazykovou mutaci dokumentu sám, protože zadané URL (např. index.html) neidentifikuje přímo soubor na serveru. Hledání vhodné varianty dokumentu podle preferencí prohlížeče musí být samozřejmě na straně serveru podporováno a povoleno. Například u serveru Apache musí být pro patřičný adresářový podstrom povolen parametr MultiViews:
<Directory /WWW/root> Options Includes ExecCGI MultiViews </Directory /WWW/root>Pokud server dostane požadavek na URL http://server/index.html a v odpovídajícím adresáři existují pouze soubory index.html.czech a index.html.eng, zvolí jeden z nich podle preferovaného jazyka. Pokud požadavek neobsahuje hlavičku Accept-Language, pak server vybere jazykovou mutaci dokumentu dle pevně nastavené priority jazyků.
Výběr mutace dokumentů nebyl v protokolu http verze 1.0 formálně definován. Odpovídající hlavičky sice jako volitelné definovány byly, ale jejich zpracování ne. Protokol http verze 1.1 již výběr variant dokumentů definuje a to na základě požadavků klienta na:
GET /index HTTP/1.1 Accept: text/html, text/plain;q=0.2, audio/*;q=0.2;mxb=100000 Accept-Charset: ISO-8859-2, unicode-1-1 Accept-Language: cs, sk, en;q=0.9, de;q=0.5Pokud není váha uvedena, je uvažována váha 1. V tomto příkladu tedy klient požaduje dokument ve formátu "text/html" s vahou 1.0, ve formátu "text/plain" s vahou 0,2 nebo formátu "audio/*" s vahou 0,2 a maximální velikostí 100000 slabik. Při výběru dostupné varianty dokumentu server vyhledá všechny akceptovatelné varianty, vypočte jejich váhy jako součin jednotlivých vah preferencí klienta a zašle dokument s nejvyšší výslednou vahou. Pokud dokument ve zvolené variantě přesáhne limit velikosti, zvolí se následující vyhovující varianta. Priorita preferencí se stejnými vahami postupuje zleva doprava. Pokud je k dispozici více variant požadovaného dokumentu, obsahuje odpověď navíc hlavičku Vary:
Content-Type: text/html; charset=ISO-8859-2 Content-Language: cs Content-Length: 1241 Vary: accept-language, accept-charset ...Hlavička Vary slouží jako pomocná informace pro ukládání dokumentů v proxy cache serverech. Proxy cache server musí ukládat dokumenty existující ve více variantách společně se všemi odpovídajícími hlavičkami Accept-*, které použil pro jejich získání a které jsou uvedeny v hlavičce Vary. V daném příkladu si musí zapamatovat použité hlavičky Accept-Language a Accept-Charset. Takto uložený dokument může poskytnout klientovi pouze tehdy, pokud klient zadal stejné nebo ekvivalentní preference v těchto hlavičkách. Na hodnotě ostatních hlaviček Accept-* neuvedených v hlavičce Vary nezáleží, protože nemají vliv na výběr varianty požadovaného dokumentu.
Hledání dostupných variant dokumentů je řešeno na straně serveru buď vyhledáním všech souborů se stejným začátkem jména bez přípony (index.*) nebo z popisného souboru variant. V prvním případě jsou atributy dokumentů určeny příponami jmen existujících souborů. Například přípona .html znamená, že soubor je typu "text/html", přípona "czech", že je v jazyce českém, apod. V druhém případě jsou jména souborů a jejich atributy dány definicemi v popisném souboru:
# popisný soubor index.var URI: english.html # jméno souboru Content-Language: en # jazyk Content-Type: text/html; charset=ISO-8859-1 # typ MIME URI: czech.html Content-Language: cs Content-Type: text/html; charset=ISO-8859-2V popisném souboru jsou popsány všechny dostupné varianty jednoho dokumentu. Server pozná, že má použít pro dané URL popisný soubor variant podle toho, že existuje soubor se stejným jménem jako v URL a příponou danou konfigurací serveru (obvykle .var).
Při výběru mutace dokumentů se může stát, že žádná z dostupných variant není pro klienta přijatelná. V tomto případě server může odpovědět chybovým kódem 406 (NOT ACCEPTABLE) a nabídnout dostupné varianty dokumentu:
HTTP/1.1 406 Not Acceptable Server: Apache/1.2b8 dev Vary: accept-language Connection: close Content-type: text/html <HTML><HEAD> <TITLE>406 Not Acceptable</TITLE> </HEAD><BODY> <H1>Not Acceptable</H1> An appropriate representation of the requested resource / could not be found on this server.<P> Available variants: <ul> <li><a href="index.html.czech">index.html.czech</a>, type text/html, language cs <li><a href="index.html.eng">index.html.eng</a>, type text/html, language en </ul> </BODY></HTML>Výběr varianty dokumentu na straně serveru byl sice definován až v protokolu http verze 1.1, ale je již delší dobu v mnoha serverech implementován a používán. Přitom se začínají postupně objevovat nevýhody této koncepce. Především popis přijatelných mutací dokumentu je u inteligentních prohlížečů poměrně složitý a dlouhý, takže by v plném tvaru podstatně prodlužoval každý požadavek. Naopak dokumenty obvykle nejsou dostupné ve všech možných mutacích, ale pouze v několika málo, například ve formátu text/html a application/pdf.. Proto klient posílá v hlavičkách Accept pouze omezenou podmnožinu svých schopností a volba mutace na straně serveru nemůže být díky tomu optimální. Proxy cache servery navíc musí ukládat dokumenty v různých variantách podle různých použitých preferencí klientů, přičemž nemohou zjistit, zda různé preference nevedou na stejnou variantu dokumentu. Obvykle je počet dostupných mutací dokumentu podstatně menší, než výčet mutací, které akceptuje klient. V protokolu http verze 1.1 je proto uvedena možnost přenést výběr varianty dokumentů na stranu klienta. Konkrétní realizace je pak předmětem připravovaného standardu Transparent Content Negotiation.
GET /doc/VeryLongDocument.html HTTP/1.1 Range: 1000-8000,50000-Požadovaná část je určena intervalem od počáteční po poslední požadovanou slabiku dokumentu. Pokud není uvedena horní mez, je přenesen dokument až do konce. Pokud není uvedena dolní mez, je přenesen zadaný počet slabik od konce dokumentu. V jedné hlavičce může být uvedeno více intervalů, oddělených čárkami. Pokud klient požaduje několik částí, zašle je server ve tvaru zprávy o více částech ve formátu MIME. Každá část navíc obsahuje hlavičku Content-Range, která identifikuje obsažený interval:
Content-Type: multipart/x-byteranges; boundary=MARK --MARK Content-Type: text/html Content-Range: 1000-8000/327482 ... --MARK Content-Type: text/html Content-Range: 50000-327482/327482 ... --MARK