HTTP
HTTP tutvustus
Ressursid
HTTP 1.0
HTTP toimingute struktuur
Esimene päringurida
Esimene vastuserida (staatuserida)
Päiseread
Teate keha (body)
Näide HTTP infovahetusest
Teised HTTP meetodid: HEAD ja POST
HEAD meetod
POST meetod
HTTP Proxid
Mõned soovitused
Järeldus
HTTP 1.1.
HTTP 1.1. kliendid
Host: päis
Tükkide kaupa kodeerimine ja saatmine
Püsiühendused (persistent connections) ja ‘Connection: close’ päis
‘100 Continue’ Vastus
HTTP 1.1 Serverid
Host: päise pärimine
Absoluutsete URL-ide aktsepteerimine
Tükkidena transportimine ja kodeerimine
Püsiühendused ja ‘Connection: close’ päis
‘100 Continue’ vastuse kasutamine
Date: päis
Päringud päistega ‘If-Modified-Since’ või ‘If-Unmodified-Since’
GET ja HEAD meetodite toetus
HTTP versiooni 1.0 päringute toetus
HTTP spetsifikatsioon
Kasutatud materjal
HTTP tutvustus
HTTP on lühend inglisekeelsest mõistest Hypertext Transfer Protocol. See on võrguprotokoll, mida kasutatakse peaaegu kõigi failide ja andmete (koondnimetusega ressursid) edasitoimetamiseks WWWs (World Wide Web). Need võivad olla HTML failid, graafikafailid, mingite küsimustike tulemused jne. Tavaliselt toimib HTTP TCP/IP pistiku kaudu. Igas veebiserveris on HTTP deemon – programm, mis tegeleb sissetulevate HTTP päringutega. Veebibrauser on HTTP klient, mis saadab serveritele päringuid. Kui brauseri kasutaja ‘teostab päringuid’ ehk ‘avab’ veebifaile (sisestades URLi) või klikkides hüperteksti lingil, siis koostab brauser HTTP päringu ja saadab selle URLi poolt näidatud IP aadressile. Viimaks jõuab päring HTTP deemonini, mis saadab vastu nõutud faili.
Brauser on HTTP klient, sest ta saadab päringuid HTTP serverile (veebiserver), mis seejärel saadab kliendile vastuse. HTTP serveri standardport on tavaliselt 80, kuigi nad võivad kasutada ükskõik millist porti.
HTTP koosneb järgnevatest osadest:
•	Ühendus: klient loob ühenduse serveriga, kasutades selleks tavaliselt TCP/IP porti 80
•	Päring: klient saadab serverile päringuteate
•	Vastus: server saadab kliendile vastuse
•	Ühenduse sulgemine: see võib toimuda mõlemalt poolt
HTTP programmeerimise juures oleks kasulik silmas pidada järgmist: tuleb olla hoolikam kui vaid ühele masinale programmeerides ning järgida standardeid. Kui kirjutad enda masinale halva programmi, raiskad enda ressursse (protsessor, ribalaius, mälu), kuid viletsa võrguprogrammi kirjutamine toob kaasa teiste inimeste arvutite ressursside raiskamise.
Ressursid
HTTP-d kasutatakse mitte ainult failide, vaid ka ressursside transportimiseks. Ressursi all mõistetakse mingit hulka informatsiooni, mille tuvastab URL (Universal Resource Locator), kirjeldades täpselt, kus kohas veebis teatud informatsioon asub. Kõige tüüpilisem ressurss on fail, kuid selleks võib olla ka dünaamiliselt genereeritud päringutulemus, CGI skripti väljund, mingi dokument vms.
HTTP 1.0
HTTP toimingute struktuur
Nagu enamik veebiprotokolle, kasutab ka HTTP klient-serveri mudelit: HTTP klient avab ühenduse ning saadab HTTP serverile päringuteate, millele server saadab vastuse, mis tavaliselt sisaldab küsitud ressurssi. Pärast vastuse kohaletoimetamist sulgeb server ühenduse. Päringute ja vastuste formaat on sarnane. Mõlemais sisaldub:
•	algusrida
•	0 või rohkem päiseridu
•	tühi rida
•	teate sisu (näiteks fail, päringuandmed jne.)
Teisisõnu on HTTP teate formaat järgmine:
<algusrida, mis on päringu ja vastuse puhul erinev>
Päis1: väärtus1
Päis2: väärtus2
Päis3: väärtus3

<siia käib teate sisu, mille pikkus võib olla mitmeid ridu ning mis võib sisaldada andmeid binaarsel kujul>
Algusridade ja päiste lõpus peaks olema CRLF, kuigi võib kirjutada ka lihtsalt LF, CR ja LF, mis tähistavad ASCII väärtusi 13 ja 10, kuigi mõned platvormid kasutavad teisi sümboleid.
Esimene päringurida
Algusrida on päringul ja vastusel erinev. Päringurida koosneb kolmest osast, mis on üksteisest tühikutega eraldatud: meetodi nimi, päritud faili local path ja kasutatava HTTP versioon. Tüüpiline päringurida võiks olla järgmine:
GET /path/to/file/index.html HTTP/1.0
Selgitus:
•	GET on kõige tavalisem HTTP meetod, mis sisuliselt ütleb: ‘saada mulle see ressurss’. Teisteks meetoditeks on POST ja HEAD. Meetodite nimed kirjutatakse alati suurte tähtedega.
•	Teekond (path) on see URLi osa, mis asub host name’ i järel.
•	HTTP versioon kirjutatakse alati formaadis “HTTP/x.x”.
Esimene vastuserida (staatuserida)
Esimene vastuserida, mida kutsutakse ka staatusereaks, sisaldab samuti kolme tühikutega eraldatud osa: HTTP versioon, vastuse staatusekood, mis annab päringu tulemuse ning inglisekeelne fraas, mis kirjeldab staatusekoodi. Tüüpilised staatuseread on järgmised:
HTTP/1.0 200 OK
või
HTTP/1.0 404 Not Found
Selgitus
•	HTTP versioon on samasugusel kujul kui päringureal: ‘HTTP/x.x.’
•	Staatusekood on mõeldud arvutile lugemiseks, fraas aga inimesele
•	Staatusekood on kolmekohaline number, milles esimene number määrab kindlaks vastuse üldise kategooria:
-	1xx näitab, et tegu on informatsiooniteatega
-	2xx näitab mingi toimingu õnnestumist
-	3xx juhatab kliendi teisele URL-ile
-	4xx tähistab kliendipoolset viga
-	5xx annab märku serveripoolsest veast
Kõige tuntumad staatusekoodid on:
•	200 OK: päring õnnestus ja vastav ressurss (näiteks fail või skript) saadetakse tagasi.
•	404 Not Found: nõutud ressurssi ei eksisteeri.
•	301 Moved Permanently: ressurss on vastavalt aadressilt jäädavalt ära kolinud.
•	302 Moved Temporarily: ressurss on vastavalt aadressilt ajutiselt ära kolinud.
•	303 See Other (ainult HTTP versioonis 1.1): ressurss on kolinud teisele URL-ile ning klient saab selle automaatselt kätte. Tihti kasutab seda CGI skript, suunamaks brauserit failile.
•	500 Server Error: ootamatu viga serveris. Tavaliselt on põhjuseks vigane serveriskript.
Päiseread
Päiseread annavad informatsiooni päringu või vastuse kohta, või objekti kohta, mis saadetakse teate sisus. Päiseread on tavaliselt tekstipäise formaadis, milleks on rida päise kohta, kujul ‘Päisenimi: väärtus’, ning lõpus CRLF. Sama formaati kasutatakse ka emaili ja uudiste saatmise puhul. Mõningad detailid päiseridade kohta:
•	nagu juba mainitud, tuleb lõppu kirjutada CRLF
•	päise nime puhul ei ole oluline, kas kasutada suur- või väiketähti
•	väärtusele eelneva kooloni ja väärtuse vahel võib olla tühikuid ja tabulaatorivajutusi
•	päiseread, mis algavad tühiku või tabulaatoriga, on osa eelmisest päisest, mis on paigutatud mitmesse ritta, et hõlbustada lugemist.
Seega on järgmised kaks päist võrdsed:
Päis1: mingi-väärtus-1a, mingi-väärtus-1b
PÄIS1: mingi-väärtus-1a
	mingi-väärtus-1b
HTTP versioon 1.0 defineerib 16 päist, versioon 1.1 46 päist. Oma päringutesse oleks viisakas lisada järgmised päiseread:
•	From: päis näitab päringusaatja emaili aadressi
•	User-Agent: päis tuvastab programmi, millelt on tulnud päring kujul ‘Programmi nimi/x.xx’, kus x.xx tähistab programmi versiooni. Näiteks Netscape 3.0 saadab päise ‘User-agent: Mozilla/3.0Gold’.
Päised aitavad veebimeistritel probleemide jälile jõuda. Samuti annavad nad infot kasutaja kohta.
Serverite kirjutamisel peaks oma vastustesse lisama järgmised read:
•	Server: päis on analoogne User-Agent: päisega: ta tuvastab serveritarkvara kujul ‘Programmi nimi/x.xx’. Näiteks, Apache’i serveri üks beetaversioon saadab vastuseks: ‘Server: Apache/1.2b-dev’.
•	Last-Modified: päis annab saadetava ressursi muutmiskuupäeva. Seda kasutatakse cachimisel ja teistes ribalaiust säästvates tegevustes.
Teate keha (body)
HTTP teate päiseridadele võib järgneda andmeid sisaldav keha. Vastuse puhul on see koht, kuhu kliendile saadetakse nõutud ressurss või selgitav tekst, kui ilmneb viga. Päringu korral on tegemist kohaga kuhu serverile saadetakse kasutaja poolt sisestatud andmed või uploaditud failid.
Kui HTTP teatel on sisu, siis on teatel tavaliselt sisu kirjeldavad päiseread, näiteks:
•	Content-Type: päis näitab sisus olevate andmete MIME-tüübi, näiteks text/html või image/gif
•	Content-Length: päis näitab sisus olevate baitide hulka.
Näide HTTP infovahetusest
Faili saamiseks järgnevalt URLi aadressilt:
http://www.mingihost.com/path/fail.html
ava kõigepealt pistik hosti’le www.mingihost.com, port 80 (kasuta vaikimisi määratud porti 80, sest URL ei täpsusta porti). Seejärel saada läbi pistiku midagi alljärgnevat:
GET/path/file.html HTTP/1.0
From: aavik@tpu.ee
User-Agent: HTTPTool/1.0
[tühi rida]
Server peaks vastama millegi järgnevaga, mis tuleb läbi sama pistiku:
HTTP/1.0 200 OK
Date: Mon, 31 Dec 2001 23:59:59 GMT
Content-Type: text/html
Content-Length: 1354
<html>
<body>
<h1>Head uut aastat!</h1>
(sisu läheb edasi)
...
</body>
</html>
Peale vastuse saatmist sulgeb server pistiku.
Teised HTTP meetodid: HEAD ja POST
Lisaks GET-ile on kaks kõige enamkasutatavamat meetodit HEAD ja POST.
HEAD meetod
HEAD päring sarnaneb GET-ile, erinevus on vaid selles, et ta palub serveril tagastada ainult vastuse päised, mitte konkreetset allikat (näiteks teate sisu puudub). See on kasulik juhul, kui tahta kontrollida ressursi omadusi ilma seda tegelikult kohale tõmbamata, säästes seega ribalaiust. HEAD-i tuleks kasutada juhul, kui ei ole vaja faili sisu.
Vastus HEAD-ile ei tohi kunagi sisaldada teate sisu, ainult staatuserida ja päiseid.
POST meetod
POST päringut kasutatakse andmete serverile töötlemiseks saatmiseks, näiteks CGI skripti kaudu. POST päring erineb GET päringust järgnevate omaduste poolest:
•	Teate sisus on koos päringuga saadetud andmeblokk. Teate sisu kirjeldamiseks on tavaliselt lisapäised, nagu näiteks Content-Type: ja Content-Length:
•	Päringu URI ei ole ressurss, vaid programm, mis tegeleb saadetud andmetega
•	HTTP vastus on tavaliselt programmi väljund, mitte staatiline fail
Kõige levinum POST-i kasutusviis on HTML-i vormi kaudu saadud andmete saatmine CGI skripti. Sellisel juhul on Content-Type: päis tavaliselt järgmine: application/x-www-form-urlencoded, ja Content-Length: päis annab URL-kodeeritud andmete pikkuse. CGI skript saab teate sisu läbi STDIN-i ning dekodeerib selle. Järgnev on tüüpiline vorm, mis kasutab POST-i.
POST /path/script.cgi HTTP/1.0
From: aavik@tpu.ee
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
home=lemmik+varv=punane
POST päringut võib kasutada ükskõik milliste andmete saatmiseks, tuleb lihtsalt jälgida, et saatja ja vastuvõttev programm tõlgendaksid formaati ühtemoodi.
Ka GET meetodit saab kasutada vormide saatmiseks.
HTTP Proxid
HTTP proxy on programm, mis tegutseb vahendajana kliendi ja serveri vahel. Ta saab klientidelt päringuid ja edastab need vastavatele serveritele. Sama teed pidi tulevad tagasi ka vastused. Seega, proxy täidab nii kliendi kui serveri ülesandeid.
Proxy-sid kasutatakse tavaliselt tulemüürides. Kui klient kasutab proxy-t, saadab ta tavaliselt kõik päringud vastavale proxy-le, selle asemel et saata need URL serveritele. Proxy-le suunatud päringud erinevad tavalistest päringutest ühe tunnuse poolest: esimeses reas on nõutava ressursi täielik URL, näiteks:
GET http://www.mingihost.com/path/file.html HTTP/1.0
Niimoodi teab proxy, millisele serverile päring edastada (kuigi proxy ise võib kasutada teist proxyt).
Mõned soovitused
Vähemalt võrguprogrammeerimises kehtib ütlus: ‘Vali hoolega mida saadad ning ole tolerantne selle suhtes, mida saad.’ Teiste sinuga suhtlevate klientide ja serverite teadetes võivad olla väiksed vead, mille suhtes tuleks ettevaatlik olla. Abiks võivad osutuda järgmised soovitused:
•	Kuigi päiseridade lõpuks peaks olema CRLF, võivad mõned selle asemel kirjutada lihtsalt LF. Ole valmis kohtama mõlemat.
•	Algteate kolm välja peaksid olema eraldatud ühe tühikuga, kuid mõningatel juhtudel kasutatakse selle asemel mitmeid tühikuid või tab-e.
Järeldus
Eelpool kirjeldatu on HTTP põhiline struktuur. Järgnevas osas on juttu klientide ja serverite upgrade’imisest kasutamaks HTTP versiooni 1.1. On rida uusi nõudeid klientidele ja serveritele. Alates 1997 aasta algusest on veeb läinud üle HTTP versioonilt 1.0. versioonile 1.1.
HTTP 1.1.
Nagu paljud teisedki protokollid, areneb ka HTTP pidevalt. HTTP 1.1. pakub uusi võimalusi ja kompenseerib HTTP 1.0.-i puudujääke. Parandused on järgmised:
•	Kiirem päringutele vastamine, mis on võimalik tänu mitme samaaegse operatsiooni lubamisele ühe ja sama ühenduse vältel.
•	Kiirem päringutele vastamine ja suurem ribalaiuse säästlikkus, mis tuleneb cache’i toetuse lisamisest.
•	Kiirem vastamine dünaamiliselt genereeritud lehtedele, mida võimaldab tükkidena kodeerimise toetus, mis lubab vastuse teele saata enne, kui on teada selle kogupikkus.
•	IP aadresside edukas kasutamine – ühelt ja samalt IP aadressilt on võimalik teenindada mitmeid domeene korraga.
HTTP 1.1. kliendid
HTTP 1.1 kliendid peavad:
•	Lisama igale päringule Host: päise
•	Võtma vastu andmeid tükkidena
•	Toetama püsiühendust (persistent connections) või igasse päringusse lisama ‘Connection: close:’ päise.
•	Tegelema ‘100 Continue’ vastusega
Host: päis
Alates HTTP versioonist 1.1, võib üks server ühel IP aadressil olla mitmete veebidomeenide koduks. Näiteks aadressid ‘www.host1.com’ ja ‘www.host2.com’ võivad olla samas serveris.
Mitmeid ühes serveris eksisteerivaid domeene võib võrrelda hulga inimestega, kes kasutavad sama telefoni: helistaja teab, kellega ta rääkida tahab, kuid telefonile vastaja ei tea seda. Seega, iga HTTP päring peab täpsustama millisele hostile (ja pordile) päring on suunatud. Täielik HTTP 1.1 päring võiks välja näha järgmine:
GET /path/file.html HTTP/1.1
Host: www.host1.com:80
[tühi rida]
‘80’ ei ole tegelikult vaja lisada, sest see on vaikimisi määratud HTTP port.
Host: on ainuke kohustuslik päis HTTP 1.1 päringus. See on ka HTTP 1.1 kõige kasulikum uus omadus. Ilma selleta vajaks iga hostinimi unikaalset IP aadressi, kuid seoses uute domeenide plahvatusliku kasvuga jääb IP aadressidest väheseks.
Tükkide kaupa kodeerimine ja saatmine
Kui server tahab hakata vastust saatma enne selle kogupikkuse teadasaamist (näiteks pika skriptiväljundi puhul), võib ta kasutada tavalist tükkide kaupa kodeerimist ja saatmist, mis jagab vastuse väiksemateks tükkideks ja saadab osade kaupa. Sellise vastuse tunneb kergesti ära, kuna ta sisaldab päist ‘Transfer-Encoding: chunked’. Kõik HTTP 1.1 kliendid peavad olema võimelised vastu võtma tükeldatud teateid.
Tükeldatud teate keha (body) sisaldab hulga tükke, millele järgneb rida, milles esineb ‘0’ (null), pärast mida tulevad omakorda jalused (justnagu päised) ja tühi rida. Iga tükk koosneb kahest osast:
•	Rida, mis näitab ära tükeldatud andmete suuruse (16nd-süsteemis), millele järgneb semikoolon ja lisaparameetrid. Rida lõppeb CRLF-ga.
•	Andmed ise, millele järgneb CRLF.
Seega võib tükeldatud vastus näha välja järgmine:
HTTP/1.1 200 OK
Date: Mon, 31 Dec 2001 23:59:59 GMT
Content-Type: text/plain
Transfer-Encoding: chunked

1a; ignore-stuff-here
abcdefghijklmnopqrstuvwxyz
10
1234567890abcdef
0
mingi-jalus: mingi-väärtus
veel-üks-jalus: veel-üks-väärtus
[siia käib tühi rida]
Tekstiandmete pikkus on 42 baiti (1a + 10, 16ndsüsteemis), andmed ise on abcdefghijklmnopqrstuvwxyz1234567890abcdef. Jaluseid tuleks kohelda sarnaselt päistega.
Tükid võivad sisaldada suvalisi andmeid binaarsel kujul ning võivad olla palju suuremad, kui siin toodud näited. Reasuuruse parameetreid tavaliselt ei kasutata, kuid neid tuleks korrektselt ignoreerida. Ka jalused esinevad harva, kuid sealt võib lugeda näiteks kontrollsummasid ja digitaalallkirju.
Järgnev kood on võrdne eelmisega, kuid ei kasuta tükeldamist:
HTTP/1.1 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/plain
Content-Length: 42
mingi-jalus: mingi-väärtus
veel-üks-jalus: veel-üks-väärtus

abcdefghijklmnopqrstuvwxyz1234567890abcdef
Püsiühendused (persistent connections) ja ‘Connection: close’ päis
HTTP versioonis 1.0 ja varem suleti TCP ühendused pärast igat päringut ja vastust, seega iga ressurss nõudis eraldi ühendust. TCP ühenduste avamine ja sulgemine kulutab märkimisväärsel hulgal protsessori aega, ribalaiust ja mälu. Praktikas koosneb enamus veebilehti mitmetest failidest, mis asuvad samas serveris. Seega on mõttekam ja säästlikum lubada läbi ühe püsiühenduse mitemeid päringuid ja vastuseid.
Püsiühendused on HTTP versioonis 1.1 vaikimisi määratud, seega ei ole nende kasutamiseks erinõudeid. Tuleb lihtsalt ühendus avada ja saata mitmeid päringuid seeriate kaupa (pipelining), ning lugeda vastuseid samas järjekorras, milles saadeti päringud. Niiviisi tehes tuleks hoolega lugeda iga vastuse täpset pikkust ja need korralikult eraldada.
Kui klient lisab vastusele ‘Connection: close’ päise, siis suletakse ühendus pärast vastuse saamist. Seda varianti tuleks kasutada, kui puudub püsiühenduse toetus, või kui on teada, et vastav päring on oma ühenduse puhul viimane. Sarnaselt sellele, kui vastus sisaldab päist, siis sulgeb server ühenduse vastusele järgnevalt ning klient ei peaks läbi selle ühenduse enam päringuid saatma.
Server või ühendus sulgeda enne, kui kõik vastused on saadetud, seega peab klient pidama arvet kõikide päringute üle ja kui vaja, siis need uuesti saatma. Uuesti saatmisel ei tohiks päringuid pipeline'ida enne kui on teada, kas on olemas püsiühendus. Üldse ei tohiks pipeline'ida juhul kui server ei toeta püsiühendusi (näiteks siis kui ta kasutab HTTP 1.0-i).
‘100 Continue’ Vastus
Kui HTTP 1.1 klient saadab päringu serverile, võib server vastata ‘100 Continue’ vastusega. See tähendab, et server on kätte saanud päringu esimese osa. Struktuurilt sarnaneb ‘100 Continue’ vastus HTTP vastusele, s.t., ta sisaldab staatuserida, võimalikke päiseid ja tühja rida. Kuid erinevalt teistest vastustest järgneb sellele alati lõplik vastus. Niisiis, laiendades viimast näidet, võivad serverilt tulevad andmed sisaldada kahte vastust järjest, näiteks:
HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Date: Mon, 31 Dec 2001 23:59:59 GMT
Content-Type: text/plain
Content-Length: 42
mingi-jalus: mingi-väärtus
veel-üks-jalus: veel-üks-väärtus

abcdefghijklmnoprstuvwxyz1234567890abcdef
Tavaline HTTP 1.1 klient võib ühe vastuse lugeda pistikust, kui staatusekood on 100, ning jätta kõrvale esimese vastuse ja lugeda selle asemel järgmist.
HTTP 1.1 Serverid
Serverid peavad:
•	Pärima HTTP 1.1 klientidelt Host: päise
•	Vastu võtma absoluutseid URL-e päringus
•	Vastu võtma päringuid tükeldatud andmetega
•	Toetama kas püsiühendusi või lisama igale vastusele päise ‘Connection: close’
•	Kasutama õigesti ‘100 Continue’ vastust
•	Igale vastusele lisama Date: päise
•	Toime tulema vastustega, millel on päised ‘If-Modified-Since:’ või ‘If-Unmodified-Since’
•	Toetama vähemalt GET ja HEAD meetodeid
•	Toetama HTTP 1.0 päringuid
Host: päise pärimine
Serverid ei luba HTTP 1.1 ilma Host: päiseta päringuid. Kui server saab sellise päringu, siis peab ta vastama ‘400 Bad Request’ vastusega, näiteks

HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 111

<html><body>
<h2>No Host: header received</h2>
HTTP 1.1 requests must include the Host: header.
</body></html>
See nõue kehtib ainult klientidele, kes kasutavad HTTP versiooni 1.1, mitte mingit HTTP tulevikuversiooni. Kui päring kasutab HTTP 1.1-st hilisemat versiooni, siis server võib Host: päise asemel aktsepteerida absoluutset URL-i. Kui päring kasutab HTTP 1.0-i, siis võib server aktsepteerida päringut ilma hosti tuvastamata.
Absoluutsete URL-ide aktsepteerimine
Host: päis on tegelikult hosti tuvastamise probleemile ajutine lahendus. HTTP tulevikuversioonides hakkavad päringud kasutama pathname'i asemel absoluutset URL-i, näiteks:
GET http://www.mingihost.com/path/fail.html HTTP/1.2
Et lubada sellist protokollivahetust, peavad HTTP 1.1. serverid lubama sellist päringuvormi, isegi kui HTTP 1.1 kliendid neid ei saada. Server peab ikkagi andma veateate, kui klient jätab ära Host: päise.
Tükkidena transportimine ja kodeerimine
Niisamuti kui HTTP 1.1 kliendid peavad aktsepteerima tükeldatud vastuseid, peavad serverid aktsepteerima tükeldatud päringuid, mis praktikas on küll suhteliselt vähetõenäoline. Serveritel pole tarvis ise genereerida tükeldatud teateid, nad peavad lihtsalt olema võimelised neid vastu võtma.
Püsiühendused ja ‘Connection: close’ päis
Kui HTTP 1.1 klient saadab läbi ühe ühenduse mitmeid päringuid, siis peab server vastused tagasi saatma samas järjekorras kui päringud. Kui päringus sisaldub ‘Connection: close’ päis, siis on see päring vastava ühenduse puhul viimane ja server peaks peale vastuse saatmist ühenduse sulgema. Lisaks sellele sulgeb server idle ühenduse pärast mingit ajavahemikku, milleks võib olla kasvõi 10 sekundit. Kui sa ei soovi püsiühenduse toetust, siis lisa vastusesse ‘Connection: close’ päis. Kasuta seda päist iga kord, kui tahad ühenduse sulgeda, isegi kui kõiki päringuid pole veel täidetud. Päis määrab ära, et ühendus sulgetakse peale käimasolevat vastust ning korralik HTTP 1.1 klient tuleb sellega õigesti toime.
‘100 Continue’ vastuse kasutamine
See vastus on abiks aeglaste linkide korral. Kui HTTP 1.1 server saab HTTP 1.1 päringu esimese rea, siis peab ta vastama kas ‘100 Continue’ või veateatega. Kui ta saadab ‘100 Continue’ vastuse, siis peab ta saatma veel ühe, lõpliku vastuse pärast seda kui päring on töödeldud. ‘100 Continue’ vastus ei nõua päiseid, kuid sellele peab järgnema tavapärane tühi rida, näiteks:
HTTP/1.1 100 Continue
[siia käib tühi rida]
[siia käib teine HTTP vastus]
HTTP versiooni 1.0 klientidele ei tohiks saata ‘100 Continue’ vastust, sest nad ei oska seda käsitleda.
Date: päis
Üheks HTTP 1.1 tähtsaks paranduseks on cache’imine, mis ei toimi ilma ajalise määratluseta vastuste korral. Niisiis peavad serverid iga vastuse märgistama Date: päisega, mis sisaldab hetkeaega järgneval kujul:
Date: Mon, 31 Dec 2001 23:59:59 GMT
Päringud päistega ‘If-Modified-Since’ või ‘If-Unmodified-Since’
Vältimaks nende ressursside saatmist, mida tegelikult ei ole vaja saata ning säästmaks ribalaiust, on HTTP versioonis 1.1 kasutusel päringupäised If-Modified-Since: ja If-Unmodified-Since. Esimene tähendab: “saada ressurss ainult sel juhul, kui seda on muudetud vastavast kuupäevast alates”, ning teine märgib täpselt vastupidist. Tegelikult pole klientidel tarvis neid päiseid kasutada. Tulenevalt eelmistest HTTP versioonidest võib kuupäeva väärtus olla ainult kolmel järgneval kujul:
If-Modified-Since: Mon, 31 Dec 2001 23:59:59 GMT
If-Modified-Since: Monday, 31-Dec-01 23:59:59 GMT
If-Modified-Since: Mon Dec 31 23:59:59 2001
Kuigi serverid peavad aktsepteerima kõiki kolme formaati, siis HTTP 1.1 kliendid ja serverid peavad genereerima ainult esimest varianti. Kui kuupäev on vale, tuleks päist ignoreerida.
If-Modified-Since päist kasutatakse GET päringuga. Kui nõutud ressurssi on muudetud alates antud kuupäevast, siis tuleks päist ignoreerida ja ressurss vastu saata. Muul juhul peaks saatma vastuse ‘304 Not Modified’, mis sisaldab Date: päist ja millel ei ole teate keha, näiteks:
HTTP/1.1 304 Not Modified
Date: Mon, 31 Dec 2001 23:59:59 GMT
[siia käib tühi rida]
If-Unmodified-Since: päis on eelmisega sarnane, kuid seda saab kasutada iga meetodiga. Kui nõutud ressurssi ei ole muudetud alates antud kuupäevast, siis ignoreeri päist ja saada vastu ressurss. Vastasel juhul saada vastus ‘412 Precondition Failed’, näiteks:
HTTP/1.1 412 Precondition Failed
[tühi rida]
GET ja HEAD meetodite toetus
HTTP 1.1 server peab toetama vähemalt GET ja HEAD meetodeid ning CGI skriptide puhul ka POST meetodit.
Neli ülejäänud meetodit (PUT, DELETE, OPTIONS ja TRACE) on küll kirjeldatud HTTP 1.1-s, kuid neid kasutatakse harva. Kui klient pärib meetodit, mille toetus puudub, siis saada vastus ‘501 Not Implemented’, näiteks
HTTP/1.1 501 Not Implemented
[tühi rida]
HTTP versiooni 1.0 päringute toetus
Ühildumaks vanemate brauseritega, peavad HTTP 1.1 serverid toetama ka HTTP 1.0 päringuid. Kui päring kasutab HTTP 1.0 (see on ära näidatud esimeses päringureas), siis tuleks ei tohiks nõuda Host: päist ega saata ‘100 Continue’ vastust.
HTTP spetsifikatsioon
Enne HTTP-ga tegelemist oleks kasulik lugeda ametlikku spetsifikatsiooni. HTTP versioon 1.0 ei saanud kunagi ametlikuks Interneti standardiks, vaid ta on RFC 1954 poolt kirjeldatud de facto standard. HTTP 1.1 arendati välja IETF töögrupi poolt. Enne üksmeelsele otsusele jõudmist koguti avalikult sisendeid paljudest allikatest. 1997 aasta jaanuaris loodi RFC 2068 standard.

Kasutatud materjal
1.	http://www.jmarshall.com/easy/http
2.	http://www1.ics.uci.edu/pub/ietf/http
3.	http://www.w3.org/Protocols/HTTP