Ez és a következő szakaszok röviden bemutatják, hogyan lehet alapvető webalkalmazásokat létrehozni PHP használatával. A részben tárgyaltak nyilvánvalóan nem elegendőek ahhoz, hogy az alkalmazás kommunikáljon a felhasználóval, és az általa végrehajtott műveletek vagy a megadott paraméterek függvényében fogalmazzon. Mi hiányzik? Nem áll rendelkezésre elegendő tudás a felhasználói adatok bevitelének megszervezésére és ezen adatok szerverre történő továbbítására vonatkozóan. Nos, már rendelkeznie kell alapvető ismeretekkel arról, hogyan kell programozottan feldolgozni a szerveren kapott információkat.

HTTP kérési metódusok és paramétereik

Bármely dinamikus webalkalmazás választ generál a felhasználónak az általa megadott paraméterek vagy a kliens oldalon végzett műveletek szerint. A szerverrel való kapcsolatfelvétel leggyakrabban két típusú kérésből fakad: a GET metódus vagy a POST metódus használatával. Néhány szó a két kéréstípus közötti különbségekről.

GET módszer:

A paraméterek a HTTP-kérés fejlécében kerülnek elküldésre, így láthatók benne parancssor, és egy ilyen kérés elmenthető a könyvjelzők közé. Mivel a fejléc teljes hossza korlátozott, a GET segítségével átadott paraméterek száma és hossza is korlátozott.

Úgy gondolják, hogy több, egymás után végrehajtott azonos GET-kérés eredményének meg kell egyeznie.

POST módszer:

A kérésparaméterek a HTTP-kérés törzsében kerülnek átadásra, így nem jelennek meg a parancssorban. A paraméterek száma és mérete korlátlan.

Úgy gondolják, hogy több azonos POST kérés eredménye eltérő értékeket ad vissza, mivel megváltoztathatja a célobjektum tulajdonságait.

A GET metódussal egy információs erőforrás tartalmát paraméterek szerint kell lekérni, ha nincs szükség a célerőforrás adatstruktúráinak módosítására, és célszerű a kérést (URL) könyvjelzőkbe menteni. A GET metódus gyorsabban tud teljesíteni, mint a POST metódus használatával végzett hasonló kérések.

A POST metódust akkor kell használni, ha el kell rejtenie a szervernek átadott paramétereket az URL elől. Ezt a módszert kell használni a cél erőforrás tartalmának módosítására irányuló kérésekben is, átadva a paraméterekben a változások leírását (a kérelem törzsében).

Az erőforrás elérési útja?parameter1=value1¶meter2=value2&…

Ha nem rendelkezik speciális HTML űrlappal a paraméterek kitöltéséhez, akkor a PHP-alkalmazás hibakeresését úgy végezheti el, hogy a tesztparamétereket közvetlenül a böngésző parancssorában adja át, például:

Http://site/php-samples/sql.php?sql=select * innen: d_staff

A kérésparaméterek szerveroldali eléréséhez globális tömböket kell használnia $_GETÉs $_POST illetőleg. Ha az alkalmazásnak nem mindegy, hogy melyik metódussal éri el, akkor tömböt kell használnia $_REQUEST, amely egyesíti a $_GET és $_POST tömbök adatait, például így:

$sql = isset($_REQUEST["sql"]) ? $_REQUEST["sql"] : "";

Ebben a példában a program meghatározza, hogy az „sql” paramétert átadták-e: ha igen, akkor hozzárendeli az értékét a megfelelő változóhoz, ha nem, akkor üres értéket ad neki.

HTTP kérési paraméterek meghatározása HTML űrlapon keresztül

Természetesen a paraméterek manuális meghatározása közvetlenül a böngésző parancssorában nem túl kényelmes. Ez a módszer alkalmas HTTP kérések programozott végrehajtására, amikor a webalkalmazások kommunikálnak egymással. A kliens oldalon történő kezdeti adatellenőrzés megadásához és végrehajtásához HTML űrlapokat és . Alább egy példa legegyszerűbb formája, amellyel egy szöveges paramétert (értéket) adunk meg, amely ezt követően a POST metódus paramétereként kerül átadásra a szervernek.

módszer ="bejegyzés" akció =’sql.php’ > SQL:
<b>név</b> </u>="sql" cols="100" rows="8">

A form elem method attribútuma azt a metódust adja meg, amely meghatározza az adatok kiszolgálóra való továbbításának módját (get vagy post). Az action attribútum határozza meg php fájl , amely feldolgozza a kérést. Ha a kezelő az aktuális fájl, akkor az action attribútumot nem kell hozzáadni. Minden olyan elemnél, amelynek értékét HTTP-kérési paraméterként kell átadni, meg kell határoznia egy egyedi értéket a name attribútumhoz. Ez az attribútum értéke név lesz index a $_GET, $_POST vagy $_REQUEST tömbökben (lásd a fenti példát). Egy gomb megnyomása benyújtani elküldi az űrlapot az összes megadott értékkel a szervernek.

A PHP POST kérés végrehajtásának első módja a file_get_contents használata. A második módszer a freadet néhány más funkcióval kombinálva fogja használni. Mindkét lehetőség a stream_context_create függvényt használja a kérésfejléc szükséges mezőinek kitöltéséhez.

Kód magyarázata

A $sPD változó tartalmazza az átvinni kívánt adatokat. HTTP kérési karakterlánc formátumban kell lennie, ezért néhány speciális karaktert kódolni kell.

Mind a file_get_contents függvényben, mind a fread függvényben két új paraméterünk van. Az első a use_include_path . Mivel HTTP kérést küldünk, az mindkét példában hamis lesz. Ha igaz értékre van állítva egy helyi erőforrás olvasásához, a függvény az include_path címen keresi a fájlt.

A második paraméter a kontextus, amely a stream_context_create visszatérési értékével van feltöltve, amely az $aHTTP tömb értékét veszi fel.

A file_get_contents használata POST-kérésekhez

Ha POST kérést szeretne küldeni a file_get_contents használatával PHP-ben, a stream_context_create segítségével kézzel kell kitöltenie a fejlécmezőket, és meg kell adnia, hogy melyik „burkolót” használja - ebben az esetben HTTP:

$sURL = "http://brugbart.com/Példák/http-post.php"; // POST URL $sPD = "name=Jacob&bench=150"; // POST adatok $aHTTP = array("http" => // Használandó burkoló array("method" => "POST", // Kérési metódus // A kérés fejlécei a "header" alatt vannak beállítva => "Tartalom - típus: application/x-www-form-urlencoded", "content" => $sPD)); $kontextus = stream_context_create($aHTTP); $contents = file_get_contents($sURL, false, $kontextus); echo $tartalom;

Fread használata POST kérések végrehajtására

A fread funkció segítségével POST kéréseket küldhet. A következő példa a stream_context_create paramétert használja a szükséges HTTP-kérelem fejlécek összeállításához:

$sURL = "http://brugbart.com/Példák/http-post.php"; // POST URL $sPD = "name=Jacob&bench=150"; // POST adatok $aHTTP = array("http" => // Használandó burkoló array("method" => "POST", // Request Method // A kérés fejlécei a "header" alatt vannak beállítva => "Tartalom - típus: application/x-www-form-urlencoded", "content" => $sPD)); $kontextus = stream_context_create($aHTTP); $handle = fopen($sURL, "r", false, $kontextus); $contents = ""; while (!feof($handle)) ( $contents .= fread($handle, 8192); ) fclose($handle); echo $tartalom;

GET kérések készítése PHP-vel

Most a fread és file_get_contents használatával fogunk összpontosítani tartalmak letöltésére az internetről HTTP-n és HTTPS-en keresztül. A cikkben leírt módszerek használatához engedélyeznie kell az fopen wrappers opciót. Ehhez a php.ini fájlban az allow_url_fopen paramétert On értékre kell állítani.

A PHP-ben a POST és GET kérések végrehajtása a webhelyekre való bejelentkezésre, a weboldal tartalmának lekérésére vagy az alkalmazások új verzióinak ellenőrzésére szolgál. Megmutatjuk, hogyan lehet egyszerű HTTP kéréseket készíteni.

Fread használata fájlok letöltésére vagy fogadására az interneten keresztül

Ne feledje, hogy a weboldalak olvasása a csomag elérhető részére korlátozódik. Tehát a stream_get_contents ( hasonló a file_get_contents-hez) vagy egy while ciklus a tartalom kisebb darabokban történő olvasásához, amíg el nem éri a fájl végét:

PHP POST kérés feldolgozása esetén a fread függvény utolsó argumentuma megegyezik a töredék méretével. Általában nem lehet nagyobb 8192-nél ( 8*1024 ).

Közös bennük, hogy ugyanúgy működnek. Technikailag nincs különbség köztük. De vannak ideológiai különbségek.

Beszélek róluk a PHP kontextusában. Kérjük, vegye figyelembe, hogy a HTTP protokoll közvetetten kapcsolódik a PHP-hez, mert html oldalak cseréjére készült, és a PHP egyszerűen kibővíti mindkettő képességeit.

A GET kérés az adatok fogadására szolgál, a POST pedig a küldésre. (Ne feledje, hogy technikailag ugyanúgy működnek).

Ezért a PHP kontextusában erre az ideológiára alapozva a következőket tettük:
1. Minden alkalommal, amikor elindítja a PHP-t, alapértelmezés szerint szuperglobális tömbök ($_GET, $_POST) jönnek létre.
2. Ha van egy kérdőjel(?) a lekérdezési karakterláncban. Utána mindent figyelembe kell venni paramétereket GET kérés esetén "kulcs"="érték" formátumban jelennek meg, és az "és" karaktert (&) használják elválasztóként.
Példa:
GET /index.php?name=Andrey&vezetéknév=Galkin
Ez egy lekérdezési karakterlánc, 2 paramétere van. ezek a paraméterek a $_GET tömbbe kerülnek.
3. A $_POST más módon van kitöltve. ennek a tömbnek a tartalma a "kérelem fejlécekből" van kitöltve. Vagyis a szem elől egyértelműen rejtett helyről. A böngésző gondoskodik az ilyen fejlécek létrehozásának minden feladatáról. Bár néha valamit kézzel szerkesztenek a fejlécekben.

Leggyakrabban az űrlapokon (adatok küldésére) használnak feladási kérelmet.

Például van egy bejelentkezési űrlapunk 2 mezővel: bejelentkezési név és jelszó.

Képzeljük el, hogy a GET módszert használjuk. Ezután az űrlap elküldésekor a következő címre megyünk: /login.php?login=Andrey&password=123 Ön elfogadja, hogy az ilyen információk ilyen módon történő továbbítása egyáltalán nem biztonságos. Bárki megnyithatja böngészőjét, és a webhely címének beírását követően láthatja jelszavait és bejelentkezési adatait az előzményekből.

De ha megadnánk a POST módszert, akkor a következő kérést kapnánk:
POST /login.php (login=Andrey&password=123) ami a zárójelben van, az el van rejtve, és semmilyen módon nem kerül mentésre a böngészőben.

Összefoglalva:
A GET egy adott oldal megnyitása egy bizonyos forma(osztályozás, aktuális oldal blog, keresősáv stb.).
POST - olyan adatok küldésére, amelyek nem befolyásolják az oldal megjelenítését, abban az értelemben, hogy ezek az adatok csak a szkript eredményét érintik (bejelentkezések, jelszavak, hitelkártyaszámok, üzenetek stb.).

És még egy jó hír, hogy például kombinálhatók is
POST /index.php?page=login (login=Andrey&password=123) Azt hiszem, már eleget kifejtettem, hogy mi lesz ebből, és melyik paraméterek melyik tömbbe kerülnek.

IN utóbbi időben Egyre gyakrabban látok kérdéseket a PHPClub fő fórumán a POST és GET kérések létrehozásával kapcsolatban, valamint a következő témában: "Hogyan generálhatok POST kérést a fejléc függvény segítségével." Úgy gondolom, hogy szükség van az „i” pont használatára ezt a technológiát, mivel a kezdő programozók egyszerűen nem értik a web alapelveit. Kezdjük tehát utazásunkat a HTTP protokoll világában.

1. HTTP protokoll. Bevezetés

Egy apróságot szeretnék rögtön tisztázni.

A szörnyű szóprotokoll nem más, mint sok ember megállapodása, egy szép pillanatban az emberek úgy döntöttek: "Csináljuk így, és akkor minden rendben lesz." Nincs mitől félni, minden egyszerűen felháborító, és most ezt a gyalázatot fogjuk felfedni. Tehát mi az a HTTP protokoll, és mire használják?

A világon nincsenek csodák, és főleg a programozás és az internet világában!

Fogadd ezt megingathatatlan igazságként. És ha a program nem vagy nem a kívánt módon működik, akkor valószínűleg vagy hibásan van megírva, vagy hibákat tartalmaz. Tehát hogyan kéri a böngésző a szervert, hogy küldjön neki valamit?

Igen, nagyon egyszerű! Csak pihenned kell egy kicsit, és elkezded élvezni a folyamatot :-)

1.2. Első HTTP kérésünk megírása

• Ha úgy gondolja, hogy minden túl bonyolult, akkor téved. Az ember úgy van megtervezve, hogy egyszerűen nem képes bonyolultat alkotni, különben ő maga is belezavarodik :-) Szóval van böngésző és van webszerver.
• Az adatcsere mindig a böngésző kezdeményezője. A webszerver soha nem küld egyszerűen semmit senkinek, hogy elküldjön valamit a böngészőnek – a böngészőnek kérnie kell.
• A legegyszerűbb HTTP-kérés így nézhet ki:
• Szerezze be a http://www.php.net/ HTTP/1.0\r\n\r\n oldalt

GET (angol fordításban „get”) - a kérés típusa eltérő lehet, például POST, HEAD, PUT, DELETE (az alábbiakban néhányat megnézünk). http://www.php.net/ - URI (cím), amelyről legalább néhány információt szeretnénk kapni (természetesen reméljük, hogy megtanuljuk a HTML oldalt). A HTTP/1.0 a protokoll típusa és verziója, amelyet a szerverrel való kommunikáció során használunk.

\r\n a sor vége, amit kétszer kell megismételni, az kicsit később derül ki.

Ezt a kérést nagyon egyszerűen teljesítheti. Futtassa a telnet.exe programot, adja meg gazdagépnek a www.php.net címet, adja meg a 80-as portot, és egyszerűen írja be ezt a kérést az Enter kétszeri megnyomásával \r\n\r\nként. Válaszul HTML kódot kap

kezdőlap www.php.net webhely.

• 1.3 Kérelem szerkezete Nézzük meg, miből áll egy HTTP kérés.

Minden nagyon egyszerű. Kezdjük azzal, hogy a HTTP kérés egy teljesen értelmes szöveg. Miből áll ez általános esetben? Megfontoljuk a HTTP 1.0 protokollt. Így:

• Request-Line[Általános fejléc | Kérelem fejléc | Entitásfejléc ]\r\n[ Entitástörzs ]
• Request-Line- egy relatív vagy abszolút hivatkozás egy oldalra paraméterkészlettel, például /index.html vagy http://www.myhost.ru/index.html vagy /index.html?a=1&b=qq.
• Ez utóbbi esetben a szerver egy kérést küld a és b változókkal a megfelelő értékekkel, és az „&” jel - egy "és" - szolgál elválasztóként a paraméterek között. HTTP-verzió

- a HTTP protokoll verziója, esetünkben "HTTP/1.0".

Nagyon érdekelnek minket a GET és POST feldolgozási módszerek. A GET metódussal egyszerűen átadhatunk paramétereket a szkriptnek, a POST metódussal pedig emulálhatjuk az űrlapküldést. A GET metódus esetében a Request-URI így nézhet ki:

• "/index.html?param1=1¶m2=2". General-Header
  - a cím fő része.
  Formátum:
• Csak két paramétere lehet: Dátum vagy Pragma. Dátum – Greenwich-i dátum a "hét napja, nap hónap év ÓÓ:PP:SS GMT" formátumban, például "Ked, 1994. november 15. 08:12:31 GMT" - a kérelem létrehozásának dátuma. A Pragma egyetlen no-cache értéket is tartalmazhat, ami letiltja az oldal gyorsítótárazását.

  Kérelem fejléc - a fejléc része, amely leírja a kérést..
  A Request-Header a következő paraméterekkel rendelkezhet:

• Engedélyezés, Engedélyezés, Feladó, Ha-Módosítva-Azóta, Hivatkozó, Felhasználói ügynök Ebben a fejezetben nem foglalkozunk az Authorization paraméterrel, mivel ez a privát erőforrások elérésére szolgál, amire nincs túl gyakran szükség.
  A www.w3c.org webhelyen megtudhatja, hogyan hozhat létre saját maga engedélyezett hozzáférési fejlécet.
  Engedélyezze
• - elfogadható feldolgozási módszereket állít be. - Formátum: "Engedélyezés: GET | HEAD\n". A paraméter figyelmen kívül hagyja a POST feldolgozási metódust a Request-Line-ban. Meghatározza az elfogadható kérésfeldolgozási módszereket.
  A proxyszerverek nem módosítják az Allow paramétert, és változatlan formában jut el a szerverhez.
  Tól e-mail címet aki küldte a kérést.
• Formátum: "Feladó: adderss\r\n". Például: „Feladó:
  [e-mail védett]
  \r\n".
• Ha-Módosítva-Azóta- azt jelzi, hogy a kérés ilyen és olyan időpont óta nem módosult.
  Formátum: "If-Modified-Since: date\r\n"
  Csak a GET feldolgozási módszerhez használatos. A dátum GMT-ben van megadva, ugyanolyan formátumban, mint a Dátum paraméternél az Általános fejlécben.
• Hivatkozó- egy abszolút hivatkozás arra az oldalra, amelyről a kérést kezdeményezték, azaz egy hivatkozás arra az oldalra, amelyről a felhasználó a mi oldalunkra érkezett.
  Formátum: "Hivatkozó: url\n".
• Példa: "Hivatkozó: www.host.ru/index.html\n". User-Agent
  A kérelem ezen része az oldal törzsét leíró paramétereket határozza meg. Az entitásfejléc a következő paramétereket tartalmazhatja: Engedélyezés, Tartalom-kódolás, Tartalom-hosszúság, Tartalom-típus, Lejár, Utoljára módosított, bővítmény-fejléc.
• Engedélyezés, Engedélyezés, Feladó, Ha-Módosítva-Azóta, Hivatkozó, Felhasználói ügynök- az Allow from General-Header paraméterhez hasonló paraméter.
• Tartalom-kódolás- Entity-Body adatkódolási típus.
  Formátum: "Tartalomkódolás: x-gzip | x-compress | egyéb típus\n".
  Példa: "Tartalomkódolás: x-gzip\n". A "|" karakter a „vagy” szót jelenti, vagyis ezt vagy azt vagy azt stb.
  Egy másik típus jelezheti az adatok kódolását, például a POST metódushoz: "Content-Encoding: application/x-www-form-urlencoded\n".
• Tartalom-hossz- az Entity-Body-nak küldött bájtok száma. A Content-Length érték teljesen más jelentéssel bír a MIME formátumban küldött adatoknál, ahol az adatok egy részének leírására szolgáló paraméterként szolgál - "external/entity-body".
  Az érvényes számok a nullától kezdődő és a feletti egész számok.
• Példa: "Content-Length: 26457\n". Tartalom-típus
  - a továbbított adatok típusa.
• Például: "Content-Type: text/html\n". Lejár
  - Az az idő, amikor az oldalt el kell távolítani a böngésző gyorsítótárából.
• Formátum: "Lejárat: dátum\n". A dátum formátuma megegyezik az Általános fejléc Dátum paraméterének dátumformátumával. Utoljára módosítva
  - a továbbított adatok utolsó változásának időpontja.
• Formátum: "Utolsó módosítás: dátum\n". A dátum formátuma megegyezik az Általános fejléc Dátum paraméterének dátumformátumával. kiterjesztés-fejléc
  - a fejléc része, amelyet például egy böngésző vagy más, a dokumentumot fogadó program feldolgozására szánhatnak. Ebben a részben a paramétereit a "Paraméternév: paraméterérték\n" formátumban írja le. Ezeket a paramétereket figyelmen kívül hagyja, ha az ügyfélprogram nem tudja, hogyan kell feldolgozni őket.

Például: "Cookie: r=1\r\n" - jól ismert cookie-kat állít be az oldalhoz.

És most, ilyen szörnyű szavak után, próbáljunk meg egy kicsit megnyugodni, és megérteni, mire van szükségünk? Természetesen példákkal megértjük.

Képzeljük el, hogy a Cookie-k átadásával egy oldalt kell lekérnünk az oldalról, különben egyszerűen hívatlan vendégként küldünk el minket, ráadásul köztudott, hogy csak akkor férhet hozzá ehhez az oldalhoz, ha meglátogatta a főoldalt. telek.

2 GET módszer

Írjuk meg kérésünket.
Szerezze be a http://www.site.ru/news.html HTTP/1.0\r\n oldalt

Házigazda: www.site.ru\r\n
Cookie: bevétel=1\r\n

Ez a kérés azt jelzi, hogy a http://www.site.ru/news.html címen található oldal tartalmát a GET módszerrel szeretnénk megszerezni. A Host mező azt jelzi, hogy ez az oldal a www.site.ru szerveren található, a Hivatkozó mező azt jelzi, hogy hírért jöttünk az oldal főoldaláról, a Cookie mező pedig azt, hogy egy ilyen és ehhez hasonló cookie-t rendeltünk hozzánk. Miért olyan fontosak a Host, Referer és Cookie mezők? Mert a normál programozók dinamikus oldalak létrehozásakor ellenőrzik a szkriptekben (beleértve a PHP-t is) változók formájában megjelenő adatmezőket. Ez mire való? Annak érdekében, hogy például megakadályozzák az oldal kirablását, pl.

nem állítottak rá programot az automatikus letöltésre, vagy arra, hogy az oldalra látogató mindig csak a főoldalról jusson el stb.

Most képzeljük el, hogy ki kell töltenünk az oldalon lévő űrlapmezőket, és kérést kell küldenünk az űrlapról, legyen két mező ebben az űrlapban: bejelentkezési név és jelszó (login és jelszó) - és természetesen ismerjük a bejelentkezést és jelszót.
Szerezze be a http://www.site.ru/news.html HTTP/1.0\r\n oldalt
LETÖLTÉS http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Házigazda: www.site.ru\r\n
Cookie: bevétel=1\r\n

Referencia: http://www.site.ru/index.html\r\n A bejelentkezési nevünk "Petya Vasechkin" Miért írjunk Petya%20Vasechkin? Ennek az az oka, hogy a speciális karaktereket a szerver felismerheti új paraméter jelenlétének vagy egy kérés végének stb. jeleként. Ezért van egy algoritmus a paraméternevek és azok értékeinek kódolására a kérésben előforduló hibahelyzetek elkerülése érdekében. Teljes leírás

Ez az algoritmus megtalálható, a PHP-ben pedig a rawurlencode és a rawurldecode függvények kódolására, illetve dekódolására szolgál. Szeretném megjegyezni, hogy a PHP maga végzi el a dekódolást, ha kódolt paramétereket adtak át a kérésben. Ezzel zárom a HTTP protokollal való ismerkedésem első fejezetét. A következő fejezetben olyan építési kéréseket fogunk megvizsgálni, mint például a POST (angolul „küldés”), amelyek sokkal érdekesebbek lesznek, mert Ez az a típusú kérés, amelyet a HTML-űrlapokból történő adatok küldésekor használnak.

3. POST módszer.

3.1 Tartalomtípus: Application/x-www-form-urlencoded.

A GET kérésünkhöz hasonló kérést írunk a bejelentkezési név és jelszó átvitelére, amelyről az előző fejezetben volt szó:

Szerezze be a http://www.site.ru/news.html HTTP/1.0\r\n oldalt
LETÖLTÉS http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Házigazda: www.site.ru\r\n
Tartalom típusa: application/x-www-form-urlencoded\r\n
Tartalom-hossz: 35\r\n
Cookie: bevétel=1\r\n

Itt láthatunk egy példát a Content-Type és Content-Length fejlécmezők használatára. A Content-Length megmondja, hogy az adatterület hány bájtot foglal el, amelyet egy másik sortörés választ el a fejléctől \r\n. De a korábban a GET-kérelem Request-URI-jában elhelyezett paraméterek most az Entity-Body-ban vannak. Látható, hogy ugyanúgy alakulnak, csak a cím után kell írni. Még egy dologra szeretnék rámutatni fontos pont

, semmi sem akadályozza meg, hogy az Entity-Body paraméterkészletével egyidejűleg más nevű paramétereket helyezzen el a Request-URI-ban, például:
.....
Cookie: bevétel=1\r\n
POST http://www.site.ru/news.html?type=user HTTP/1.0\r\n

login=Petya%20Vasechkin&password=qq

3.2 Tartalom típusa: többrészes/űrlapadatok

Amint az internetes világ rájött, hogy jó lenne űrlapokon keresztül fájlokat küldeni, a W3C konzorcium hozzálátott a POST kérés formátumának finomításához. Akkoriban a MIME formátumot (Multipurpose Internet Mail Extensions – többcélú protokollbővítmények e-mail üzenetek generálására) már széles körben használták, ezért, hogy ne találjuk fel újra a kereket, úgy döntöttünk, hogy ennek az üzenetgeneráló formátumnak egy részét használjuk fel az üzenet létrehozására. POST kérések a HTTP protokollban.

Melyek a fő különbségek ez a formátum és az application/x-www-form-urlencoded típus között?

A fő különbség az, hogy az Entity-Body mostantól szakaszokra osztható, amelyeket határok (határ) választanak el. A legérdekesebb az, hogy minden szakasznak saját fejléce lehet, ami leírja a benne tárolt adatokat, pl.

egy kéréssel különféle típusú adatokat vihet át (mint egy levélben, szöveggel egyidejűleg fájlokat is átvihet).
Szerezze be a http://www.site.ru/news.html HTTP/1.0\r\n oldalt
LETÖLTÉS http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Házigazda: www.site.ru\r\n

Tehát kezdjük. Tekintsük újra ugyanazt a példát a bejelentkezési név és a jelszó átvitelével, de most egy új formátumban.
Cookie: bevétel=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Tartalom-hossz: 209\r\n
--1BEF0A57BE110FD467A Tartalom-hossz: 209\r\n
Tartalom-hossz: 209\r\n
\r\n Tartalom-hossz: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Tartalom-hossz: 209\r\n
Tartalom-Dispozíció: forma-adat; name="bejelentkezés" Tartalom-hossz: 209\r\n
Tartalom-hossz: 209\r\n
Petya Vasechkin Tartalom-hossz: 209\r\n
Tartalom-Dispozíció: forma-adat; name="jelszó" Tartalom-hossz: 209\r\n

Most értsük meg, mi van leírva. :-) Külön kiemeltem néhány \r\n karaktert félkövérrel, hogy ne olvadjanak össze az adatokkal. Ha alaposan megnézi, észre fogja venni a határmezőt a Content-Type után. Ez a mező határozza meg a szakaszelválasztót - szegélyt. A latin betűkből és számokból, valamint néhány más szimbólumból (sajnos nem emlékszem, melyikből) álló karakterlánc használható szegélyként. A kérés törzsében a határ elejére „--” kerül, a kérés pedig határvonallal végződik, amelynek végére a „--” karakterek is hozzáadódnak. Kérelmünk két részből áll, az első a bejelentkezési mezőt, a második a jelszó mezőt írja le.

A Content-Disposition (az adattípus a szakaszban) azt mondja, hogy ezek az űrlap adatai lesznek, a név mező pedig a mező nevét adja meg. Itt ér véget a szakasz fejléce, és ezt követi a szakasz adatterülete, amelybe a mező értéke kerül (nem kell kódolni az értéket!).

Szeretném felhívni a figyelmet, hogy a szakaszfejlécekben nem kell Content-Length-t használni, hanem a kérés fejlécében kell és értéke a teljes Entity-Body mérete, ami a második \ után jelenik meg. r\n következő Tartalom-hossz: 209\ r\n. Azok. Az Entity-Body-t egy további sortörés választja el a fejléctől (ami szakaszokban is látható).

Most írjunk egy kérelmet egy fájl átvitelére.
Szerezze be a http://www.site.ru/news.html HTTP/1.0\r\n oldalt
POST http://www.site.ru/postnews.html HTTP/1.0\r\n
Házigazda: www.site.ru\r\n
Hivatkozó: http://www.site.ru/news.html\r\n
Tartalom-típus: többrészes/forma-adatok; boundary=1BEF0A57BE110FD467A\r\n
Cookie: bevétel=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Tartalom-hossz: 209\r\n
Tartalom-hossz: 491\r\n Tartalom-hossz: 209\r\n
Tartalom-hossz: 209\r\n
Tartalom-Dispozíció: forma-adat; name="news_header" Tartalom-hossz: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Tartalom-hossz: 209\r\n
Példa hír Tartalom-hossz: 209\r\n
Tartalom-Dispozíció: forma-adat; name="news_file"; Tartalom-hossz: 209\r\n
filename="news.txt" Tartalom-hossz: 209\r\n
Tartalom-hossz: 209\r\n
Tartalom-típus: alkalmazás/oktett-folyam Tartalom-hossz: 209\r\n
Tartalom-Dispozíció: forma-adat; name="jelszó" Tartalom-hossz: 209\r\n

Tartalom-átvitel-kódolás: bináris

Nagyon fontos szempont. A legtöbb CGI-szkriptet okos emberek írják, ezért szeretik ellenőrizni a bejövő fájl típusát, amely a Content-Type-ban van. Minek? Leggyakrabban a webhelyekre fájlok feltöltését használják arra, hogy képeket kapjanak a látogatótól. Tehát a böngésző maga próbálja meghatározni, hogy a látogató milyen fájlt szeretne küldeni, és beilleszti a megfelelő Content-Type-ot a kérésbe. A szkript átvételkor ellenőrzi, és ha például nem gif vagy jpeg, akkor figyelmen kívül hagyja ezt a fájlt. Ezért a kérés „kézi” létrehozásakor ügyeljen a Content-Type értékre, hogy az a legközelebb legyen az átvitt fájl formátumához.

Példánkban egy kérés jön létre, amelyben szöveges fájl. A bináris fájl átvitelére vonatkozó kérés ugyanígy jön létre.

4. Utóirat.

Azt gondolom, hogy nem érdemes részletesen beszélni a kérések szerver felé küldéséről. Ez tisztán RHP technológia kérdése :-). Elég figyelmesen elolvasni a socketekkel való munkavégzés funkcióiról vagy a CURL modul funkcióiról szóló részt a hivatalos PHP dokumentációban.

A fentiekből remélem, most már világos, hogy miért a következő a kérdés: „Hogyan generálhatok POST kérést a fejléc függvény segítségével?” - értelmetlen.

A header(string) függvény csak a kérés fejlécéhez ad hozzá bejegyzést, a kérés törzséhez nem.

Van egy másik típusú kérés - Tartalom-típus: többrészes/vegyes, remélem, a cikk elolvasása után könnyen megérti ezt a típust. Részletesen tanulmányozhatja

Ez a bejegyzés válasz az egyik cikkemben feltett kérdésre.

Ebben a cikkben szeretném elmondani, hogy mik a GET/POST/PUT/DELETE és mások a HTTP metódusok, miért találták ki őket, és hogyan kell használni őket a REST szerint.

HTTP

Tehát mi az internet egyik fő protokollja? A pedánsokat elküldöm az RFC2616-ra, a többit pedig emberileg elmondom :)

Ez a protokoll két számítógép (kliens és szerver) közötti interakciót írja le, amely a kérelem (Request) és válasz (Response) üzenetek alapján épül fel. Minden üzenet három részből áll: kezdővonalból, fejlécekből és törzsből. Ebben az esetben csak a rajtvonalra van szükség.

A kérés és a válasz kezdősorai eltérő formátumúak – minket csak a kérés kezdősora érdekel, amely így néz ki: MÓDSZER URI HTTP/ ,

VÁLTOZAT Ahol a METHOD a HTTP kérési metódus, az URI az erőforrás azonosító, a VERSION pedig a protokoll verziója (az pillanatnyilag

A fejlécek kettősponttal elválasztott név-érték párok gyűjteménye. A fejlécek különféle szolgáltatási információkat közvetítenek: üzenetkódolás, böngészőnév és verzió, cím, ahonnan a kliens érkezett (hivatkozó), stb.

Az üzenet törzse a ténylegesen továbbított adat. A válaszban a továbbított adat általában az a HTML oldal, amelyet a böngésző kért, a kérésben pedig például az üzenet törzsében a szerverre feltöltött fájlok tartalma kerül továbbításra. De általában nincs üzenet a kérésben.

HTTP interakciós példa

Nézzünk egy példát.

Kér:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Elfogadás: text/html Csatlakozás: bezár
Az első sor a lekérdezési sor, a többi a fejléc; üzenettörzs hiányzik

Válasz:
HTTP/1.0 200 OK Szerver: nginx/0.6.31 Tartalom-Nyelv: ru Tartalom-típus: text/html; charset=utf-8 Tartalomhossz: 1234 Csatlakozás: bezár ... MAGA A HTML OLDAL...

Erőforrások és módszerek

Térjünk vissza a kérés kezdősorához, és ne feledjük, hogy olyan paramétert tartalmaz, mint az URI. Ez az Uniform Resource Identifier rövidítése – egy egységes erőforrás-azonosító. Az erőforrás általában egy fájl a szerveren (egy példa URI ebben az esetben a „/styles.css”), de általában egy erőforrás lehet valamilyen absztrakt objektum is („/blogs/webdev/” - pontok a „Web” blokkfejlesztéshez", nem pedig egy adott fájlra).

A HTTP kérés típusa (más néven HTTP metódus) közli a szerverrel, hogy milyen műveletet szeretnénk végrehajtani az erőforráson. Kezdetben (a 90-es évek elején) azt feltételezték, hogy a kliens csak egy dolgot akarhat egy erőforrástól - kapni, de most a HTTP protokoll segítségével bejegyzéseket hozhat létre, profilt szerkeszthet, üzeneteket törölhet és még sok mást. És ezeket a műveleteket nehéz összekapcsolni a „bevételezés” kifejezéssel.

A HTTP-metódusok szintjén a műveletek és az erőforrások megkülönböztetésére a következő lehetőségeket találták ki:

• GET – erőforrás megszerzése
• POST - erőforrás létrehozása
• PUT - erőforrás frissítés
• DELETE – erőforrás törlése

Kérjük, vegye figyelembe, hogy a HTTP specifikáció nem követeli meg, hogy a szerver megértse az összes metódust (amelyből valójában sokkal több van, mint 4) - csak a GET szükséges, és azt sem mondja meg a szervernek, hogy mit kell tennie, amikor egy adott kérést kap. módszer. Ez azt jelenti, hogy a szerver válaszul a DELETE /index.php HTTP/1.1 kérésre nem köteles törölje az index.php oldalt a szerveren, ugyanúgy, mint a GET /index.php HTTP/1.1 kérésnél nem köteles visszaadja neked az index.php oldalt, az pl törölheti :)

A REST játékba lép

A REST (REpresentational State Transfer) egy kifejezés, amelyet 2000-ben Roy Fielding, a HTTP-protokoll egyik fejlesztője vezetett be, a webalkalmazások felépítésére vonatkozó elvek csoportjának elnevezéseként. Általában a REST szélesebb területet fed le, mint a HTTP – más hálózatokban is használható más protokollokkal. A REST a kliens és a szerver közötti interakció elveit írja le, az „erőforrás” és az „ige” (érthető alanyként és állítmányként) fogalma alapján. HTTP esetén az erőforrást az URI azonosítja, az ige pedig a HTTP metódus.

A REST azt javasolja, hogy hagyjuk abba ugyanazt az URI-t a különböző erőforrásokhoz (vagyis két különböző cikk címét, például /index.php?article_id=10 és /index.php?article_id=20 – ez nem REST-útvonal) és különböző HTTP-módszerek használata a különböző műveletekhez. Vagyis a REST megközelítéssel írt webalkalmazás a HTTP DELETE metódussal elérve töröl egy erőforrást (persze ez nem jelenti azt, hogy lehetőséget kell adni minden és mindenki törlésére, de bármilyen az alkalmazás törlési kérelmének a HTTP DELETE metódust kell használnia).

A REST lehetővé teszi a programozók számára, hogy szabványosított és a korábbinál valamivel szebb webalkalmazásokat írjanak. A REST használatával az új felhasználó hozzáadásához szükséges URI nem /user.php?action=create (GET/POST metódus), hanem egyszerűen /user.php (szigorúan POST metódus).

Ennek eredményeként a meglévő HTTP specifikáció és a REST megközelítés kombinálásával végre értelmet nyernek a különböző HTTP-módszerek. GET - visszaad egy erőforrást, POST - újat hoz létre, PUT - frissít egy meglévőt, DELETE - törli.

Problémák?

Igen, van egy kis probléma a REST gyakorlati használatával. Ezt a problémát HTML-nek hívják.

A PUT/DELETE kérések az XMLHttpRequest segítségével, manuálisan (mondjuk curl-en vagy akár telneten keresztül) felvehetők a szerverrel, de nem lehet olyan HTML űrlapot készíteni, amely teljes értékű PUT/DELETE kérést küld.

A helyzet az, hogy a HTML-specifikáció nem teszi lehetővé olyan űrlapok létrehozását, amelyek a GET-en vagy a POST-on kívül küldenek adatokat. Ezért ahhoz, hogy más módszerekkel normálisan dolgozhasson, mesterségesen kell utánoznia azokat. Például a Rackben (az a mechanizmus, amely alapján a Ruby interakcióba lép a webszerverrel; Rails, Merb és más Ruby keretrendszerek Rack segítségével készülnek) hozzáadhat egy rejtett mezőt az űrlaphoz "_method" néven, és adja meg a metódus nevét értékként (pl. "PUT") - ebben az esetben POST kérést küld a rendszer, de a Rack képes úgy tenni, mintha PUT-t kapott volna, nem pedig POST-ot.