HTTP

A HTTP (HyperText Transfer Protocol) egy információátviteli protokoll elosztott, kollaboratív, hipermédiás, információs rendszerekhez. RFC 2616

A HTTP fejlesztését a World Wide Web Consortium és az Internet Engineering Task Force koordinálta RFC-k formájában. Az 1999-ben kiadott RFC 2616 definiálja a HTTP/1.1 verziót. Kiadása után 11 évvel, 2010-ben is ez a legelterjedtebb verzió.

A HTTP egy kérés-válasz alapú protokoll kliens és szerver között. A HTTP klienseket a „user agent” gyűjtőnévvel is szokták illetni. A user agent jellemzően, de nem feltétlenül webböngésző.

A HTTP általában a TCP/IP réteg felett helyezkedik el, de nem függ tőle. A HTTP implementálható más megbízható szállítási réteg felett is, akár az interneten, akár más hálózaton.

Történet

Tim Berners-Lee és csapata alkották meg a HTTP és a HTML legelső változatát, és az ahhoz tartozó technológiát, azaz egy szervert és egy klienst.

0.9 verzió (1991)

Az első dokumentált verzió. A kliens csak a GET metódust használhatta a kérésben. A GET egyparaméteres volt, csak az erőforrás nevét kellett megadni, a verziószámra itt még nem gondoltak. Mivel ebben a verzióban nem volt POST, a kliens nem tudott túl sok információt eljuttatni a szerverre. Ez a verzió még nem támogatta a headereket sem. A szerver válasza ekkor még minden esetben HTML formátumú volt.

1.0 verzió (1996 május)

HTTP munkacsoportot kiterjesztette a protokollt és 1996 májusában kiadta az 1.0 verziót. Itt vezették be a verziószámozás, így a kérések kétparaméteresek lettek. A kliens a kérésben megadja az általa támogatott legfrissebb verziót, a szerver pedig vagy azzal megegyező vagy annál korábbi verzióval válaszol. RFC 1945

1.1 verzió (1999 június)

A HTTP munkacsoport 1995 decemberében tervezte bevezetni az 1.1 verziót. Hivatalosan 1997 januárjában sikerült kiadni az RFC 2068 formájában. Javításokat és frissítéseket tartalmaz az 1.1 verzióhoz az 1999 júniusában kiadott RFC 2616. Az 1.1 szabvánnyal vezették be a perzisztens kapcsolatokat és a request pipeliningot.

A verziószámok használatát az RFC 2145 írja le.

Kérés (request)

Egy HTTP kérés első sora mindig ,,METÓDUS ERŐFORRÁS VERZIÓ" alakú, például így:

GET /images/logo.gif HTTP/1.1

Ezt a sort követheti tetszőleges számú header sor ,,HEADER: ÉRTÉK" alakban, például így:

Accept: text/plain,text/html
Accept-Language: en

A header sorok végét egy üres sor jelzi, melyet az opcionális üzenettest követ. A sorokat a CRLF (azaz kocsi vissza + soremelés) karakterpárral kell elválasztani. A headerek végét jelző üres sor csak ezt a két karaktert tartalmazhatja, nem lehet benne szóköz és tabulátor sem.

Metódusok

HTTP protokoll 8 féle metódust definiál. A metódusok (más szóval verbek) a megadott erőforráson végzendő műveletet határozzák meg.

verb	jelentés
HEAD	Ugyanazt adja vissza, mint a GET, csak magát az üzenettestet hagyja ki a válaszból.
GET	A megadott erőforrás letöltését kezdeményezi. Ez messze a leggyakrabban használt metódus.
POST	Feldolgozandó adatot küld fel a szerverre. Például HTML űrlap tartalmát. Az adatot az üzenettest tartalmazza.
PUT	Feltölti a megadott erőforrást.
DELETE	Törli a megadott erőforrást.
TRACE	Visszaküldi a kapott kérést. Ez akkor hasznos, ha a kliens oldal arra kíváncsi, hogy a köztes gépek változtatnak-e illetve mit változtatnak a kérésen.
OPTIONS	Visszaadja a szerver által támogatott HTTP metódusok listáját.
CONNECT	Átalakítja a kérést transzparens TCP/IP tunnellé. Ezt a metódust jellemzően SSL kommunikáció megvalósításáshoz használják.

Biztonságos metódusok

Biztonságosnak azokat a metódusokat nevezzük, amelyek csak információ lehívására szolgálnak és elvben nem változtatják meg a szerver állapotát. Más szóval mellékhatás nélküliek. Ilyenek például a HEAD, a GET, az OPTIONS és a TRACE. Fontos megjegyezni, hogy a gyakorlatban lehetnek a biztonságos metódusoknak is szerveroldali mellékhatásai. Előfordulhat például, hogy egy GET kérés hatására a szerver cache-elésbe kezd. Ennél veszélyesebb az, amikor a szerver egy egyszerű hiperlinkből mutató GET kérés hatására végez módosítást vagy törlést az adatbázisban. Ez a gyakorlat nem ajánlott, mert problémákat okozhat cache-elő, kereső vagy egyéb automatizált klienseknél, mert ezek nem kívánt változásokat okozhatnak a szerveren az ilyen jellegű GET-eknél.

Idempotens metódusok

Idempotensnek azokat a metódusokat nevezzük, melyeknek többszöri végrehajtása ugyanazt a hatást váltja ki, mint az egyszeri. Ilyenek például a PUT és a DELETE. Minden biztonságos metódus (például HEAD, GET, OPTIONS és TRACE) értelemszerűen idempotens is. Az RFC szerint az idempotens metódusoknál a kliens (leggyakrabban webböngésző) következmény nélkül újrapróbálkozhat, ha a kérés sikertelen volt. Ez arra jó, hogy ha a szerver túl lassan vagy hibásan válaszol, akkor a böngésző felhasználói beavatkozás nélkül újrapróbálhatja az oldal letöltését.

Fontos azonban tudni, hogy a szabványban definiált idempotencia nem nyújt automatikus védelmet a szerveroldali változásoktól. Minden további nélkül írható olyan webalkamazás, amely GET kérés hatására adatbázis módosítást (sql update) vagy beszúrást (sql insert) hajt végre, amelyek nyilvánvalóan szerveroldali változást okoznak.

Az ilyen GET használat és a kliens automatikus újrapróbálkozásának összetalálkozása nemkívánatos eredményeket okozhat, ezért a GET használata tranzakciók esetében kerülendő. Tanácsos követni az RFC-ben definált szabványt, és a GET metódust csak adatok lehívására használni.

Válasz (response)

A HTTP válasz első sora a státuszsor, amely ,,VERZIÓ STÁTUSZKÓD INDOKLÁS" alakú. A státuszkód (angolul status code) egy három számjegyű szám, az indoklás (angolul reason phrase) egy üzenet valamilyen emberi nyelven. Az előbbit inkább gépi, az utóbbit inkább emberi feldolgozásra szánták. Például:

HTTP/1.1 200 OK

vagy

HTTP/1.1 404 Not Found

A szöveges üzenetekre a szabvány csak javaslatokat tartalmaz. A szerver küldhet lokalizált üzeneteket is:

HTTP/1.1 404 Nincs meg.

Státuszkódok

A státuszkódok jelentését az RFC 2616 tartalmazza részletesen, az alábbi lista egy áttekintő osztályozást ad a kezdő számjegy alapján:

• 1xx: Informatív – Kérés megkapva.
• 2xx: Siker – A kérés megérkezett; értelmezve, elfogadva.
• 3xx: Átirányítás – A kérés megválaszolásához további műveletre van szükség.
• 4xx: Kliens hiba – A kérés szintaktikailag hibás vagy nem teljesíthető.
• 5xx: Szerver hiba – A szerver nem tudta teljesíteni az egyébként helyes kérést.

Ha a státuszkód hibára utal, akkor a kliens megjelenítheti a hibaüzenetet, hogy tájékoztassa a felhasználót a hiba természetéről. A szabvány megengedi azt is, hogy a kliens maga interpretálja a státuszkódot és az alapján saját üzenetet generáljon a felhasználónak, de ez zavaró lehet. A szabvány szerint a státuszkódot szánják gépi feldolgozásra, és a „reason phrase” való emberi fogyasztásra. Használhatóak egyedi státuszkódok is, mert a kliens ismeretlen kód esetén az első számjegy alapján már tudja osztályozni a választ.

Header sorok

A státuszsor után header sorok következhetnek a HTTP kérésnél látott módon ,,HEADERNÉV: ÉRTÉK" alakban. Például így:

Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

A header sorokat itt is üres sor zárja, melyet az opcionális üzenettest követ.

A kliens elsősorban a státuszkód, másodsorban a header sorok tartalma alapján kezeli a választ.

Perzisztens kapcsolat

A HTTP/0.9 és 1.0 verziókban a kapcsolat egy kérés-válasz után lezáródik. A HTTP/1.1 verzióban bevezettek egy mechanizmust a kapcsolat életben tartására, így a kapcsolat újrafelhasználható további kérésekhez. A kapcsolat életben tartását hívják idegen szóval perzisztenciának, az ilyen kapcsolatot pedig a perzisztens jelzővel illetik. Ez az újítás gyorsíthatja a kommunikációt, mert a kliensnek nem kell újratárgyalnia a TCP kapcsolatot minden egyes kérésnél.

Egy másik teljesítménynövelő újítás a HTTP/1.1 verzióban az ún. chunked transfer encoding, mellyel a perzisztens kapcsolat felett adatfolyam (stream) továbbítható, a kevésbé gazdaságos bufferelés helyett. A HTTP pipelining segítségével pedig a kliens elküldhet több kérést is egymás után anélkül, hogy megvárná a választ. További hatékonyságoptimalizáló újítás a byte serving, ami azt jelenti, hogy a kért erőforrásnak csak a kliens által kijelölt darabját küldi el a szerver.

Munkamenet (session)

A HTTP egy állapot nélküli protokoll. Az állapot nélküli protokollok előnye, hogy a szervernek nem kell nyilvántartania felhasználói információkat az egyes kérések kiszolgálása között. A HTTP eredetileg nem arra készült, hogy felhasználók jelentkezzenek be rajta keresztül szerverekre és ott munkamenetet (idegen szóval session-t) indítsanak. Történetileg azonban úgy alakult, hogy a HTTP terjedt el széles körben más, felhasználói bejelentkezést támogató protokollok helyett, ami arra kényszerítette a webfejlesztőket, hogy a HTTP-t mintegy megerőszakolva, kerülőutakon járva tárolják a felhasználók munkamenetállapotait. Egy tipikus megoldás cookie-kban tárolni a felhasználói állapotot. Egyéb módszerek még a rejtett változók (például <input type=hidden name=session_id value="1956">) vagy az URL-ben kódolt paraméterek (például /index.php?userid=3) használata illetve a szerveroldali állapotmegőrzés. A legbiztonságosabb megoldás vélhetően a szerveroldali állapotmegőrzés, mert az az egyetlen, amelyet nem tudnak ,,megpiszkálni" rosszindulatú kliensek.

Biztonságos HTTP

Jelenleg két módszer áll rendelkezésre biztonságos http-kapcsolat felépítésére: Az egyik a https URI-séma, a másik pedig a HTTP/1.1 verzióban bevezetett Upgrade header (lásd RFC 2817). Az Upgrade header kliensoldali támogatása jelenleg gyakorlatilag még nem létezik, ezért egyértelműen a https dominál.

A HTTPS URI-séma

A https séma szintaktikailag megegyezik a http-sémával, de jelzi a böngészőnek, hogy használni kell az SSL/TSL titkosító réteget az adatforgalom védelme érdekében. Az SSL különösen célszerű a HTTP esetében, mert akkor is nyújt némi védelmet, ha csak a kommunikáció egyik oldala hitelesített (más szóval autentikált). Az internetes HTTP-tranzakciók esetében jellemzően csak a szerveroldal hitelesített.

A HTTP 1.1 Upgrade header

A HTTP 1.1 verzióban bevezették az Upgrade headert. A kommunikáció során a kliens először egy sima titkosítatlan kérést küld, majd később vagy a kliens vagy a szerver kéri (vagy megköveteli) a kapcsolat titkosítását. Jellemzően a szerver követeli meg a titkosítást:

Kliens

GET /titkos-cuccok HTTP/1.1
Host: www.valami.com

Szerver

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

A 426-os státuszkód jelzi, hogy kötelező a titkosítás, az Upgrade header pedig megadja a támogatott protokollverziókat. Ha a kliens nem támogatja az Upgrade headert és nem ismeri ezt a hibakódot, akkor is tudja az első számjegyből, hogy kliensoldali hibáról van szó.

Lásd még

• X-Forwarded-For