Brzy se ukázalo, že natolik jednoduchý protokol nestačí. Klient nebyl schopen rozeznat atributy zaslaného dokumentu jinak, než z přípony jména dokumentu. To původně nevadilo, protože byl omezen počet zpřístupněných dokumentů a vesměs se jednalo o textové nebo hypertextové dokumenty. Po zavedení odkazů na obrázky, zvuky, video sekvence a jiné typy médií se ukázalo nepružné odvozovat typ dokumentu na straně klienta podle přípony jména dokumentu na straně serveru. Dalším problémem byla neznalost velikosti dokumentu, klient musel číst data, která mu posílal server, tak dlouho, dokud server neukončil spojení. Uživatel při přenosu nevěděl, jak velký bude přenášený dokument a nemohl se podle toho zařídit. Rovněž neexistoval způsob, jak zjistit čas poslední modifikace dokumentu a klient proto musel přenášet každý dokument vždy znovu.
První vylepšení na sebe nenechalo dlouho čekat, a protože jsou při přenosu zpráv v rámci Internetu používány textové hlavičky, bylo logickým krokem doplnění hlaviček do požadavku klienta i odpovědi serveru. Textové hlavičky ve tvaru "Jméno: hodnota" umožňují neomezený budoucí vývoj protokolu doplňováním dalších hlaviček. Základní sada hlaviček popisuje typ a atributy dokumentu a vychází ze standardu MIME (Multipurpose Internet Mail Extensions, RFC1521). Ostatní hlavičky slouží pro přenos pomocných informací a předávání parametrů mezi klientem a serverem.
Zavedení hlaviček do požadavků a odpovědí přineslo problém rozlišení požadavků
původní verze protokolu od verze s hlavičkami. Protože při komunikaci klienta
se serverem mohou nastat všechny čtyři kombinace (starý klient/starý server,
starý klient/nový server, atd.), bylo třeba rozlišit, zda se jedná o požadavek
původního nebo nového protokolu, a zda se jedná o odpověď původního nebo nového
protokolu. Server musí při přijetí požadavku starým protokolem ukončit čtení po
prvním řádku, protože klient dále nic nepošle. Proto muselo být doplněno
rozlišení už do prvního řádku zaslaného klientem. Rozlišení bylo dosaženo
doplněním verze protokolu za jménem požadovaného dokumentu. Pokud dostane
takovýto požadavek starý server, označení protokolu za jménem dokumentu bude
buď ignorovat, nebo ho bude chápat jako součást jména dokumentu a odpoví
chybou. Odpověď novým protokolem je odlišena tím, že musí obsahovat na prvním
řádku výsledek ve tvaru "verze_protokolu kód_odpovědi". Protože
staré servery předávaly pouze hypertextové dokumenty, které by neměly obsahovat
takovýto tvar prvního řádku, je toto rozlišení postačující. Tento způsob
rozlišení starého a nového protokolu zároveň dovoluje rozlišení novějších verzí
protokolu.
V této podobě je protokol http používán dodnes. V květnu 1996 byla formálně publikována specifikace protokolu http verze 1.0 ve formě dokumentu RFC (Request For Comment). Lze ji nalézt například na adrese http://www.fit.vutbr.cz/pub/doc/rfc/rfc1945.txt.
V současné se věnuje komise IETF HTTP (Internet Engineering Task Force) standardizaci nové verze protokolu. Pro urychlení schválení specifikace protokolu verze 1.0 byly vlastně vypuštěny od druhého návrhu specifikace mnohé zatím neimplementované rysy protokolu a byly přesunuty do návrhu protokolu http verze 1.1 (viz http://www.fit.vutbr.cz/pub/doc/rfc/rfc2068.txt). Základním nedostatkem protokolu http verze 1.0 je paradoxně jeho jednoduchost. Nedovoluje totiž při jednom spojení se serverem získat více dokumentů. Při původním použití systému WWW to příliš nevadilo, jeden dokument obvykle obsahoval pouze text a v něm pouze odkazy na další navazující dokumenty. Dnešní dokumenty ale často obsahují desítky vložených obrázků a pro zobrazení takových dokumentů musí klient přenést nejen vlastní dokument, ale také všechny vložené obrázky. Pro jejich získání používá klient také protokol http a musí proto vygenerovat tolik požadavků, kolik je v dokumentu obrázků. Sekvenční generování požadavků trvá poměrně dlouho, protože u přenosu malého objemu dat trvá nejdéle navázání spojení. Většina klientů proto generuje pro přenos vložených obrázků paralelně několik požadavků, které paralelně zpracovávají. Přesto nelze ani při této metodě využít teoretické přenosové kapacity spoje. Souvisí to s vlastnostmi protokolu TCP, který je optimalizován spíše pro déletrvající souvislý přenos dat při jednom spojení, než pro krátké, nezávisle spojované přenosy. Podrobnou analýzu lze nalézt v dokumentu http://sunsite.unc.edu/mdma-release/http-prob.html. Návrh protokolu http verze 1.1 řeší tento problém zavedením udržovaného spojení, které není ukončeno po přenosu jednoho dokumentu.
Požadavky a odpovědi obsahují společné obecné hlavičky a případně hlavičky popisující přenášená data. Další hlavičky jsou speciální pro požadavek a pro odpověď. Hlavičky jsou ukončeny prvním prázdným řádkem. Konec řádku hlavičky má být signalizován znaky CR a LF, ale mnohé servery zasílají jen znak LF.