Adatok átadása az ASP-ben
HTTP kérés – a Request objektum

Adatküldés a HTTP protokoll segítségével
A dinamizmus, az interaktivitás egyik mozgatórugója természetesen az, ha menet közben adatokat kapunk az ügyfél oldaláról. Ezeket az adatokat a Request objektum segítségével érhetjük el.

Adatok átadása az URL-ben (QueryString)
A klasszikus adatbeviteli módszer, amikor az adatokat a kérés URL-jéhez csatoljuk, ilymódon:

http://localhost/qs.asp?input1=val1&input2=val2

Ekkor ilyen HTTP kérés indul a kiszolgáló felé:

GET /request.asp?input1=value1&input2=value2&submit=Submit HTTP/1.1

Ennek a módszernek több hátránya is van: egyrészt, a bemenő adatok növelik az URL hosszát, a kiszolgálónak elküldhető URL-ek mérete pedig biztonsági okokból általában korlátozva van. (Próbáljunk meg az IIS-nek elküldeni egy többszáz bájt hosszú címet! – A válasz szabványos HTTP hibaüzenet: “404 – Request – URI too long"). Másrészt nemcsak kényelmetlen, de nem is igazán biztonságos, hogy az átadott adatok (amelyeket esetleg nem is mi írtunk be, hanem mondjuk egy kérdőív rejtett részei voltak) megjelennek a böngésző címsorában. Az átadott adatmezők név=adat formájúak (ld. fent: input1=val1), az egyes adatmezőket & jel választja el egymástól, az egészet pedig kérdőjel a fájlnévtől. Egy adott mező értékét a Request.QueryString(“mezőnév“) függvény adja vissza. Ha az adatok között ilyen mező nem szerepel, a visszaadott érték (““).

Lássunk egy példát:

<%
If Len( Request.QueryString("nev") ) Then
Response.Write( "Szia " & Request.QueryString("nev") & "!" )
End If
%>

Ha nevünket megadjuk az URL-ben (pl. request.asp?nev=kati), akkor az oldal köszönt minket. Egy mező “meglétét“ a legegyszerűbben úgy ellenőrizhetjük, ha lekérdezzük a hosszát (ezt teszi a Len() függvény a példában). Ha ez nem 0, lehet dolgozni. Egy mezőnek azonban nem csak egy értéke lehet, a HTTP kérésben egy mezőnév egynél többször is szerepelhet:

http://localhost/qs2.asp?nev=Piroska&nev=Farkas

Ezt az alábbi módon lehet feldolgozni:

<%
Response.Write("Nevek száma: " & Request.QueryString("nev").Count & "<br>")
For i=1 To Request.QueryString("nev").Count
Response.Write( i & ": " & Request.QueryString("nev")(i) & "<br>")
Next
%>

A Request.QueryString(“mezőnév“).Count érték visszaadja az adott nevű mezők számát. Ha a sok közül egy konkrét értékre vagyunk kíváncsiak, akkor átadhatjuk az indexet is (a számozás 1-től kezdődik). Maradjunk a fenti példánál, a Farkas-ra így hivatkozhatunk:

Request.QueryString("nev")(2)

Ha egy mezőnek több értéke van, és mi mégis közvetlenül kérdezzük le (pl. Request.QueryString(“nev")), akkor az értékek vesszővel elválasztott listáját kapjuk válaszként: “Piroska, Farkas“. Ha pedig egyszerűen csak Request.QueryString-re hivatkozunk, akkor visszakapjuk a teljes kérdést:

“nev=Piroska&nev=Farkas“.

Ez volt tehát az URL-be ágyazott lekérdezés feldolgozása. Fontos azonban még megemlíteni, hogy az URL-ek formátuma kötött, és mivel a lekérdezés (és főleg az átadott adatok) ilyenkor az URL részét képezik, ezeknek az adatoknak is meg kell felelniük bizonyos szabályoknak: például, minden írásjel, illetve ékezetes karakter, csakis kódolt formában (pl. egyenlőségjel: %3D) szerepelhet az URL-ben. Ez a kódolás pedig sokszor körülményes és kényelmetlen.

Adatfeltöltés a POST HTTP paranccsal

Szerencsére a HTTP protokoll tartalmaz egy, a fentinél fejlettebb megoldást is. A POST parancs használata esetén a feltöltendő adatok a HTTP üzenet törzsrészébe kerülnek. Az adatok kódolását persze így sem ússzuk meg, de az esetek többségében ezt a munkát nem mi, hanem a böngésző végzi. Kérdőív (Form) kitöltése esetén például, ha a FORM elem method attribútumát postra állítottuk, a következő kérés indul a kiszolgáló felé:

POST /request.asp HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 41
Connection: Keep-Alive
input1=value1&input2=value2&submit=Submit

Láthatjuk, hogy a kiszolgálónak szánt adatok nem a POST parancs paraméterében, hanem a HTTP üzenet törzsrészében utaznak. Érdemes megfigyelni a törzs kódolására vonatkozó Content-Type HTTP fejléc értékét is.

A HTML kérdőív elemének (FORM) method attribútuma határozza meg az adatok küldésének módját. Ha method attribútum értéke “get“, a kérdőív tartalmát az URLbe ágyazva, ha viszont az attribútum értéke “post“, akkor HTTP kérés törzsében küldi el a böngésző a kiszolgálónak. Lehetőség szerint használjuk tehát a post módot!

A kérdőív egyes mezőinek értékét a Request.Form kollekció tartalmazza. Az előző példához hasonlóan minden mező értékét lekérdezhetjük, ha a mezőnek több értéke van, akkor itt is használhatjuk a .Count jellemzőt és az indexeket is, pl.:

Request.Form("nev")
Request.Form("nev").Count
Request.Form("nev")(5)

A kérdőív feldolgozása esetén a Submit nyomógomb értéke (felirata) is eljut a kiszolgálóhoz, de ha több ilyen van, akkor csak annak az egynek, amelyikre kattintottunk. Így megtehetjük azt, hogy ha egy kérdőívbe két Submit nyomógombot teszünk:

<INPUT type="submit" name="submit" value="elso">
<INPUT type="submit" name="submit" value="masodik">

A feldolgozás során könnyen megállapítható, melyik Submit gomb lett megnyomva:

<%
If Request.Form("submit") = "elso" Then
’ Első
Else
’ Második
End If
%>

A For Each utasítás segítségével (a többi kollekcióhoz hasonlóan) a .Form kollekció elemeit is kilistázhatjuk:

<%
For Each mezo In Request.Form
‘ a mezo-be a mezonev kerul
Response.Write( "<b>" & mezo & " = </b>" & Request.Form(mezo) & "<br>" )
Next
%>

Egy HTTP válasz – a Response objektum

A Response objektum egy HTTP kérésre adott válasz. A Response objektum legegyszerűbb (és leggyakoribb) alkalmazását már láthattuk korábban: a Response.Write() metódus segítségével állítottuk elő az oldal tartalmát. A Write() használata egyszerű: minden, amit paraméterként átadunk neki, bekerül a válaszként visszaküldött adatcsomagba. A Write() metódusról egyetlen dolgot kell tudni: a kiírt szöveg nem tartalmazhatja a %> jelsorozatot, helyette ezt kell írni: %\> Az ezt tartalmazó szöveget IIS automatikusan visszaalakítja majd az eredeti formára.
A válaszpuffer

Az .asp oldal előállítása természetesen több lépésben történik, az oldalban található scripttől függően előfordulhat az is, hogy az oldal tartalmának egy része csak bizonyos várakozási idő után áll rendelkezésre. Ilyenkor dönthetünk, hogy a már kész tartalmat elküldjük-e az ügyfélnek, majd várunk a folytatásra, vagy kivárjuk, amíg a teljes oldal elkészül, és csak a munka legvégén küldjük a komplett választ. Ez utóbbi esetben a “kimenet“ egy pufferbe kerül. A pufferelés az IIS5-ben alapértelmezésben működik, míg az IIS4-ben alapértelmezésben ki van kapcsolva.
A Response objektum segítségével mi magunk is kezelhetjük a puffert: mindenekelőtt, a Response.Buffer property-nek False értéket adva letilthatjuk, True segítségével pedig engedélyezhetjük a puffer használatát. A Clear() metódus kiüríti a puffert (A “külső“ HTML kód is a pufferbe kerül, törléskor az is elveszik!), a Flush() pedig elküldi azt, ami addig a pufferbe került, majd csak azután törli a tartalmát. Az oldal feldolgozását bármikor megszakíthatjuk a Response.End() meghívásával. Ha az oldal végrehajtása befejeződik, természetesen a puffer teljes tartalma az ügyfélhez kerül.

Cookie

A cookie kis adatcsomag, amit a kiszolgáló kérésére a böngésző az ügyfél számítógépén tárol, és szükség esetén visszaküldi azt. Alapjában véve két különböző típusú cookie létezik: az első típus csak addig “él“, amíg a böngészővel egy kiszolgálónál tartózkodunk. A böngésző bezárásával az ilyen cookie tartalma elveszik. Ezeket a cookie-kat elsősorban átmeneti célra használjuk (például az ASP Session fenntartására). A másik fajta, felhasználói szemmel gyakrabban megfigyelt cookie annyiban különbözik az előzőtől, hogy a böngésző bezárásakor nem veszik el, hanem a számítógép lemezére kerül. Az ilyen cookie-knak érvényességi idejük van. Amíg ez az érvényességi idő le nem jár, addig a böngésző megőrzi az értéküket, és tartalmukat minden egyes látogatáskor visszaküldi a kiszolgálónak. A két cookie-fajtát csak a lejárati idő különbözteti meg egymástól. Lássuk tehát, hogyan küldhetünk egyszerű, átmeneti célra használható cookie-t a böngészőnek:

<%
Response.Cookies("nev") = "ertek"
%>

Ha a felhasználó legközelebb felénk jár, ezt az adatot így olvashatjuk ki:

<%
s = Request.Cookies("nev")
%>

Egy cookie nem csak egy szöveget tartalmazhat, hanem többet is, egyfajta táblázatot, almezőket:

<%
Response.Cookies("nev")("mezo1") = "ertek1"
Response.Cookies("nev")("mezo2") = "ertek2"
%>

A .HasKeys metódus segítségével eldönthetjük, hogy egy cookie egyszerű szöveg, vagy almezők gyűjteménye, és ettől függően kezelhetjük is:

<%
If Request.Cookies("nev").HasKeys Then
For Each mezo In Request.Cookies("nev")
Response.Write( Request.Cookies("nev")(mezo))
Next
Else
Response.Write( Request.Cookies("nev") )
End If
%>

A .HasKeys elérhető a Response objektumon keresztül is. Erre azért van szükség, mert ha egy szöveges típusú cookieban almezőket hozunk létre, elveszik a szöveges érték – és fordítva, ha almezőkkel rendelkező cookie-nak szöveges értéket adnánk, elvesznének az almezők és azok értékei. A cookie érvényességét a Response objektum segítségével korlátozhatjuk időben és “térben“:

<%
Response.Cookies("nev").Expires = "01-Jan-2003"
Response.Cookies("nev").Domain = "www.domain.net"
Response.Cookies("nev").Path = "/dir1/dir2"
%>

Az .Expires jellemző értéke határozza meg, hogy az cookie meddig marad életben. Ha nem adjuk meg, a böngésző lezárásakor elveszik.
A .Domain jellemző segítségével beállíthatjuk, hogy a böngésző milyen domainek elérése esetén küldje vissza a cookie-t.
A .Path pedig kiszolgálón belüli részletezést jelent: ha két azonos nevű cookie létezik, ugyanarra a domain-re, akkor annak az értékét fogjuk visszakapni, ahol a .Path értéke közelebb van a valósághoz. Ha tehát az oldal a /dir1/dir2 könyvtárak mélyén található, a két cookie .Path értéke pedig a /dir1 és a /dir1/dir2, akkor az utóbbit fogjuk viszontlátni.
Ha azt szeretnénk, hogy egy cookie az adott pillanattól számított egy évig legyen érvényes, használjuk a DateAdd() és a Now függvényt:

<%
Response.Cookies("egyevigjo").Expires = DateAdd( "yyyy", 1, Now)
%>

 

Összeállította:

Ajánlott felbontás:
800 x 600