Tämä ja seuraavat osat käsittelevät lyhyesti perusverkkosovellusten luomista PHP:n avulla. Se, mitä osiossa käsiteltiin, ei selvästikään riitä sovelluksellesi kommunikoimaan käyttäjän kanssa ja muotoilemaan hänen suorittamiaan toimintoja tai syöttämiään parametreja. Mitä puuttuu? Ei ole tarpeeksi tietoa siitä, kuinka järjestää käyttäjätietojen syöttäminen ja näiden tietojen siirtäminen palvelimelle. No, sinulla pitäisi olla jo perustiedot palvelimelle vastaanotettujen tietojen ohjelmointiprosessoinnista.

HTTP-pyyntömenetelmät ja niiden parametrit

Mikä tahansa dynaaminen verkkosovellus tuottaa käyttäjälle vastauksen hänen antamiensa parametrien tai asiakaspuolella suoritettujen toimien mukaisesti. Yhteyden ottaminen palvelimeen johtuu useimmiten kahdentyyppisistä pyynnöistä: GET-menetelmällä tai POST-menetelmällä. Muutama sana näiden kahden pyyntötyypin välisistä eroista.

GET-menetelmä:

Parametrit välitetään HTTP-pyynnön otsikossa, joten ne ovat näkyvissä komentorivi, ja tällainen pyyntö voidaan tallentaa kirjanmerkkeihin. Koska otsikon kokonaispituus on rajoitettu, myös GET:n avulla välitettävien parametrien määrä ja pituus on rajoitettu.

Uskotaan, että useiden identtisten peräkkäisten GET-pyyntöjen tulosten tulisi olla samat.

POST-menetelmä:

Pyyntöparametrit välitetään HTTP-pyynnön rungossa, joten niitä ei ole komentorivillä. Parametrien lukumäärä ja koko on rajoittamaton.

Uskotaan, että useiden identtisten POST-pyyntöjen tulokset voivat palauttaa erilaisia ​​arvoja, koska ne voivat muuttaa kohdeobjektin ominaisuuksia.

GET-menetelmää tulee käyttää tietoresurssin sisällön hakemiseen parametrien mukaan, kun kohderesurssin tietorakenteisiin ei tarvitse tehdä muutoksia ja pyyntö (URL) on järkevää tallentaa kirjanmerkkeihin. GET-menetelmä voi olla nopeampi kuin vastaavat POST-menetelmää käyttävät pyynnöt.

POST-menetelmää tulee käyttää, kun haluat piilottaa palvelimelle välitetyt parametrit URL-osoitteesta. Tätä menetelmää tulisi käyttää myös kohderesurssin sisällön muutospyynnöissä välittäen kuvauksen näistä muutoksista parametreissa (pyynnön rungossa).

Polku resurssiin?parameter1=arvo1¶meter2=value2&…

Jos sinulla ei ole erityistä HTML-lomaketta parametrien täyttämistä varten, voit tehdä virheenkorjauksen PHP-sovelluksesi toiminnasta välittämällä testiparametrit suoraan selaimen komentoriville, esimerkiksi:

Http://site/php-samples/sql.php?sql=select * lähteestä d_staff

Jos haluat käyttää pyyntöparametreja palvelinpuolella, sinun tulee käyttää yleisiä taulukoita $_GET Ja $_POST vastaavasti. Jos sovelluksesi ei välitä millä menetelmällä sitä käytetään, sinun tulee käyttää taulukkoa $_REQUEST, joka yhdistää $_GET- ja $_POST-taulukoiden tiedot esimerkiksi seuraavasti:

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

Tässä esimerkissä ohjelma määrittää, onko "sql"-parametri välitetty: jos kyllä, se antaa arvon vastaavalle muuttujalle, ja jos ei, se antaa sille tyhjän arvon.

HTTP-pyyntöparametrien määrittäminen HTML-lomakkeella

Parametrien määrittäminen manuaalisesti suoraan selaimen komentorivillä ei tietenkään ole kovin kätevää. Tämä menetelmä soveltuu HTTP-pyyntöjen ohjelmalliseen suorittamiseen, kun verkkosovellukset kommunikoivat keskenään. Jotta voit syöttää ja suorittaa alustavan tietojen varmennuksen asiakaspuolella, sinun tulee käyttää HTML-lomakkeita ja . Alla on esimerkki yksinkertaisin muoto, jolla syötetään tekstiparametri (arvo), joka sitten välitetään palvelimelle POST-menetelmän parametrina.

menetelmä ="post" toimintaa =’sql.php’ > SQL:
<b>nimi</b> </u>="sql" cols="100" rows="8">

Form-elementin method-attribuutti määrittää menetelmän, joka määrittää menetelmän, jolla data lähetetään palvelimelle (get tai post). Action-attribuutti määrittää php tiedosto , joka käsittelee pyynnön. Jos käsittelijänä pitäisi olla nykyinen tiedosto, action-attribuuttia ei tarvitse lisätä. Kaikille elementeille, joiden arvo on välitettävä HTTP-pyyntöparametrina, sinun on määritettävä nimi-attribuutille yksilöllinen arvo. Se on attribuutin arvo nimi tulee olemaan indeksi taulukoissa $_GET, $_POST tai $_REQUEST (katso esimerkki yllä). Painikkeen painaminen lähetä lähettää lomakkeen kaikki syötetyt arvot palvelimelle.

Ensimmäinen tapa suorittaa PHP POST -pyyntö on käyttää file_get_contents . Toinen menetelmä käyttää freadia yhdessä muutaman muun toiminnon kanssa. Molemmat vaihtoehdot käyttävät stream_context_create-funktiota vaadittujen pyyntöjen otsikkokenttien täyttämiseen.

Koodin selitys

$sPD-muuttuja sisältää siirrettävät tiedot. Sen on oltava HTTP-pyyntömerkkijonomuodossa, joten jotkin erikoismerkit on koodattava.

Sekä file_get_contents- että fread-funktiossa meillä on kaksi uutta parametria. Ensimmäinen on use_include_path . Koska teemme HTTP-pyynnön, se on epätosi molemmissa esimerkeissä. Kun arvoksi on asetettu tosi lukemaan paikallista resurssia, funktio etsii tiedostoa osoitteesta include_path .

Toinen parametri on konteksti, joka täytetään palautusarvolla stream_context_create, joka ottaa $aHTTP-taulukon arvon.

Tiedoston_get_contents käyttäminen POST-pyyntöjen tekemiseen

Jos haluat lähettää POST-pyynnön PHP:n file_get_contents-sovelluksella, sinun on täytettävä otsikkokentät manuaalisesti stream_context_create-komennolla ja määritettävä, mitä "käärettä" käytetään - tässä tapauksessa HTTP:

$sURL = "http://brugbart.com/Examples/http-post.php"; // LÄHETYS-URL $sPD = "name=Jacob&bench=150"; // POST-tiedot $aHTTP = array("http" => // Kääre, jota käytetään array("method" => "POST", // Pyynnön menetelmä // Pyynnön otsikot on asetettu "header" => "Sisältö" - tyyppi: application/x-www-form-urlencoded", "sisältö" => $sPD)); $konteksti = stream_context_create($aHTTP); $sisältö = file_get_contents($sURL, false, $context); echo $sisältö;

Freadin käyttäminen POST-pyyntöjen suorittamiseen

Voit käyttää fread-toimintoa POST-pyyntöjen tekemiseen. Seuraava esimerkki käyttää parametria stream_context_create tarvittavien HTTP-pyyntöotsikoiden muodostamiseen:

$sURL = "http://brugbart.com/Examples/http-post.php"; // LÄHETYS-URL $sPD = "name=Jacob&bench=150"; // POST-tiedot $aHTTP = array("http" => // Kääre, jota käytetään array("method" => "POST", // Request Method // Pyynnön otsikot on asetettu "header" => "Sisältö" - tyyppi: application/x-www-form-urlencoded", "sisältö" => $sPD)); $konteksti = stream_context_create($aHTTP); $kahva = fopen($sURL, "r", false, $context); $sisältö = ""; while (!feof($handle)) ( $contents .= fread($handle, 8192); ) fclose($handle); echo $sisältö;

GET-pyyntöjen tekeminen PHP:llä

Keskitymme nyt käyttämään fread- ja file_get_contents-tiedostoja sisällön lataamiseen Internetistä HTTP:n ja HTTPS:n kautta. Jotta voit käyttää tässä artikkelissa kuvattuja menetelmiä, sinun on otettava käyttöön fopen wrappers -vaihtoehto. Voit tehdä tämän määrittämällä php.ini-tiedoston allow_url_fopen-parametrin arvoksi On.

POST- ja GET-pyyntöjen suorittamista PHP:ssä käytetään verkkosivustoille kirjautumiseen, verkkosivujen sisällön hakemiseen tai uusien sovellusten versioiden tarkistamiseen. Käsittelemme yksinkertaisten HTTP-pyyntöjen tekemistä.

Freadin käyttäminen tiedostojen lataamiseen tai vastaanottamiseen Internetin kautta

Muista, että verkkosivujen lukeminen on rajoitettu paketin käytettävissä olevaan osaan. Joten sinun on käytettävä funktiota stream_get_contents ( samanlainen kuin file_get_contents) tai while-silmukka lukeaksesi sisällön pienempinä paloina, kunnes tiedoston loppu saavutetaan:

Tässä tapauksessa PHP POST -pyynnön käsittelyssä fread-funktion viimeinen argumentti on yhtä suuri kuin fragmentin koko. Sen ei yleensä pitäisi olla suurempi kuin 8192 ( 8*1024 ).

Niille on yhteistä se, että ne toimivat samalla tavalla. Niiden välillä ei ole teknisesti eroa. Mutta ideologisia eroja on.

Puhun niistä PHP:n yhteydessä. Huomaa, että HTTP-protokolla liittyy epäsuorasti PHP:hen, koska se luotiin html-sivujen vaihtamiseen ja PHP yksinkertaisesti laajentaa molempien ominaisuuksia.

GET-pyyntöä käytetään tietojen vastaanottamiseen ja POST-pyyntöä käytetään lähettämiseen. (Muista, että teknisesti ne toimivat samalla tavalla).

Siksi teimme PHP:n yhteydessä tämän ideologian pohjalta seuraavaa:
1. Aina kun käynnistät PHP:n, superglobaalit taulukot ($_GET, $_POST) luodaan oletuksena.
2. Jos kyselymerkkijonossa on kysymysmerkki(?). Kaikki sen jälkeen huomioidaan parametrit GET-pyyntö, ne esitetään muodossa "avain"="arvo" ja et-merkkiä (&) käytetään erottimena.
Esimerkki:
GET /index.php?name=Andrey&sukunimi=Galkin
Tämä on kyselymerkkijono, siinä on 2 parametria. nämä parametrit menevät $_GET-taulukkoon.
3. $_POST täytetään eri tavalla. tämän taulukon sisältö täytetään "pyyntöotsikoista". Eli paikasta, joka on selvästi piilossa näkyviltä. Selain hoitaa kaikki tällaisten otsikoiden luomiseen liittyvät työt. Vaikka joskus jotain muokataan otsikoissa manuaalisesti.

Useimmiten postipyyntöä käytetään lomakkeissa (tietojen lähettämiseen).

Meillä on esimerkiksi kirjautumislomake, jossa on 2 kenttää: sisäänkirjautuminen ja salasana.

Kuvitellaan, että käytämme GET-menetelmää. Tämän jälkeen lomakkeen lähettämisen yhteydessä siirrymme seuraavaan osoitteeseen /login.php?login=Andrey&password=123 Hyväksyt, että tällaisten tietojen välittäminen tällä tavalla ei ole ollenkaan turvallista. Kuka tahansa voi avata selaimesi ja aloittaa sivuston osoitteen syöttämisen, näkee salasanasi ja kirjautumisesi historiasta.

Mutta jos määritämme POST-menetelmän, saisimme seuraavan pyynnön:
POST /login.php (login=Andrey&password=123) suluissa oleva piilotettaisiin eikä tallennettaisi millään tavalla selaimeen.

Yhteenvetona:
GET on saada tietty sivu sisään tietty muoto(lajittelu, nykyinen sivu blogi, hakupalkki jne.).
POST - sellaisten tietojen lähettämiseen, jotka eivät vaikuta sivun näyttöön, siinä mielessä, että nämä tiedot vaikuttavat vain komentosarjan tulokseen (kirjautumistunnukset, salasanat, luottokorttien numerot, viestit jne.).

Ja toinen hyvä uutinen on, että niitä voi esimerkiksi yhdistää
POST /index.php?page=login (login=Andrey&password=123) Luulen, että olen jo tarpeeksi selittänyt, mitä tästä tulee ja mitkä parametrit menevät mihin tahansa taulukkoon.

IN viime aikoina Näen PHPClubin pääfoorumilla yhä useammin kysymyksiä POST- ja GET-pyyntöjen luomisesta sekä kysymyksiä aiheesta: "Kuinka voin luoda POST-pyynnön otsikkotoiminnon avulla." Uskon, että i-kirjaimen käyttäminen on tarpeen tätä tekniikkaa, koska aloittelevat ohjelmoijat eivät yksinkertaisesti ymmärrä verkon periaatteita sellaisenaan. Joten aloitetaan matkamme HTTP-protokollan maailman läpi.

1. HTTP-protokolla. Johdanto

Haluaisin heti selventää yhden pienen asian.

Kauhea sanaprotokolla ei ole muuta kuin monien ihmisten sopimus, vain yhtenä kauniina hetkenä ihmiset päättivät: "Tehdään näin, niin kaikki on hyvin." Ei ole mitään pelättävää, kaikki on yksinkertaisesti törkeää ja paljastamme nyt tämän häpeän. Joten mikä on HTTP-protokolla ja mihin sitä käytetään?

Maailmassa ei ole ihmeitä eikä varsinkaan ohjelmoinnin ja Internetin maailmassa!

Hyväksy tämä horjumattomana totuutena. Ja jos ohjelma ei toimi tai ei toimi toivotulla tavalla, se on todennäköisesti joko kirjoitettu väärin tai sisältää virheitä. Joten kuinka selain pyytää palvelinta lähettämään sille mitään?

Kyllä, hyvin yksinkertaista! Sinun tarvitsee vain rentoutua hieman ja alkaa nauttia prosessista :-)

1.2. Kirjoitamme ensimmäistä HTTP-pyyntöämme

• Jos luulet, että kaikki on liian monimutkaista, olet väärässä. Ihminen on suunniteltu niin, että hän ei yksinkertaisesti pysty luomaan jotain monimutkaista, muuten hän itse hämmentyy siinä :-) Eli on selain ja on Web-palvelin.
• Selain on aina tiedonvaihdon aloittaja. Web-palvelin ei koskaan yksinkertaisesti lähetä mitään kenellekään niin, että se lähettää jotain selaimelle - selaimen on pyydettävä sitä.
• Yksinkertaisin HTTP-pyyntö saattaa näyttää tältä:
• HANKI http://www.php.net/ HTTP/1.0\r\n\r\n

GET (käännetty englanniksi tarkoittaa "get") - pyynnön tyyppi voi olla erilainen, esimerkiksi POST, HEAD, PUT, DELETE (tarkastelemme joitain niistä alla). http://www.php.net/ - URI (osoite), josta haluamme saada ainakin jonkin verran tietoa (toivomme tietysti oppivamme HTML-sivun). HTTP/1.0 on protokollan tyyppi ja versio, jota käytämme viestiessään palvelimen kanssa.

\r\n on rivin loppu, joka on toistettava kahdesti, miksi selviää hieman myöhemmin.

Voit suorittaa tämän pyynnön hyvin yksinkertaisesti. Suorita telnet.exe-ohjelma, kirjoita isännäksi www.php.net, määritä portti 80 ja kirjoita tämä pyyntö painamalla Enter-näppäintä kahdesti muodossa \r\n\r\n. Vastauksena saat HTML-koodin

kotisivu sivusto www.php.net.

• 1.3 Pyynnön rakenne Katsotaanpa, mistä HTTP-pyyntö koostuu.

Kaikki on melko yksinkertaista. Aloitetaan siitä, että HTTP-pyyntö on täysin merkityksellinen teksti. Mistä se yleensä koostuu? Harkitsemme HTTP 1.0 -protokollaa. Niin:

• Pyyntö-Line[Yleinen otsikko | Pyynnön otsikko | Entity-Header ]\r\n[ Entity-Body ]
• Pyyntö-Line- suhteellinen tai absoluuttinen linkki sivulle, jossa on joukko parametreja, esimerkiksi /index.html tai http://www.myhost.ru/index.html tai /index.html?a=1&b=qq.
• Jälkimmäisessä tapauksessa palvelimelle lähetetään pyyntö, jossa on joukko muuttujia a ja b vastaavien arvoineen, ja "&" -merkki - et-merkki - toimii erottimena parametrien välillä. HTTP-versio

- HTTP-protokollan versio, tässä tapauksessa "HTTP/1.0".

Olemme erittäin kiinnostuneita GET- ja POST-käsittelymenetelmistä. GET-menetelmällä voit yksinkertaisesti välittää parametreja komentosarjalle ja POST-menetelmällä voit emuloida lomakkeen lähettämistä. GET-menetelmän Request-URI saattaa näyttää tältä:

• "/index.html?param1=1¶m2=2". Yleinen otsikko
  - otsikon pääosa.
  Muoto:
• Voi olla vain kaksi parametria: Päivämäärä tai Pragma. Päivämäärä - Greenwich-päivämäärä muodossa "Viikonpäivä, Päivä Kuukausi Vuosi HH:MM:SS GMT", esimerkiksi "Ti, 15. marraskuuta 1994 08:12:31 GMT" - pyynnön luontipäivä. Pragmalla voi olla yksi no-cache-arvo, joka poistaa sivun välimuistin käytöstä.

  Pyyntö-otsikko - otsikon osa, joka kuvaa pyyntöä..
  Request-Header voi sisältää seuraavat parametrit:

• Salli, Valtuutus, Lähettäjä, Jos-Modified-Since, Viittaaja, User-Agent Tässä luvussa emme käsittele valtuutusparametria, koska sitä käytetään yksityisten resurssien käyttämiseen, jota ei tarvita kovin usein.
  Voit oppia luomaan valtuutetun käyttöoikeusotsikon itse osoitteessa www.w3c.org.
  Salli
• - asettaa hyväksyttävät käsittelymenetelmät. - Muoto: "Salli: GET | HEAD\n". Parametri jätetään huomioimatta määritettäessä POST-käsittelymenetelmä Request-Line-rivillä. Määrittää hyväksyttävät pyyntöjen käsittelytavat.
  Välityspalvelimet eivät muuta Salli-parametria ja se saavuttaa palvelimen muuttumattomana.
  From sähköpostiosoite joka lähetti pyynnön.
• Muoto: "From: adderss\r\n". Esimerkiksi "From:
  [sähköposti suojattu]
  \r\n".
• Jos-Muokattu-Alkaen- osoittaa, että pyyntöä ei ole muutettu sen ja sen jälkeen.
  Muoto: "Jos-Muokattu-Alkaen: päivämäärä\r\n"
  Käytetään vain GET-käsittelymenetelmässä. Päivämäärä on määritetty GMT:ssä samassa muodossa kuin Date-parametrille Yleiset-otsikossa.
• Viittaaja- absoluuttinen linkki sivulle, jolta pyyntö aloitettiin, eli linkki sivulle, jolta käyttäjä tuli meidän sivulle.
  Muoto: "Viittausosoite: url\n".
• Esimerkki: "Viite: www.host.ru/index.html\n". User-Agent
  Tämä pyynnön osa määrittää parametrit, jotka kuvaavat sivun tekstiosaa. Entity-Header voi sisältää seuraavat parametrit: Salli, Sisällön koodaus, Sisällön pituus, Sisältötyyppi, Vanhenee, Viimeksi muokattu, laajennus-otsikko.
• Salli, Valtuutus, Lähettäjä, Jos-Modified-Since, Viittaaja, User-Agent- Parametri, joka on samankaltainen kuin Allow from General-Header.
• Sisällön koodaus- tietojen koodaustyyppi Entity-Body.
  Muoto: "Sisällön koodaus: x-gzip | x-compress | muu tyyppi\n".
  Esimerkki: "Sisällön koodaus: x-gzip\n". Merkki "|". tarkoittaa sanaa "tai", eli tätä tai tuota tai tuota jne.
  Toinen tyyppi voi osoittaa, kuinka tiedot on koodattu, esimerkiksi POST-menetelmää varten: "Content-Encoding: application/x-www-form-urlencoded\n".
• Sisältö-pituus- Entity-Bodylle lähetettyjen tavujen määrä. Content-Length-arvolla on täysin erilainen merkitys MIME-muodossa lähetetylle tiedolle, jossa se toimii parametrina, joka kuvaa osaa datasta - "ulkoinen/entity-body".
  Kelvolliset luvut ovat kokonaislukuja nollasta ylöspäin.
• Esimerkki: "Content-Length: 26457\n". Sisältö-tyyppi
  - lähetetyn tiedon tyyppi.
• Esimerkki: "Sisältötyyppi: text/html\n". Vanhenee
  - Aika, jolloin sivu tulee poistaa selaimen välimuistista.
• Muoto: "Vanhenee: päivämäärä\n". Päivämäärän muoto on sama kuin Päivämäärä-parametrin päivämäärämuoto General-Headerista. Viimeksi muokattu
  - lähetettyjen tietojen viimeisen muutoksen aika.
• Muoto: "Viimeksi muokattu: päivämäärä\n". Päivämäärän muoto on sama kuin Päivämäärä-parametrin päivämäärämuoto General-Headerista. laajennus-otsikko
  - otsikon osa, joka voi olla tarkoitettu esimerkiksi selaimen tai muun asiakirjan vastaanottavan ohjelman käsiteltäväksi. Tässä osassa voit kuvata parametrisi muodossa "ParameterName: parametriarvo\n". Nämä parametrit ohitetaan, jos asiakasohjelma ei osaa käsitellä niitä.

Esimerkiksi: "Eväste: r=1\r\n" - asettaa sivulle tunnetut evästeet.

Ja nyt, tällaisten kauheiden sanojen jälkeen, yritetään rauhoittua hieman ja ymmärtää, mitä tarvitsemme? Luonnollisesti ymmärrämme esimerkkien avulla.

Kuvittelemme, että meidän on saatava sivu sivustolta ohittamalla evästeet, muuten meidät yksinkertaisesti lähetetään kutsumattomina vieraina, ja lisäksi tiedetään, että sinulla on oikeus päästä tälle sivulle vasta, kun olet vieraillut sivuston pääsivulla. sivusto.

2 GET-menetelmä

Kirjoitetaan pyyntömme.
HANKI http://www.site.ru/news.html HTTP/1.0\r\n

Isäntä: www.site.ru\r\n
Eväste: tulot=1\r\n

Tämä pyyntö kertoo meille, että haluamme saada sivun sisällön osoitteessa http://www.site.ru/news.html GET-menetelmällä. Isäntä-kenttä osoittaa, että tämä sivu sijaitsee www.site.ru-palvelimella, Viittaus-kenttä osoittaa, että tulimme uutisia sivuston pääsivulta, ja Eväste-kenttä osoittaa, että meille on määritetty tällainen tai sellainen eväste. Miksi Isäntä-, Viittaus- ja Eväste-kentät ovat niin tärkeitä? Koska tavalliset ohjelmoijat dynaamisia sivustoja luodessaan tarkistavat tietokentät, jotka näkyvät skripteissä (mukaan lukien PHP) muuttujien muodossa. Mitä varten tämä on? Jotta esimerkiksi estetään sivuston ryöstö, ts.

he eivät asettaneet siihen ohjelmaa automaattista latausta varten tai niin, että sivustolla vieraileva henkilö pääsisi sinne aina vain pääsivulta jne.

Kuvittele nyt, että meidän on täytettävä sivun lomakekentät ja lähetettävä pyyntö lomakkeesta, olkoon tässä lomakkeessa kaksi kenttää: sisäänkirjautuminen ja salasana (kirjautumistunnus ja salasana) - ja tietysti tiedämme kirjautumistunnuksen ja salasana.
HANKI http://www.site.ru/news.html HTTP/1.0\r\n
HANKI http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Isäntä: www.site.ru\r\n
Eväste: tulot=1\r\n

Viite: http://www.site.ru/index.html\r\n Kirjautumistunnuksemme on "Petya Vasechkin" Miksi meidän pitäisi kirjoittaa Petya%20Vasechkin? Tämä johtuu siitä, että palvelin voi tunnistaa erikoismerkit merkkinä uuden parametrin olemassaolosta tai pyynnön päättymisestä jne. Siksi on olemassa algoritmi parametrien nimien ja niiden arvojen koodaamiseen pyynnön virhetilanteiden välttämiseksi. Täydellinen kuvaus

Tämä algoritmi löytyy, ja PHP:ssä on funktiot rawurlencode ja rawurldecode koodausta ja dekoodausta varten. Haluaisin huomauttaa, että PHP tekee dekoodauksen itse, jos koodatut parametrit välitettiin pyynnössä. Tämä päättää ensimmäisen luvun HTTP-protokollaan tutustumisestani. Seuraavassa luvussa tarkastelemme rakennuspyyntöjä, kuten POST (käännetty englanniksi "lähetä"), jotka ovat paljon mielenkiintoisempia, koska Tämä on pyyntötyyppi, jota käytetään lähetettäessä tietoja HTML-lomakkeista.

3. POST-menetelmä.

3.1 Sisältötyyppi: Application/x-www-form-urlencoded.

Kirjoitamme samanlaisen pyynnön kuin GET-pyyntömme siirtää käyttäjätunnus ja salasana, jota käsiteltiin edellisessä luvussa:

HANKI http://www.site.ru/news.html HTTP/1.0\r\n
HANKI http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Isäntä: www.site.ru\r\n
Sisältötyyppi: Application/x-www-form-urlencoded\r\n
Sisältö-Pituus: 35\r\n
Eväste: tulot=1\r\n

Tässä on esimerkki Content-Type- ja Content-Length-otsikkokenttien käytöstä. Content-Length kertoo kuinka monta tavua data-alue vie, joka on erotettu otsikosta toisella rivinvaihdolla \r\n. Mutta parametrit, jotka aiemmin sijoitettiin GET-pyynnön Request-URI:iin, ovat nyt Entity-Bodyssa. Voidaan nähdä, että ne on muodostettu täsmälleen samalla tavalla, sinun tarvitsee vain kirjoittaa ne otsikon jälkeen. Haluan huomauttaa vielä yhden asian tärkeä kohta

, mikään ei estä samanaikaisesti Entity-Body-parametrijoukon kanssa sijoittamasta parametreja muilla nimillä Request-URI:iin, esimerkiksi:
.....
Eväste: tulot=1\r\n
POST http://www.site.ru/news.html?type=user HTTP/1.0\r\n

login=Petya%20Vasechkin&password=qq

3.2 Sisältötyyppi: moniosainen/lomake-data

Heti kun Internet-maailma tajusi, että tiedostoja olisi mukava lähettää lomakkeiden kautta, W3C-konsortio ryhtyi hiomaan POST-pyyntömuotoa. Siihen mennessä MIME-muoto (Multipurpose Internet Mail Extensions - monikäyttöiset protokollalaajennukset sähköpostiviestien luomiseen) oli jo laajalti käytössä, joten emmekä keksi pyörää uudelleen, päätimme käyttää osaa tästä viestien luontiformaatista luomiseen. POST-pyynnöt HTTP-protokollassa.

Mitkä ovat tärkeimmät erot tämän muodon ja Application/x-www-form-urlencoded-tyypin välillä?

Suurin ero on, että Entity-Body voidaan nyt jakaa osiin, jotka on erotettu rajoilla (rajalla). Mielenkiintoisinta on, että jokaisessa osiossa voi olla oma otsikkonsa kuvaamaan siihen tallennettua dataa, ts.

yhdellä pyynnöllä voit siirtää erityyppisiä tietoja (kuten Mail-kirjeessä, voit siirtää tiedostoja samaan aikaan tekstin kanssa).
HANKI http://www.site.ru/news.html HTTP/1.0\r\n
HANKI http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Isäntä: www.site.ru\r\n

Joten aloitetaan. Tarkastellaanpa taas samaa esimerkkiä kirjautumistunnuksen ja salasanan siirrosta, mutta nyt uudessa muodossa.
Eväste: tulot=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Sisältö-Pituus: 209\r\n
--1BEF0A57BE110FD467A Sisältö-Pituus: 209\r\n
Sisältö-Pituus: 209\r\n
\r\n Sisältö-Pituus: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Sisältö-Pituus: 209\r\n
Sisältö-sijoittelu: muoto-tiedot; name="kirjaudu sisään" Sisältö-Pituus: 209\r\n
Sisältö-Pituus: 209\r\n
Petya Vasechkin Sisältö-Pituus: 209\r\n
Sisältö-sijoittelu: muoto-tiedot; name="salasana" Sisältö-Pituus: 209\r\n

Ymmärretään nyt, mitä on kirjoitettu. :-) Korostin erityisesti joitain \r\n-merkkejä lihavoituna, jotta ne eivät sulautuisi tietoihin. Jos katsot tarkasti, huomaat rajakentän Content-Type-kohdan jälkeen. Tämä kenttä määrittää osien erottimen - reunuksen. Reunuksena voidaan käyttää latinalaisista kirjaimista ja numeroista koostuvaa merkkijonoa sekä eräitä muita symboleja (valitettavasti en muista mitä muita). Pyynnön rungossa rajan alkuun lisätään "--" ja pyyntö päättyy rajaan, jonka loppuun lisätään myös merkit "--". Pyynnössämme on kaksi osaa, joista ensimmäinen kuvaa kirjautumiskenttää ja toinen salasanakenttä.

Content-Disposition (tietotyyppi osiossa) sanoo, että tämä on lomakkeen tietoja, ja nimikenttä määrittää kentän nimen. Tähän loppuu osion otsikko ja seuraava on osan tietoalue, johon kentän arvo sijoitetaan (arvoa ei tarvitse koodata!).

Haluan kiinnittää huomionne siihen, että osion otsikoissa ei tarvitse käyttää Content-Lengthiä, vaan pyynnön otsikossa kannattaa ja sen arvo on koko Entity-Bodyn koko, joka näkyy toisen \ jälkeen. r\n seuraavat sisällön pituus: 209\ r\n. Ne. Entity-Body erotetaan otsikosta ylimääräisellä rivinvaihdolla (joka näkyy myös osissa).

Nyt kirjoitetaan pyyntö siirtää tiedosto.
HANKI http://www.site.ru/news.html HTTP/1.0\r\n
POST http://www.site.ru/postnews.html HTTP/1.0\r\n
Isäntä: www.site.ru\r\n
Viite: http://www.site.ru/news.html\r\n
Sisältö-tyyppi: moniosainen/lomake-data; boundary=1BEF0A57BE110FD467A\r\n
Eväste: tulot=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Sisältö-Pituus: 209\r\n
Sisältö-Pituus: 491\r\n Sisältö-Pituus: 209\r\n
Sisältö-Pituus: 209\r\n
Sisältö-sijoittelu: muoto-tiedot; name="news_header" Sisältö-Pituus: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Sisältö-Pituus: 209\r\n
Esimerkki-uutinen Sisältö-Pituus: 209\r\n
Sisältö-sijoittelu: muoto-tiedot; name="news_file"; Sisältö-Pituus: 209\r\n
tiedostonimi="uutiset.txt" Sisältö-Pituus: 209\r\n
Sisältö-Pituus: 209\r\n
Sisältötyyppi: sovellus/oktettivirta Sisältö-Pituus: 209\r\n
Sisältö-sijoittelu: muoto-tiedot; name="salasana" Sisältö-Pituus: 209\r\n

Sisällönsiirto-koodaus: binääri

Erittäin tärkeä kohta. Useimmat CGI-skriptit ovat älykkäiden ihmisten kirjoittamia, joten he haluavat tarkistaa saapuvan tiedoston tyypin, joka on Content-Type-tilassa. Mitä varten? Useimmiten tiedostojen lataamista verkkosivustoille käytetään kuvien vastaanottamiseen vierailijalta. Joten selain yrittää itse määrittää, millaisen tiedoston vierailija haluaa lähettää ja lisää pyyntöön sopivan sisältötyypin. Skripti tarkistaa sen vastaanotettaessa, ja esimerkiksi jos se ei ole gif tai jpeg, se jättää tämän tiedoston huomioimatta. Siksi, kun luot pyyntöä "manuaalisesti", huolehdi Content-Type-arvosta niin, että se on lähinnä siirretyn tiedoston muotoa.

Esimerkissämme luodaan pyyntö, jossa tekstitiedosto. Pyyntö binääritiedoston siirtoa varten luodaan samalla tavalla.

4. Jälkikirjoitus.

Mielestäni pyyntöjen lähettämisestä palvelimelle ei kannata puhua yksityiskohtaisesti. Tämä on puhtaasti RHP-tekniikan kysymys :-). Riittää, kun luet huolellisesti osion toiminnoista socket-työskentelyssä tai CURL-moduulin toiminnoista virallisessa PHP-dokumentaatiossa.

Yllä olevan perusteella toivon, että nyt on selvää, miksi kysymys kuuluu: "Kuinka voin luoda POST-pyynnön otsikkofunktiolla?" - merkityksetön.

Header(string)-funktio lisää merkinnän vain pyynnön otsikkoon, mutta ei pyynnön runkoon.

On olemassa toisenlainen pyyntö - Sisältötyyppi: moniosainen/sekoitettu, toivottavasti tämän artikkelin luettuasi ymmärrät tämän tyypin helposti itse. Voit tutkia sitä yksityiskohtaisesti

Tämä viesti on vastaus eräässä artikkelissani esitettyyn kysymykseen.

Tässä artikkelissa haluan kertoa sinulle, mitä HTTP-menetelmät GET/POST/PUT/DELETE ja muut ovat, miksi ne keksittiin ja kuinka niitä käytetään REST:n mukaisesti.

HTTP

Joten mikä on yksi Internetin tärkeimmistä protokollista? Lähetän pedantit RFC2616:een ja loput kerron inhimillisesti :)

Tämä protokolla kuvaa kahden tietokoneen (asiakas ja palvelin) välistä vuorovaikutusta, joka on rakennettu pyyntö (Request) ja vastaus (Response) sanomien perusteella. Jokainen viesti koostuu kolmesta osasta: aloitusriviltä, ​​otsikoista ja tekstistä. Tässä tapauksessa tarvitaan vain lähtöviiva.

Pyynnön ja vastauksen aloitusrivit ovat eri muotoisia - meitä kiinnostaa vain pyynnön aloitusrivi, joka näyttää tältä: METHOD URI HTTP/ ,

VERSIO Kun METHOD on HTTP-pyyntömenetelmä, URI on resurssin tunniste, VERSION on protokollan versio tällä hetkellä

Otsikot ovat kokoelma nimi-arvo-pareja, jotka on erotettu kaksoispisteellä. Otsikoissa välitetään erilaisia ​​palvelutietoja: viestin koodaus, selaimen nimi ja versio, osoite, josta asiakas tuli (viittaus) ja niin edelleen.

Viestin runko on todellista lähetettävää dataa. Vastauksessa välitettävä tieto on yleensä selaimen pyytämä HTML-sivu ja pyynnössä esimerkiksi viestin rungossa välitetään palvelimelle ladattujen tiedostojen sisältö. Mutta pääsääntöisesti pyynnössä ei ole viestitekstiä ollenkaan.

Esimerkki HTTP-vuorovaikutuksesta

Katsotaanpa esimerkkiä.

Pyytää:
GET /index.php HTTP/1.1 Isäntä: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Hyväksy: text/html Yhteys: sulje
Ensimmäinen rivi on kyselyrivi, loput ovat otsikoita; viestin runko puuttuu

Vastaus:
HTTP/1.0 200 OK Palvelin: nginx/0.6.31 Sisältökieli: ru Sisältötyyppi: text/html; charset=utf-8 Content-Length: 1234 Yhteys: sulje ... HTML-SIVU ITSE...

Resurssit ja menetelmät

Palataan pyynnön aloitusriville ja muistetaan, että se sisältää sellaisen parametrin kuin URI. Tämä tulee sanoista Uniform Resource Identifier - yhtenäinen resurssitunniste. Resurssi on pääsääntöisesti palvelimella oleva tiedosto (esimerkki-URI tässä tapauksessa on “/styles.css”), mutta yleensä resurssi voi olla myös jokin abstrakti objekti (“/blogs/webdev/” - pisteet "Web"-lohkon kehittämiseen" eikä tiettyyn tiedostoon).

HTTP-pyyntötyyppi (kutsutaan myös HTTP-menetelmäksi) kertoo palvelimelle, mitä toimintoa haluamme suorittaa resurssille. Aluksi (90-luvun alussa) oletettiin, että asiakas voi haluta resurssilta vain yhtä asiaa - vastaanottaa sen, mutta nyt HTTP-protokollan avulla voit luoda viestejä, muokata profiilia, poistaa viestejä ja paljon muuta. Ja näitä toimia on vaikea yhdistää termiin "kuitti".

Toimintojen erottamiseksi resursseista HTTP-menetelmien tasolla keksittiin seuraavat vaihtoehdot:

• HANKI - resurssin hankkiminen
• POST - resurssien luominen
• PUT - resurssien päivitys
• DELETE - resurssin poisto

Huomaa, että HTTP-spesifikaatio ei edellytä palvelimen ymmärtävän kaikkia menetelmiä (joita on itse asiassa paljon enemmän kuin 4) - tarvitaan vain GET, eikä myöskään kerro palvelimelle, mitä sen pitäisi tehdä, kun se vastaanottaa pyynnön tietyllä menetelmä. Tämä tarkoittaa, että palvelin vastauksena DELETE /index.php HTTP/1.1-pyyntöön ei ole velvollinen poista index.php-sivu palvelimelta, kuten GET /index.php HTTP/1.1-pyynnössä ei ole velvollinen palauttaa index.php-sivun sinulle, se voi esimerkiksi poistaa sen :)

REST tulee peliin

REST (REpresentational State Transfer) on termi, jonka Roy Fielding, yksi HTTP-protokollan kehittäjistä, otti vuonna 2000 käyttöön verkkosovellusten rakentamisen periaateryhmän nimeksi. Yleensä REST kattaa laajemman alueen kuin HTTP - sitä voidaan käyttää myös muissa verkoissa muilla protokollilla. REST kuvaa asiakkaan ja palvelimen välisen vuorovaikutuksen periaatteita, jotka perustuvat käsitteisiin "resurssi" ja "verbi" (voidaan ymmärtää subjektina ja predikaattina). HTTP:n tapauksessa resurssi tunnistetaan sen URI:n perusteella, ja verbi on HTTP-menetelmä.

REST ehdottaa luopumista saman URI:n käytöstä eri resursseille (eli kahden eri artikkelin osoitteet, kuten /index.php?article_id=10 ja /index.php?article_id=20 - tämä ei ole REST-tapa) ja käyttämällä erilaisia ​​HTTP-menetelmiä eri toimiin. Eli REST-lähestymistavalla kirjoitettu verkkosovellus poistaa resurssin, kun sitä käytetään HTTP DELETE -menetelmällä (tämä ei tietenkään tarkoita, että on tarpeen antaa mahdollisuus poistaa kaikki ja kaikki, mutta mikä tahansa sovelluksen poistopyynnön on käytettävä HTTP DELETE -menetelmää).

REST antaa ohjelmoijille mahdollisuuden kirjoittaa standardoituja ja hieman kauniimpia web-sovelluksia kuin ennen. Käyttämällä RESTiä URI uuden käyttäjän lisäämiseen ei ole /user.php?action=create (GET/POST-menetelmä), vaan yksinkertaisesti /user.php (tarkka POST-menetelmä).

Tämän seurauksena yhdistämällä olemassa oleva HTTP-spesifikaatio ja REST-lähestymistapa, erilaiset HTTP-menetelmät ovat lopulta järkeviä. GET - palauttaa resurssin, POST - luo uuden, PUT - päivittää olemassa olevan, DELETE - poistaa sen.

Ongelmia?

Kyllä, RESTin käytössä on pieni ongelma käytännössä. Tätä ongelmaa kutsutaan HTML:ksi.

PUT/DELETE-pyynnöt voidaan lähettää XMLHttpRequestillä, ottamalla yhteyttä palvelimeen manuaalisesti (esim. curlin tai vaikka telnetin kautta), mutta et voi tehdä HTML-lomaketta, joka lähettää täysimittaisen PUT/DELETE-pyynnön.

Asia on siinä, että HTML-määritys ei salli sinun luoda lomakkeita, jotka lähettävät tietoja muuten kuin GET- tai POST-protokollan kautta. Siksi, jotta voit työskennellä normaalisti muiden menetelmien kanssa, sinun on matkittava niitä keinotekoisesti. Esimerkiksi Rackissa (mekanismi, jonka perusteella Ruby on vuorovaikutuksessa verkkopalvelimen kanssa; Rails, Merb ja muut Ruby-kehykset tehdään Rackilla) voit lisätä lomakkeeseen piilotetun kentän nimellä "_method" ja määritä arvoksi menetelmän nimi (esim. "PUT") - tässä tapauksessa POST-pyyntö lähetetään, mutta Rack voi teeskennellä, että se sai PUT:n POSTin sijaan.