Tartalom A HTTP protokoll 1. A HTTP protokoll...1 1.1. Címzés a weben...1 1.1.1. Az URL kódolás (URL encoding)...2 1.2. A MIME típusok...3 1.3. A TCP/IP protokoll szerepe a HTTP alatt...4 1.4. A HTTP protokoll metódusai...5 1.5. Fontosabb HTTP fejlécek...7 Általános fejlécek...8 A kérés fejlécei...8 A válasz fejlécei...10 Entitás fejlécek...11 1.6. A HTTP status kódok...11 1.7. A web szerver CGI változói...12 1.8. A sütik (Cookie)...13 1. A HTTP protokoll 1.1. Címzés a weben A weben való címzés erőforrások (web resources) elérést biztosítja. Ez standardizálva van, a standardokat az IETF (Internet Engineering Task Force) publikálja (RFC1630, RFC1738). A standard egy URI (Unified Resource Identifier = egységes forrás azonosító) megnevezésű címet definiál, amely lehet: URL (Unified Resource Locator) az erőforrás hely szerint van azonosítva. URN (Unified Resource Name) az erőforrás név szerint azonosítódik. Az utóbbit ritkábban használjuk, mert azt feltételezi, hogy rendelkezünk egy olyan katalógussal, amely egy névhez fizikai elérhetőséget (valamilyen gépek által elérhető címet) rendel. Az URL A weben található tartalmak, objektumok hely szerinti eléréséhez egy egységes címzési módot határoztak meg. Ez könnyen és biztonságosan értelmezhető automaták és ember által is. Neve: egységes forrásazonosító. Uniform Resource Locator, URL: a compact string representation for a resource available via the Internet. (rfc1738) Felépítése: <séma>:<séma specifikus-rész> 1
Csak nyomtatható US-ASCII karakterekből épül fel, 20h-7Eh-ig, A 00-1F és 7F kontroll karaktereket kódolni kell. A séma valamilyen eléréshez szükséges mechanizmust jelent, többnyire egy protokollt. Ilyenek az ftp:, nntp:, http:. A séma specifikus rész szintaxisa: //<user>:<password>@<host>:<port>/<url-path> Jelentésük: user:password felhasználó, jelszó host: a számítógép teljes Internet neve, FQDN (Fully Qualified Domain Name), vagy egy IP cím (4 számjegy pontokkal elválasztva). pl.: http://ms.sapientia.ro:80/index.html http://193.16.218.66/ port: a hálózati kapcsolat szerver oldali TCP port száma. A legtöbb sémának létezik implicit port száma, de mást is lehet helyette használni. Pl.: 80, 23, 443, 22, 21-es portok. url-path: sémán belüli elérési út. A / nem része az elérési útnak. Ez pl. a http: séma esetében egy valódi vagy egy virtuális könyvtár (címzés) a webszerveren. A HTTP protokoll esetében ennél több információt is tartalmaz. A http: URL teljes alakja: //<user>:<password>@<host>:<port>/<url-path>?<query-string>#<fragment> query-string: ennek a sztringnek a segítségével jutnak el a címzett forráshoz a paraméterek. Névérték párokat tartalmaz. http://ms.sapientia.ro?szekcio=1&oldal=35 fragment: a címzett forráson belül jelöl ki egy megjelenítési pontot, általában a böngésző használja fel, ettől a ponttól kezdi a megjelenítést. http://ms.sapientia.ro?szekcio=1&oldal=35#bekezdes A kijelölt megjelenítési pontot, amelyet HTML-ben kódolunk anchor-nak nevezzük, a HTML kódja: <a name="anchor">itt a bekezdés.</a> 1.1.1. Az URL kódolás (URL encoding) Az URL-ben előforduló speciális karaktereket kódolni kell. Ezek az alábbiak: 2
-kontroll karakterek ASCII 00h-1Fh és 7Fh -8 bites karakterek 80h-8Fh -Az URL speciális karakterei (ha előfordulnak a nevekben) ; /? : @ & = + $ -elválasztó karakterek: < > # % " -Más karakterek, amelyek veszélyeztetik a biztonságot, mert más protokollokban jelentéssel bírnak: { } \ ^ [ ] ` -a szóköz A használható karakterek: a-z A-Z 0-9 - _.! ~ * ' ( ) A kódolandó karaktereket egy % jellel és egy kétjegyű hexadecimális számmal kódolunk. Pl.: %2E %20 Ezt a kódolást el kell végezni, ha programból küldünk vagy fogadunk URL-t. Erre minden programozási nyelv biztosít függvényeket (urlencode, urldecode típusú függvények). A relatív és abszolút URL fogalma: amint a HTML <a> eleménél láttuk, a gyakorlatban weblapokon használható az URL webkönyvtárhoz viszonyított, relatív része. 1.2. A MIME típusok (Multipurpose Internet Mail Extensions) Standard: RFC 2045 és 2046 (http://www.ietf.org/rfc.html) A hálózati szolgáltatásoknak különböző típusú adatokat kell átvinniük az Interneten. Ezeknek az adatoknak a formátumát a helyes átküldés és fogadás miatt pontos standardok definiálják. A legtöbb használt adattípus megtalálható köztük, de újak regisztrálására is van lehetőség. A regisztrálást az IANA (Internet Assigned Media Types) nevű szerveztnél kell megtenni (lásd: http://www.iana.org/assignments/media-types/). Alapelvek: -minden hálózaton átküldött adatnak egyértelmű MIME típust kell definiálni -a típusokon belül minden használt formátumnak egyértelmű altípust kell definiálni Az alábi táblázat néhány adat típus média típusát tartalmazza. Text Típusok Altípusok plain, html, xml, rss, tab-separated-value Image gif,jpeg,tiff,vnd.dwg,... Audio basic, mp3,... Video mpeg,quicktime,... Application zip, vnd.ms-excell, mathematica,... 3
Típusok Multipart Message Altípusok Csak az email-ekben használják, több különböz ő adattípusból összeálló szerkezet Email A formátumok pontos leírások megtalálhatóak az IANA honlapján a megadott címből kiindulva, minden egyes típusra és formátumra. A HTTP protokoll mindig meghatározza a web kérések esetén átvitt típust. Ezeket a protokoll fejléc sorai tartalmazzák, pl.: Content-Type: Image/png 1.3. A TCP/IP protokoll szerepe a HTTP alatt A számítógépes hálózatok esetében a gépek közti kommunikáció bizonyos szabályok szerint zajlik. Ezeket a szabály rendszereket nevezzük protokolloknak. Az Interneten több protokollt használunk, ezeket közös névvel a TCP/IP protokoll családnak nevezzük. rétegprotokoll Feladatok megoszlása TCP és IP közt egy TCP kapcsolat értelmezése (socket-ek közt létrejött kapcsolat) a DNS rendszer felépítése, szerepe a web működésében Az alkalmazás protokollok általában 3 típusúak: összeköttetéses (pl. HTTP web alkalmazások, FTP, SMTP). Ezek használják az Interneten a TCP-t. összeköttetés mentes (pl. RTP) valós idejű bit folyam átvitele vegyes (pl. DNS: mindkettőt használja) Az alábbi ábra az Interneten használt legfontosabb protokollokat mutatja be: 4
1.4. A HTTP protokoll metódusai 1990 és 1997 közt fejlesztették, három változat ismert, ezek közül az utolsót alkalmazzuk ma, de a szervereknek a másodikat is ki kell szolgálni (1990 HTTP/0.9; 1995 HTTP/1.0; 1997 HTTP/1.1). A továbbiakban a HTTP protokoll egy HTTP kérést jelölő üzenetét metódusnak fogjuk nevezni (method). Ez mindig egy HTTP kérést határoz meg (request). Az erre adott szerver oldali válasz a HTTP válasz (response). HTTP kérés megszakadó TCP kapcsolattal HTTP kérés perszisztens kapcsolattal Egy web tartalom lekérdezése A HTTP kérés / válasznak 4 fázisa van: -a TCP kapcsolat létrehozása 5
-a kérés elküldése -a válasz fogadása -a kapcsolat felbontása A HTTP kérések felépítése A kérések szövegsorokból épülnek fel. Az első sor tartalmazza a kérés típusát vagy metódusát, a kért dokumentum relatív címét illetve a HTTP protokoll verziót: Pl.: GET /index.html HTTP/1.1 Ezután a fejléc sorai jönnek. A HTTP fejlécek három kategóriába csoportosíthatóak: Általános információk (General-Header) A kérésre vonatkozó információk (Request-Header) A kért dokumentum tulajdonságaira vonatkozó információk (Entity-Header) A fejlécek után egy üres sor, és amennyiben vannak adatok is azok következnek (ez. pl. a POST metódusra jellemző). Ha nincsenek adatok akkor a fejléc után 2 üres sorral zárul a kérés. A HTTP válaszok struktúrája A HTTP válasz első sora a válaszprotokoll verziót, a kérés sikerességére vonatkozó un. státus kódot illetve egy rövid szöveget tartalmaz. Pl. HTTP/1.1 200 OK A 1.1 a verzióra utal, a 200-as a sikeres kérést jelenti (a státus kódokat lásd a fejezet végén). Ez után következnek a fejléc sorok, majd a küldött adatok. A fejléc sorok ugyancsak három osztályba tartozó információkat tartalmaznak: Általános információk (General-Header) A válaszra vonatkozó információk (Response-Header) A küldött dokumentum tulajdonságaira vonatkozó információk (Entity-Header) A fejléc után egy üres sor, majd a küldött adatok következnek. Egyszerű weblap lekérésekor ez maga a HTML szöveg. A HTTP metódusok Metódus neve GET Leírása Célja dokumentumok lekérdezése, és nem adatok elküldése. Nem kell olyan kérésre használni, amelyek szerver oldali módosításokat okoznak. A kérésnek nincs BODY része. 6
HEAD POST PUT DELETE A HEAD kérés csak a webcím által szolgáltatott fejlécet kéri le, információk miatt. Pl. le szeretnénk kérdezni, módosult-e a weblap tartalma, a nélkül, hogy magát a weblapot lekérdezzük. Adatok elküldésére használják a kliens oldali programok. Az elküldött adatok a kérés BODY részében találhatóak, név-érték párok formájában. Részletesen az űrlapok kezelésénél fogunk vele foglalkozni. A küldött dokumentum a szerveren lesz tárolva, tulajdonképpen a metódus "felírja" a szerverre a dokumentumot. Töröl egy dokumentumot a szerverről. A 3 legfontosabb HTTP kérés a GET, POST és a HEAD. Mindennapi programozás során gyakorlatilag csak a GET és POST metódusokat használjuk. A HTTP kérések mindkét irányban fejléc illetve törzs részekből állanak (header és body). A GET metódus esetében például így néz ki egy kérés/válasz pár: HTTP kérés: GET /index.html HTTP/1.1 Host: localhost Accept: image/gif, image/png, text/plain, text/html, text/xml Accept-Language: hu, en Connection: Keep-Alive User-Agent: Mozilla/4.0 (compatible; MSIE6.0; Windows XP) HTTP válasz: HTTP/1.1 200 OK Date: Mon, 06 Mar 2006 08:00:32 GMT Server: Apache/1.3.22 (Unix) Last-Modified: Wed, 07 Jan 2005 07:02:11 GMT Content-Length: 130 Content-Type: text/html <html> <head> <title>teszt dokumentum</title> <body> <h1>cim</h1> <p>elso paragrafus</p> </body> </html> 1.5. Fontosabb HTTP fejlécek Az alábbiakban bemutatunk néhányat a fontosabb HTTP fejlécek közül. 7
A HTTP 1.1-es protokoll fejléceit mutatjuk be: Fejléc neve Általános fejlécek Date Hogyan küldi a webszerver Az általános fejlécek a kérés és válaszban egyaránt előfordulnak, esetleg más értékekkel. A válasz időbélyegét tartalmazza: Date: Mon, 06 Mar 2006 08:00:32 GMT Connection Azt kéri a másik féltől. hogy tartsa meg a TCP kapcsolatot még egy bizonyos számú szekundumig, illetve bontsa le azt. Connection: Keep-Alive vagy: Connection: Close Cache-Control Ez a fejléc a szerver és kliens közti köztes tárolóknak szól. Az alábbi formával: Cache-Control: no-cache, no-store, no-transform a szerver megtiltja a cache tárolóknak a küldött dokumentum tárolását. Ha a kliens küldi a no-cache opciót, akkor ő jelzi, hogy nem akar tárolást. Transfer-Encoding A kérés vagy válasz adat része (body) különféle módon küldhető. Egyik ilyen gyakran használt mód a darabokban (chunk) való küldés. Ilyenkor az adatrész fel van darabolva, és minden egyes darab hosszát külön küldi a szerver vagy kliens a darab előtt. Transfer-Encoding: chunked Warning Ha a kérés vagy válasz más transzformációkon is átment mint az esetleg elvártak, akkor ez jelezhető a fejlécben, elküldvén a figyelmeztetés kódját egy egy kis szöveget: Warning: 214 Transformation applied A kérés fejlécei Host A Host fejlécet a kérés kötelezően kell tartalmazza. Ez azért van, 8
mert egy gépen (amelynek IP címét a kérés tartalmazza) több webcím is lehet, más és más domain (terület) vagy al-domain-re épülve. Ezért a domain rendszerbeli nevet explicit meg kell adni. Pl.: Host: www.ms.sapientia.ro Authorization Ha hitelesítést kér a szerver a klienstől, akkor az első kérés után ezt a választ küldi: HTTP/1.1 401 Authorization Required Date: Thu, 02 Apr 2009 08:19:10 GMT Server: Apache WWW-Authenticate: Basic realm="weblab" A kliens pedig így küldi a a belépéshez szükséges információt: Authorization: Basic d2vibgfiondlcgxhca== If-Modified-Since Elküld egy dátumot, és csak akkor kéri a dokumentumot, ha módosult a dátum óta. Ez tulajdonképpen egy feltételes GET kérés. Ha a kliens az alábbi kérést küldi: If-Modified-Since Tue, 31 Mar 2009 21:57:52 GMT csak akkor kap dokumentumot válaszként, ha az módosult a küldött dátum óta. Egyébként csak egy válasz kódot kap: 304 Not modified. Referer Annak az oldalnak a webcímét tartalmazza, ahonnan a kérés jött (általában ahol a linkre kattintottak). A Referer szót hibásan kell írni, egy r-el: Referer: http://ms.sapientia.ro/felveteli.html Accept Az Accept fejléc a HTTP tartalom kiválasztására vonatkozik, a kliens elküldi, hogy milyen MIME típusú dokumentumokat fogad el. Accept: text/xml; q=1.0; mxb=10000 Accept: text/html; q=0.9 Accept: text/plain; q=0.8 A fenti 3 sor küldése ezt jelenti: küldd a dokumentumot xml formátumban, ha nem nagyobb mint 10000 byte. Egyébként inkább küldj html-t, ha nem lehet akkor sima szöveget. A q paraméterrel a preferált típust jelzi a kliens, a szám 0 és 1 közti. Accept-Charset Azokat a karakterkészleteket jelöli, amelyeket a kliens elfogad.pl.: 9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding Azokat a kódolási módokat jelöli, amelyeket a kliens elfogad. A dokumentumokat lehet sűrítve is küldeni. Accept-Encoding: gzip,deflate Cookie Sütit (cookie) küld a kliens, jelezvén, hogy beállította a szerver által kiküldött sütit (lásd alább a süti definícióját). Cookie: PHPSESSID=oqbdq22cbme9i5chdjbmfld401 User-Agent A kliens a szoftver nevét, verzióját ebben a fejlécben küldi. Ennek függvényében a szerver módosíthatja a kiküldött oldalt (pl. mást küld Internet Explorer-nek minf Firefox-nak). User-Agent: Mozilla/4.0 (Windows NT 4.0) A válasz fejlécei Location Egy URL-t küld a szerver, jelezvén, hogy erre kell a kliensnek navigálnia, ha folytatni akarja a böngészést. átirányításokat tudunk ezzel végezni, pl.: Location: http://www.google.com fejléc hatására a kliens kiküld egy második kérést és a Google oldalára ugrik. Server A szerver saját leírását küldi ezzel. Server: Apache WWW-Authenticate Amint említettük ezzel a fejléccel kér egyszerű hitelesítést a szerver: HTTP/1.1 401 Authorization Required Date: Thu, 02 Apr 2009 08:19:10 GMT Server: Apache WWW-Authenticate: Basic realm="weblab" Retry-After Set-Cookie Egy időpontot küld ezzel a szerver, amely után ismét próbálkozhat a kliens: a kért dokumentum nem lesz kiszolgálva. Sütit állít be a szerver: Set-Cookie teszt=szingli; expires=thu, 02-Apr- 2009 16:34:41 GMT 10
Entitás fejlécek Allow Ezek kimondottan a küldött dokumentumra vonatkoznak, és un. meta információkat tartalmaznak. Ha egy tatalomhoz nem lehet hozzáférni bizonyos HTTP kéréssel, akkor a szerver jelzi, hogy melyikkel lehet. Ilyenkor a válaszban 405- ös hibakódot küldd a szerver, és jelzi, hogy milyen kéréssel lehet majd elérni a dokumentumot: Allow: GET, HEAD Content-* sorok A Content-Encoding, Content-Length, Content-Type, Content-Location, Content-Language, Content-MD5 fejlécek a tartalom kódolását, hosszát, helyét (ha más URL-en van), nyelvét illetve MD5 hash kódját jelzik: Content-Length: 384 Content-Type: text/html; charset=utf-8 Content-Language: hu Expires Last-Modified: Ezzel a fejléccel egy időpontot küldenek el, amelyben a tartalom érvényességi ideje van. Ez a fejléc jelzi, mikor módosult utoljára a dokumentum: Last-Modified: Tue, 31 Mar 2009 21:57:52 GMT Etag Egy kódot küldd a szerver amivel a tartalom összehasonlítható az előzőleg küldött változattal. Ha a tartalom változott, a hozzárendelt Etag érték is változik: Etag: "50f45-180-466714a603800" Fontos: programozás során a fejléceket kötelezően a HTML oldal szövege előtt kell kiküldeni. 1.6. A HTTP status kódok A szerver a válasz első sorában egy kódot küldd a kérés sikerére vonatkozóan: HTTP/1.1 200 OK A status kódok 3 számjegyből állnak (a példában a 200 a jól lefutott kérést jellemzi). A kód első számjegye a kérés lefutásának kategóriáját tartalmazza, az alábbiak szerint: 1-el kezdődőek, információt adnak a kérés kezelésének módosításáról: 11
100 Continue / A kliens folytathatja a kérést 101 Switching Protocols / a kliens kérésére protokollt cserél 2-vel kezdődőek: a kérést sikeresen kiszolgálta a szerver: 200 OK / sikeres kérés 3-al kezdődőek: Átirányítás: további lépések szükségesek a kérés befejezéséhez pl.: 301 Moved Permanently / a kért lap elköltözött egy más címre, ezt a szerver a Location fejlécben küldi 4-el kezdődőek: kliens hiba, a kérés hibás szintaxist vagy paramétereket tartalmaz, pl.: 408 Request Time-out / a kliens nem küldött kérést annyi idő alatt mennyit a szerver szánt annak várására 5-el kezdődőek: hiba lépett fel a szerveren kiszolgálás közben.ez azt jelenti dinamikus lapoknál, hogy a program amely kiszolgálta a kérést hibába futott: 500 Internal Server Error / hiba történt egy szerver oldali programban 1.7. A web szerver CGI változói Miközben a webszerver a kiszolgáló programot futtatja egy sor változót állít elő, amelyek a kiszolgálást jellemzik. Ezeket átadja annak a programnak is amely a kiszolgálást végzi. A változókat klasszikus CGI változóknak nevezzük, mert a CGI (Common Gateway Interface) nevű programozási specifikációban jelentek meg először. Bármely programozási környezet előállítja őket. A Java szervletek esetében a HttpRequest típusú objektumok (pl. a szervletekben a request) függvényeivel hívhatók le. Ezek a változók sztring név-érték párok. Például egy klasszikus CGI környezetben az egyik változó neve: REMOTE_HOST és ez a kliens gép nevét vagy IP címét tartalmazza. Java-ban, amennyiben a request a kérést ábrázoló objektum egy szervletben, akkor a: String s = reguest.getremotehost (); függvénnyel kapjuk meg értékét. Alább megadunk egy táblázatot a web szerver fontosabb változóival, amelyek nem Java specifikusak, de előállnak Java szervletek kiszolgálásánál is. Változó neve Példa az értékére Mit tartalmaz HTTP_HOST HTTP_USER_AGENT HTTP_ACCEPT localhost Mozilla/5.0 (X11; U; Linux i686; en-us; rv:1.6) Gecko/20040113 text/xml,application/xml,ap plication/xhtml+xml,text/ht A HTTP szervert futtató gép neve A böngésző adatai A Http-Accept fejléc sor értéke 12
HTTP_ACCEPT_LANGUAGE HTTP_ACCEPT_ENCODING HTTP_ACCEPT_CHARSET HTTP_KEEP_ALIVE 300 HTTP_CONNECTION ml;q=0.9,text/plain;q=0.8,i mage/png,image/jpeg,image/g if;q=0.2,*/*;q=0.1 en-us,en;q=0.5 gzip,deflate ISO-8859-1,utf- 8;q=0.7,*;q=0.7 keep-alive A Http-Accept-language értéke A Http-Accept-encoding értéke(fogad e tömörített adatokat a böngésző) Milyen karakterkészletet fogad el Menny ideig maradjon életben a TCP kapcsolat (sec) Maradjon életben a TCP kapcsolat HTTP_CACHE_CONTROL max-age=0 A Cache-Control fejléc értéke PATH / sbin:/usr/sbin:/bin:/usr/bi n:/usr/x11r6/bin SERVER_SIGNATURE Apache/2.0.40 Server at localhost Port 80 A szerver aláírás sztringje SERVER_SOFTWARE Apache/2.0.40 (Red Hat Linux) A szerveren futó szoftver SERVER_NAME localhost A szerver domain neve SERVER_ADDR 127.0.0.1 A webszerver gép neve vagy címe SERVER_PORT 80 A használt TCP port REMOTE_ADDR 127.0.0.1 A kliens gép címe DOCUMENT_ROOT /var/www/html A szerver html dokumentumainak könyvtára SERVER_ADMIN root@localhost REMOTE_PORT 32820 A böngésző port címe GATEWAY_INTERFACE CGI/1.1 Az interfész SERVER_PROTOCOL HTTP/1.1 A használt protokoll verzió REQUEST_METHOD GET A kérés metódusa QUERY_STRING /?a=2&b=3 A kérés URL-ben küldött paraméterei 1.8. A sütik (Cookie) A HTTP protokoll un. állapot nélküli protokoll: a kérés után a TCP kapcsolat megszakad. A protokoll önmagában nem tudja követni az egymás utáni kérések folytonosságát egy adott böngészőtől. A szerver ha ugyanazon weblapra egymás után több kliens gépről kap kérést, nehezen tudja követni, hogy melyik gép hanyadszor ad le kérést, és hogy az előzőekben mit csinált, ha kimondottan a HTTP protokoll adataira támaszkodik. Ezért a protokollt kiegészítettek, a javaslatot először a Netscape készítette, a mai specifikációt az IETF adta ki (RFC 2965). 13
A HTTP kiegészítője egy fejléc információ, amelyet cookie-nak, vagy magyarul sütinek nevezünk. Ez egy név-érték pár, amit a szerver válasza állít be, és a kliens programok kis állomány formában eltárolhatnak. Ha a beállítás érvényben van, akkor a HTTP kérés folyamán a kliens visszaküldi a szervernek. Ezt követve, a szerver pontosan el tudja dönteni, melyik klienstől kapta az éppen kiszolgált választ. A süti beállítása és kliens általi visszaküldése is a HTTP fejlécekben történik. A süti a név-érték pár mellett még tartalmaz néhány mezőt, amelyek érvényességét határozzák meg. Az alábbi mezőkből épül fel: név=érték Mező expires=dátum Mit tartalmaz egy nevet és egy hozzárendelt sztringet tartalmaz mint érték. A sztring hossza nem lehet nagyobb mint 4000 karakter és amennyiben szóköz, vessző vagy pontosvessző karaktereket tartalmaz, URL kódolt formában kell közlekednie. Ez az egyetlen kötelező mező a süti beállításakor. a dátum egy időbélyeget tartalmaz az alábbi formában: Wdy, DD-Mon-YYYY HH:MM:SS GMT ez határozza meg mikor jár le a süti élettartama. -Ha hiányzik, a süti akkor jár le, amikor a felhasználó lezárja a böngészőt. -Ha negatív időt tartalmaz (a HTTP válasz időpontja idő előttit) akkora böngésző törli a sütit ha az előzőleg be volt állítva -a legtávolabbi beállítható élettartam jelenleg 2038 január 1. domain=tartománynév path=útvonal Az a tartománynév amelyre a süti érvényes. Pl.: ms.sapientia.ro A böngésző akkor fogja a sütit visszaküldeni, ha erre a tartománynévre szól a HTTP kérés. Egy tartomány csak a saját maga és al-tartományai számára állíthat be sütiket. Azt az útvonalat tartalmazza a tartományon belül, amelyre a süti érvényes. Pl. a '/' a legáltalánosabb útvonal. A '/abc' pedig érvényes az alábbi útvonalakra: '/abc.html', '/abc/def' secure Ha az utolsó mező létezik és értéke secure, akkor a sütit csak titkosított kapcsolaton lehet átküldeni, azaz HTTPS protokollon keresztül. Konkrétan, amikor a a fejlécekben közlekedik a süti így néz ki: 14
1. A szerver a válasz fejlécben beállít egy sütit: Set-Cookie beta=zold; expires=thu, 02-Apr-2009 18:18:15 GMT; path=/~lszabo 2. A kliens ennyit küld vissza a kérés fejléceként, ha a süti érvényes: Cookie beta=zold A sütik igen fontos kiegészítői a HTTP protokollnak. Mivel általuk egy változót tárolhatunk a kliens gépeken, és ezt visszakaphatjuk akkor is, ha a kliens felhasználó lezárta számítógépét és újraindította, sok alkalmazás vezérlő szekvencia valósítható meg velük. Gyakorlatként a cookie.php programot hívogatva nézhetjük meg, hogyan működik a süti beállítás. Használat: cookie.php?do=delete cookie.php?do=set&name=nev&value=ertek cookie.php?do=show minden sütit töröl beállít egy sütit kijelzi a beállítottat A sütik legfontosabb alkalmazása a HTTP szesszió kezelés, amelyet jelenleg minden programozási környezet automatikusan kezel. 15