A HTTP protokoll. A standard egy URI (Unified Resource Identifier = egységes forrás azonosító) megnevezésű címet definiál, amely lehet:

Sapientia Egyetem, Marosvásárhely, SzLZs

Webtechnológia előadás, 2009/10-II. félév

A HTTP protokoll Tartalom 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>@:<port>/

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>@:<port>/?#

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: Itt a bekezdés.

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 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. Típusok

Altípusok

Text

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

Altípusok

Multipart

Csak az email-ekben használják, több különböző adattípusból összeálló szerkezet

Message

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

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.

POST

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.

PUT

A küldött dokumentum a szerveren lesz tárolva, tulajdonképpen a metódus "felírja" a szerverre a dokumentumot.

DELETE

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 Teszt dokumentum
Cim

Elso paragrafus

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:

Accept

http://ms.sapientia.ro/felveteli.html

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

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.

Set-Cookie

Sütit állít be a szerver: Set-Cookie teszt=szingli; expires=Thu, 02-Apr2009 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

Ezzel a fejléccel egy időpontot küldenek el, amelyben a tartalom érvényességi ideje van.

Last-Modified:

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 101


Continue / A kliens folytathatja a kérést 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

HTTP_HOST

localhost

HTTP_USER_AGENT HTTP_ACCEPT

Mit tartalmaz A HTTP szervert futtató gép neve

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) A böngésző adatai Gecko/20040113 text/xml,application/xml,ap A Http-Accept fejléc sor értéke plication/xhtml+xml,text/ht

12



ml;q=0.9,text/plain;q=0.8,i mage/png,image/jpeg,image/g if;q=0.2,*/*;q=0.1 HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5 HTTP_ACCEPT_ENCODING gzip,deflate

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 A Cache-Control fejléc értéke

HTTP_ACCEPT_CHARSET

ISO-8859-1,utf8;q=0.7,*;q=0.7

HTTP_KEEP_ALIVE

300

HTTP_CONNECTION

keep-alive

HTTP_CACHE_CONTROL

SERVER_ADMIN

max-age=0 / sbin:/usr/sbin:/bin:/usr/bi n:/usr/X11R6/bin Apache/2.0.40 Server at A szerver aláírás sztringje localhost Port 80 Apache/2.0.40 (Red Hat A szerveren futó szoftver Linux) localhost A szerver domain neve A webszerver gép neve vagy 127.0.0.1 címe 80 A használt TCP port 127.0.0.1 A kliens gép címe A szerver html /var/www/html dokumentumainak könyvtára root@localhost

REMOTE_PORT GATEWAY_INTERFACE SERVER_PROTOCOL REQUEST_METHOD

32820 CGI/1.1 HTTP/1.1 GET

QUERY_STRING

/?a=2&b=3

PATH SERVER_SIGNATURE SERVER_SOFTWARE SERVER_NAME SERVER_ADDR SERVER_PORT REMOTE_ADDR DOCUMENT_ROOT

A böngésző port címe Az interfész A használt protokoll verzió A kérés metódusa 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: Mező

Mit tartalmaz

név=érték

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.

expires=dátum

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 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. path=útvonal

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

A HTTP protokoll. A standard egy URI (Unified Resource Identifier = egységes forrás azonosító) megnevezésű címet definiál, amely lehet:

Recommend Documents

Cim