Ontvang postplaatsverzoeken. Post- en Get-verzoeken, wat is het verschil daartussen, wat is beter en voor welke doeleinden

Het gebruik van GET- en POST-methoden in PHP is moeilijk te overschatten, aangezien deze methoden op vrijwel elke website te vinden zijn. Voordat u het hieronder beschreven materiaal bestudeert, raad ik u aan vertrouwd te raken met de html-tag

. Laten we elk van deze methoden in detail bekijken.

GET-methode

De GET-methode wordt gebruikt om gegevens over te dragen URL-tekenreeks. Het is je misschien opgevallen dat er lange en onduidelijke URL's zijn. Bijvoorbeeld: function.php?login=Alex&email=dezyakin. IN in dit geval de gegevens worden verwerkt in function.php. Na het vraagteken "?" staat een lijst met doorgegeven parameters (parameters worden gescheiden door "&") met waarden: de login-parameter krijgt de waarde Alex toegewezen en de e-mailvariabele krijgt de waarde dezyakin. De gegevens worden opgeslagen in de superglobal array $_GET. Hieronder vindt u een voorbeeld van het gebruik van de GET-methode:

Login: E-mail: Met behulp van de superglobal array $_GET geven we de geaccepteerde waarden weer:*/echo "
login = ". $_GET["inloggen"] ; echo "
email = ". $_GET["e-mail"] ; ?>

Merk op hoe we waarden uit de $_GET superglobal array lezen: $_GET["variabele_naam"]. In ons voorbeeld zijn de namen van de variabelen gedeclareerd in de vorm (naam=login en naam=e-mail).

Advies:
Voordat ik de ontvangen waarden verwerkt, raad ik u aan om via functies te controleren of ze bestaan isset(variabelenaam) of leeg(variabele_naam)- deze functies zijn besproken in de vorige les 2: variabelen in PHP. Bijvoorbeeld:

controleren op bestaan ​​met behulp van isset: if isset ($_GET["inloggen"] ) ( operators voor het verwerken van aanmeldingen ... } //of controleer op bestaan ​​met leeg: indien leeg ($_GET["email"] ) ( operators voor e-mailverwerking ... } ?>

In het formulier kunt u de naam opgeven van het bestand dat de overgedragen waarden zal verwerken. Dit gebeurt met behulp van het attribuut actie vormen, waaraan u het adres van dit bestand kunt toewijzen. Standaard wordt dit bestand toegewezen huidige bestand(dat wil zeggen verwerkt in het bestand waarin het formulier zich bevindt). Hier is een voorbeeld waarin gegevens uit een formulier worden overgebracht naar het bestand srcipt.php voor verwerking:

Login: E-mail:

Het script.php-bestand moet een soort informatiehandler bevatten, anders wordt de informatie leeg doorgegeven.

De GET-methode heeft veel nadelen:

Vanwege de bovengenoemde nadelen GET-methode wordt alleen gebruikt in gevallen waarin het nodig is om een ​​kleine hoeveelheid gegevens over te dragen, en deze gegevens zijn op geen enkele manier geclassificeerd.

POST-methode

De POST-methode verschilt van GET doordat de gegevens in privévorm worden overgedragen. Er is een superglobal array $_POST waaruit gegevens als volgt kunnen worden gelezen: $_POST["variabele_naam"]. Bijvoorbeeld:

Login: "> E-mail: ">
Met behulp van de superglobal array $_POST geven we de geaccepteerde waarden weer:*/echo "
login = ". $_POST["inloggen"] ; echo "
email = ". $_POST["e-mail"] ; ?>

Het resultaat van het uitvoeren van de bovenstaande code wordt weergegeven in de onderstaande afbeelding:

Zoals u kunt zien, heeft de URL geen naschrift, maar zijn de gegevens toch ontvangen en weergegeven.

Opmerking:
1) Het volume van de verzonden waarden met behulp van de POST-methode is standaard beperkt en is gelijk aan 8 MB. Om deze waarde te verhogen moet je de post_max_size richtlijn in php.ini wijzigen.

2) In eerdere versies van PHP werden in plaats van de korte superglobal array-namen $_GET en $_POST langere namen gebruikt: $HTTP_GET_VARS en $HTTP_POST_VARS . Standaard zijn ze uitgeschakeld in PHP 5, maar je kunt ze inschakelen in het php.ini-configuratiebestand met behulp van de parameter register_long_arrays. In de php 6-versie zijn deze lange namen niet beschikbaar.

3) Voordat u variabelen uit $_POST verwerkt, raad ik u aan de variabelen op hun aanwezigheid te controleren, net zoals bij de GET-methode is gedaan.

Wat ze gemeen hebben is dat ze op dezelfde manier werken. Technisch gezien is er geen verschil tussen hen. Maar er zijn ideologische verschillen.

Ik zal erover praten in de context van PHP. Houd er rekening mee dat het HTTP-protocol indirect verband houdt met PHP, omdat het is gemaakt voor het uitwisselen van HTML-pagina's en PHP eenvoudigweg de mogelijkheden van beide uitbreidt.

GET-verzoek wordt gebruikt om gegevens te ontvangen en POST wordt gebruikt om te verzenden. (Houd er rekening mee dat ze technisch gezien hetzelfde werken).

Daarom hebben we in de context van PHP, gebaseerd op deze ideologie, het volgende gedaan:
1. Elke keer dat u PHP start, worden er standaard superglobal arrays ($_GET, $_POST) gemaakt.
2. Als er een vraagteken(?) in de queryreeks staat. Alles daarna wordt overwogen parameters GET-verzoek, worden ze gepresenteerd in het formaat "key"="value" en wordt het ampersand-teken (&) gebruikt als scheidingsteken.
Voorbeeld:
GET /index.php?name=Andrey&achternaam=Galkin
Dit is een queryreeks, er zijn twee parameters. deze parameters worden in de $_GET array geplaatst.
3. $_POST wordt op een andere manier ingevuld. de inhoud van deze array wordt gevuld vanuit de "request headers". Dat wil zeggen, vanaf een plek die duidelijk aan het zicht onttrokken is. De browser zorgt voor alle taken bij het maken van dergelijke headers. Hoewel er soms handmatig iets in de kopjes wordt aangepast.

Meestal wordt een postverzoek gebruikt in formulieren (om gegevens te verzenden).

We hebben bijvoorbeeld een inlogformulier met 2 velden: login en wachtwoord.

Laten we ons voorstellen dat we de GET-methode gebruiken. Vervolgens gaan we bij het indienen van het formulier naar het volgende adres /login.php?login=Andrey&password=123. U gaat ermee akkoord dat het op deze manier verzenden van dergelijke informatie helemaal niet veilig is. Iedereen kan uw browser openen en, door het siteadres in te voeren, uw wachtwoorden en logins uit de geschiedenis kunnen zien.

Maar als we de POST-methode specificeerden, zouden we het volgende verzoek ontvangen:
POST /login.php (login=Andrey&password=123) wat tussen haakjes staat, wordt verborgen en op geen enkele manier opgeslagen in de browser.

Om het samen te vatten:
GET is om een ​​bepaalde pagina in een bepaalde vorm te krijgen (sortering, huidige blogpagina, zoekbalk, enz.).
POST - voor het verzenden van gegevens die geen invloed hebben op de weergave van de pagina, in die zin dat deze gegevens alleen het resultaat van het script beïnvloeden (logins, wachtwoorden, creditcardnummers, berichten, enz.).

En nog een goed nieuws is dat ze bijvoorbeeld gecombineerd kunnen worden
POST /index.php?page=login (login=Andrey&password=123) Ik denk dat ik al genoeg heb uitgelegd wat hiervan zal komen en welke parameters in welke array terechtkomen.

1. HTTP-protocol. Invoering

Ik wil meteen één klein dingetje verduidelijken. Het vreselijke woordprotocol is niets meer dan een overeenkomst van veel mensen, op een mooi moment besloten mensen: "Laten we het zo doen, en dan komt alles goed." Er is niets om bang voor te zijn, alles is gewoon schandalig en we zullen deze schande nu onthullen. Wat is het HTTP-protocol en waarvoor wordt het gebruikt?

1.1 Cliënt en server

Er zijn geen wonderen in de wereld, en vooral niet in de wereld van programmeren en internet! Accepteer dit als een onwrikbare waarheid. En als het programma niet of niet naar wens werkt, is het hoogstwaarschijnlijk onjuist geschreven of bevat het fouten. Dus, hoe vraagt ​​de browser de server om iets te sturen? Ja, heel simpel! Je hoeft alleen maar een beetje te ontspannen en te genieten van het proces :-)

1.2. Het schrijven van ons eerste HTTP-verzoek

Als je denkt dat alles te ingewikkeld is, dan vergis je je. De mens is zo ontworpen dat hij simpelweg niet in staat is iets complexs te creëren, anders raakt hij er zelf in verward :-) Er is dus een browser en er is een webserver. De browser is altijd de initiator van gegevensuitwisseling. Een webserver zal nooit zomaar iets naar iemand sturen, zodat hij iets naar de browser stuurt; de browser moet erom vragen. Het eenvoudigste HTTP-verzoek kan er als volgt uitzien:


KRIJG http: //www.php.net/HTTP/1.0rnrn


* GET (vertaald uit het Engels betekent "krijgen") - het type verzoek, het type verzoek kan verschillen, bijvoorbeeld POST, HEAD, PUT, DELETE (we zullen er hieronder enkele bekijken).
* http://www.php.net/ - URI (adres) waarvan we op zijn minst wat informatie willen ontvangen (uiteraard hopen we de HTML-pagina te leren).
* HTTP/1.0 - het type en de versie van het protocol dat we zullen gebruiken bij de communicatie met de server.
* rn - het einde van de regel, dat twee keer moet worden herhaald, waarom zal even later duidelijk worden.

U kunt dit verzoek heel eenvoudig uitvoeren. Voer het programma telnet.exe uit, voer www.php.net in als host, specificeer poort 80 en typ eenvoudig dit verzoek door tweemaal op Enter te drukken als rnrn. Als reactie ontvangt u de HTML-code van de hoofdpagina van de site www.php.net.

1.3 Verzoekstructuur

Laten we eens kijken waaruit een HTTP-verzoek bestaat. Alles is vrij eenvoudig. Laten we beginnen met het feit dat een HTTP-verzoek een volledig betekenisvolle tekst is. Waaruit bestaat het in het algemeen? We zullen het HTTP 1.0-protocol beschouwen. Dus :


Aanvraag - Regel [ Algemeen - Kop | Verzoek - Kop | Entiteit - Koptekst ] rn [ Entiteit - Hoofdtekst ]


* Request-Line - verzoekregel
*

Formaat : "Methodeverzoek-URI HTTP-versiern"
* Methode - de methode waarmee de Request-URI-bron wordt verwerkt, kan GET, POST, PUT, DELETE of HEAD zijn.
* Request-URI - een relatieve of absolute link naar een pagina met een reeks parameters, bijvoorbeeld /index.html of http://www.myhost.ru/index.html of /index.html?a=1&b= qq. In het laatste geval ontvangt de server een verzoek met een reeks variabelen a en b met de bijbehorende waarden, en dient het “&” -teken - een ampersand - als scheidingsteken tussen de parameters.
* HTTP-versie - versie van het HTTP-protocol, in ons geval "HTTP/1.0".

Wij zijn zeer geïnteresseerd in GET- en POST-verwerkingsmethoden. Met de GET-methode kunt u eenvoudig parameters aan het script doorgeven, en met de POST-methode kunt u het indienen van formulieren emuleren.

Voor de GET-methode kan de Request-URI er als volgt uitzien: "/index.html?param1=1¶m2=2".

* General-Header - het grootste deel van de header.
Formaat:
Kan slechts twee parameters hebben: Datum of Pragma. Datum - Greenwich-datum in de notatie "Dag van de week, Dag Maand Jaar HH:MM:SS GMT", bijvoorbeeld "Tue, 15 Nov 1994 08:12:31 GMT" - datum waarop de aanvraag is aangemaakt. Pragma kan een enkele waarde zonder cache hebben, waardoor het cachen van pagina's wordt uitgeschakeld.

* Request-Header - deel van de header dat het verzoek beschrijft.

Request-Header kan de volgende parameters hebben : Toestaan, Autorisatie, Van, Indien-gewijzigd-sinds, Verwijzer, Gebruiker-agent.
In dit hoofdstuk zullen we de parameter Autorisatie niet beschouwen, omdat deze wordt gebruikt om toegang te krijgen tot particuliere bronnen, wat niet vaak nodig is. Op www.w3c.org kunt u leren hoe u zelf een geautoriseerde toegangsheader kunt maken.

* Toestaan ​​- stelt acceptabele verwerkingsmethoden in.
Formaat: "Toestaan: GET | HEADn".
De parameter wordt genegeerd bij het opgeven van de POST-verwerkingsmethode in Request-Line. Specificeert aanvaardbare verwerkingsmethoden voor verzoeken. Proxyservers wijzigen de parameter Allow niet en bereiken de server ongewijzigd.

* Van - e-mailadres van de persoon die het verzoek heeft verzonden.
Formaat: "Van: adderssrn".
Bijvoorbeeld: "Van: [e-mailadres beveiligd]".

* If-Modified-Since - geeft aan dat het verzoek sindsdien niet is gewijzigd.
Formaat: "Als-gewijzigd-sinds: datern"
Alleen gebruikt voor de GET-verwerkingsmethode. De datum wordt opgegeven in GMT in hetzelfde formaat als voor de parameter Datum in de General-Header.

* Verwijzer - een absolute link naar de pagina vanwaar het verzoek is geïnitieerd, d.w.z. een link naar de pagina vanwaar de gebruiker naar de onze is gekomen.
Formaat: "Verwijzer: urln".
Voorbeeld: "Verwijzer: www.host.ru/index.htmln".
* User-Agent - browsertype.
Bijvoorbeeld: 'Gebruikersagent: Mozilla/4.0n'

* Entity-Header - deel van de header dat de Entity-Body-gegevens beschrijft.
Dit deel van het verzoek specificeert parameters die de hoofdtekst van de pagina beschrijven. Entity-Header kan de volgende parameters bevatten: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header.

* Toestaan ​​- een parameter die lijkt op Toestaan ​​vanuit General-Header.

* Inhoudscodering - Type codering van entiteitslichaamsgegevens.
Formaat: "Inhoudscodering: x-gzip | x-comprimeren | ander type".
Voorbeeld: "Inhoudscodering: x-gzipn". Het teken "|". betekent het woord “of”, dat wil zeggen, dit of dat of dat, enz.
Een ander type kan aangeven hoe de gegevens worden gecodeerd, bijvoorbeeld voor de POST-methode: "Content-Encoding: application/x-www-form-urlencodedn".

* Inhoudslengte - het aantal bytes dat naar de entiteitsbody wordt verzonden. De waarde Content-Length heeft een geheel andere betekenis voor gegevens die in MIME-formaat worden verzonden, waarbij deze fungeert als parameter voor het beschrijven van een deel van de gegevens: "extern/entiteitslichaam". Geldige getallen zijn gehele getallen vanaf nul en hoger.
Voorbeeld: "Inhoudslengte: 26457n".

* Content-Type - type verzonden gegevens.
Bijvoorbeeld: "Inhoudstype: tekst/htmln".

* Verloopt - Tijd waarop de pagina uit de browsercache moet worden verwijderd.
Formaat: "Verloopt: gedateerd". Het datumformaat is hetzelfde als het datumformaat voor de parameter Datum uit General-Header.

* Laatst gewijzigd - tijdstip van de laatste wijziging van de verzonden gegevens.
Formaat: "Laatst gewijzigd: gedateerd". Het datumformaat is hetzelfde als het datumformaat voor de parameter Datum uit General-Header.

* Extention-header - deel van de header, dat bijvoorbeeld bedoeld kan zijn om te worden verwerkt door een browser of ander programma dat het document ontvangt. In dit deel kunt u uw parameters beschrijven in het formaat "ParameterName: parametervaluen". Deze parameters worden genegeerd als het clientprogramma niet weet hoe deze moet worden verwerkt.
Bijvoorbeeld: "Cookie: r=1rn" - stelt bekende cookies in voor de pagina.

En laten we nu, na zulke vreselijke woorden, proberen een beetje te kalmeren en te begrijpen wat we nodig hebben? Natuurlijk zullen we het begrijpen met voorbeelden.

Laten we ons voorstellen dat we een pagina van de site moeten krijgen door cookies door te geven, anders worden we gewoon als ongenode gasten gestuurd, en bovendien is het bekend dat je deze pagina pas mag bezoeken nadat je de hoofdpagina van de site hebt bezocht. plaats.

2 GET-methode

Laten we ons verzoek schrijven.


KRIJG http:
Gastheer: www. plaats. rennen

Koekje: inkomen = 1rn
rn


Dit verzoek vertelt ons dat we de inhoud van de pagina op http://www.site.ru/news.html willen ophalen met behulp van de GET-methode. Het veld Host geeft aan dat deze pagina zich op de server www.site.ru bevindt, het veld Referer geeft aan dat we voor nieuws kwamen van de hoofdpagina van de site, en het veld Cookie geeft aan dat we zo'n en zo'n cookie hebben gekregen. Waarom zijn de velden Host, Referer en Cookie zo belangrijk? Omdat normale programmeurs bij het maken van dynamische sites de gegevensvelden controleren die in scripts (inclusief PHP) verschijnen in de vorm van variabelen. Waar is dit voor? Om bijvoorbeeld te voorkomen dat de site wordt beroofd, d.w.z. ze hebben er geen programma op ingesteld voor automatisch downloaden, of zodat een persoon die de site bezoekt er altijd alleen vanaf de hoofdpagina naartoe kan gaan, enz.

Laten we ons nu voorstellen dat we de formuliervelden op de pagina moeten invullen en een verzoek vanuit het formulier moeten verzenden, laat er twee velden in dit formulier zijn: login en wachtwoord (login en wachtwoord) - en natuurlijk kennen we de login en wachtwoord.


KRIJG http: //www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0rn
Gastheer: www. plaats. rennen
Verwijzing: http: //www.site.ru/index.htmlrn
Koekje: inkomen = 1rn
rn


Onze login is "Petya Vasechkin" Waarom zouden we Petya%20Vasechkin schrijven? Dit komt omdat speciale tekens door de server kunnen worden herkend als tekenen van de aanwezigheid van een nieuwe parameter of het einde van een verzoek, enz. Daarom is er een algoritme voor het coderen van parameternamen en hun waarden om foutsituaties in het verzoek te voorkomen. Een volledige beschrijving van dit algoritme kun je hier vinden, en PHP heeft rawurlencode- en rawurldecode-functies voor respectievelijk coderen en decoderen. Ik zou willen opmerken dat PHP de decodering zelf uitvoert als er gecodeerde parameters in het verzoek zijn doorgegeven. Hiermee is het eerste hoofdstuk afgesloten van mijn kennismaking met het HTTP-protocol. In het volgende hoofdstuk zullen we kijken naar bouwverzoeken zoals POST (vertaald uit het Engels als “send”), wat veel interessanter zal zijn, omdat Dit is het type verzoek dat wordt gebruikt bij het verzenden van gegevens uit HTML-formulieren.

3. POST-methode.

In het geval van een HTTP POST-verzoek zijn er twee opties voor het overbrengen van velden uit HTML-formulieren, namelijk met behulp van het application/x-www-form-urlencoded en multipart/form-data algoritme. De verschillen tussen deze algoritmen zijn behoorlijk groot. Feit is dat het eerste type algoritme lang geleden is gemaakt, toen de HTML-taal nog niet voorzag in de mogelijkheid om bestanden via HTML-formulieren over te dragen. Laten we deze algoritmen eens bekijken met voorbeelden.

3.1 Inhoudstype: application/x-www-form-urlencoded.

We schrijven een verzoek dat lijkt op ons GET-verzoek om de login en het wachtwoord over te dragen, dat in het vorige hoofdstuk werd besproken:


POSThttp: //www.site.ru/news.html HTTP/1.0rn
Gastheer: www. plaats. rennen
Verwijzing: http: //www.site.ru/index.htmlrn
Koekje: inkomen = 1rn
Inhoud - Type: applicatie / x - www - formulier - urlencodedrn
Inhoud - Lengte: 35rn
rn


Hier zien we een voorbeeld van het gebruik van de headervelden Content-Type en Content-Length. Content-Length vertelt hoeveel bytes het datagebied in beslag zal nemen, dat van de header wordt gescheiden door een andere line feed rn. Maar de parameters die voorheen in de Request-URI voor een GET-verzoek werden geplaatst, bevinden zich nu in de Entity-Body. Het is duidelijk dat ze op precies dezelfde manier zijn gevormd, je hoeft ze alleen maar na de titel te schrijven. Ik zou nog een belangrijk punt willen opmerken: niets verhindert dat, gelijktijdig met de set parameters in de Entity-Body, parameters met andere namen in de Request-URI worden geplaatst, bijvoorbeeld:


POSThttp: //www.site.ru/news.html?type=gebruiker HTTP/1.0rn
.....
rn
login = Petya % 20Vasechkin & wachtwoord = qq


3.2 Inhoudstype: meerdelige/formuliergegevens

Zodra de internetwereld besefte dat het leuk zou zijn om bestanden via formulieren te verzenden, begon het W3C-consortium met het verfijnen van het POST-verzoekformaat. Tegen die tijd was het MIME-formaat (Multipurpose Internet Mail Extensions - multifunctionele protocolextensies voor het genereren van e-mailberichten) al op grote schaal gebruikt. Om het wiel niet opnieuw uit te vinden, hebben we daarom besloten een deel van dit berichtgeneratieformaat te gebruiken om berichten te genereren. POST-verzoeken in het HTTP-protocol.

Wat zijn de belangrijkste verschillen tussen dit formaat en het type application/x-www-form-urlencoded?

Het belangrijkste verschil is dat Entity-Body nu kan worden onderverdeeld in secties, die gescheiden zijn door grenzen (boundary). Het meest interessante is dat elke sectie zijn eigen header kan hebben om de gegevens te beschrijven die erin zijn opgeslagen, d.w.z. in één verzoek kunt u verschillende typen gegevens overbrengen (net als bij een postbrief kunt u bestanden tegelijk met tekst overbrengen).

Dus laten we aan de slag gaan. Laten we opnieuw hetzelfde voorbeeld bekijken met de overdracht van login en wachtwoord, maar nu in een nieuw formaat.


POSThttp: //www.site.ru/news.html HTTP/1.0rn
Gastheer: www. plaats. rennen
Verwijzing: http: //www.site.ru/index.htmlrn
Koekje: inkomen = 1rn

Inhoud - Lengte: 209rn
rn
-- 1BEF0A57BE110FD467Arn
Inhoud - Dispositie: vorm - gegevens; naam = "inloggen" rn
rn
Petya Vasechkinrn
-- 1BEF0A57BE110FD467Arn
Inhoud - Dispositie: vorm - gegevens; naam = "wachtwoord" rn
rn
qqrn
-- 1BEF0A57BE110FD467A -- rn


Laten we nu begrijpen wat er geschreven staat. :-) Ik heb met opzet enkele rn-tekens vetgedrukt gemarkeerd, zodat ze niet samenvloeien met de gegevens. Als je goed kijkt, zie je het grensveld na Content-Type. Dit veld specificeert het sectiescheidingsteken - rand. Als rand kan een reeks bestaande uit Latijnse letters en cijfers worden gebruikt, evenals enkele andere symbolen (helaas weet ik niet meer welke andere). In de hoofdtekst van het verzoek wordt “--” toegevoegd aan het begin van de grens, en het verzoek eindigt met een grens, waaraan ook de tekens “--” worden toegevoegd aan het einde. Ons verzoek bestaat uit twee delen: het eerste beschrijft het inlogveld en het tweede beschrijft het wachtwoordveld. Content-Disposition (het gegevenstype in de sectie) zegt dat dit gegevens uit het formulier zijn, en het naamveld specificeert de naam van het veld. Dit is waar de sectiekop eindigt en wat volgt is het sectiegegevensgebied waarin de veldwaarde wordt geplaatst (de waarde hoeft niet te worden gecodeerd!).

Ik zou uw aandacht willen vestigen op het feit dat u Content-Length niet hoeft te gebruiken in sectiekoppen, maar dat u Content-Length moet gebruiken in de verzoekheader en de waarde ervan is de grootte van de gehele Entity-Body, die verschijnt na de tweede rn volgende Inhoud-Lengte: 209rn. Die. Entity-Body wordt van de header gescheiden door een extra regeleinde (dat ook in secties te zien is).

Laten we nu een verzoek schrijven om een ​​bestand over te dragen.


POSThttp: //www.site.ru/postnews.html HTTP/1.0rn
Gastheer: www. plaats. rennen
Verwijzing: http: //www.site.ru/news.htmlrn
Koekje: inkomen = 1rn
Inhoudstype: meerdelige/formuliergegevens; grens = 1BEF0A57BE110FD467Arn
Inhoud - Lengte: 491rn
rn
-- 1BEF0A57BE110FD467Arn
Inhoud - Dispositie: vorm - gegevens; naam = "nieuws_header" rn
rn
Voorbeeld nieuwsrn
-- 1BEF0A57BE110FD467Arn
Inhoud - Dispositie: vorm - gegevens; naam = "nieuwsbestand"; bestandsnaam = "nieuws.txt" rn
Inhoud - Type: applicatie / octet - streamrn
Inhoud - Overdracht - Codering: binair
rn
Hier is het nieuws, die in het nieuwsbestand staat. txtrn
-- 1BEF0A57BE110FD467A -- rn


In dit voorbeeld verzendt de eerste sectie de nieuwstitel en de tweede sectie het bestand news.txt. Als u goed oplet, ziet u de velden bestandsnaam en inhoudstype in het tweede gedeelte. Het veld bestandsnaam specificeert de naam van het bestand dat wordt verzonden, en het veld Content-Type specificeert het type van dit bestand. Application/octet-stream geeft aan dat dit een standaard datastroom is, en Content-Transfer-Encoding: binary geeft aan dat dit binaire gegevens zijn, die op geen enkele manier gecodeerd zijn.

Een heel belangrijk punt. De meeste CGI-scripts zijn geschreven door slimme mensen, dus controleren ze graag het type van het binnenkomende bestand, dat zich in het Content-Type bevindt. Waarvoor? Meestal wordt het uploaden van bestanden op websites gebruikt om afbeeldingen van de bezoeker te ontvangen. De browser probeert dus zelf te bepalen wat voor soort bestand de bezoeker wil verzenden en voegt het juiste Content-Type in het verzoek in. Het script controleert dit bij ontvangst en negeert dit bestand als het bijvoorbeeld geen gif of jpeg is. Zorg daarom bij het “handmatig maken” van een aanvraag voor de waarde Content-Type, zodat deze het formaat van het overgedragen bestand het dichtst benadert.

Afbeelding/gif voor gif
afbeelding/jpeg voor jpeg
afbeelding/png voor png
image/tiff voor tiff (dat uiterst zelden wordt gebruikt, het formaat is te ruim)

In ons voorbeeld wordt een verzoek gegenereerd waarin een tekstbestand wordt overgedragen. Op dezelfde manier wordt een verzoek voor de overdracht van een binair bestand gegenereerd.

4. Naschrift.

Ik denk dat het niet de moeite waard is om in detail te praten over het verzenden van verzoeken naar de server. Dit is een kwestie van puur RHP-technologie :-). Het volstaat om het gedeelte over functies voor het werken met sockets of over de functies van de CURL-module in de officiële PHP-documentatie aandachtig te lezen.

Uit het bovenstaande hoop ik dat het nu duidelijk is waarom de vraag luidt: “Hoe kan ik een POST-verzoek genereren met behulp van de headerfunctie?” - zinloos. De functie header(string) voegt alleen een item toe aan de verzoekheader, maar niet aan de hoofdtekst van het verzoek.

Rug

HTTP is een hypertext-transportprotocol, een van de protocollen in de TCP/IP-stack. Het protocol is oorspronkelijk gemaakt voor het verzenden en ontvangen van HTML-pagina's, maar wordt nu goed gebruikt voor gedistribueerde informatiesystemen. Het is een van de meest gebruikte protocollen op het World Wide Web.

Figuur - 1

Gebaseerd op een verzoek/antwoord-schema. Wanneer een client een verzoek naar de server verzendt, kan hij dit doen met behulp van 3 soorten verzoeken: GET, PUT en POST.

GET HTTP-protocolverzoek

KRIJGEN is een klantverzoek om informatie. De webbrowser van de client verzendt een GET-bericht om pagina's op te halen. Het verzoek bestaat uit twee delen:

  • vraagtekenreeks
  • kopteksten

Een GET-verzoek heeft geen databody, maar dit betekent niet dat er geen gegevens naar de server kunnen worden verzonden. Met behulp van speciale parameters in de URL-regel kunt u gegevens naar de server overbrengen. Teken ? achter het domein in de URL betekent dat er verdere parameters worden doorgegeven. Figuur 2 laat precies zien welke informatie de browser naar de server verzendt.

Figuur - 2

POST- en PUT HTTP-protocolverzoek

Deze twee methoden zijn geïmplementeerd om informatie naar de webserver te verzenden. Met behulp van speciale webformulieren sturen we ze, nadat we ze hebben ingevuld, naar de server via de POST-methode. PUT uploadt bronnen of gegevens naar een webserver (foto, video).

HTTP is geen veilig protocol en POST-berichten kunnen worden onderschept en gelezen omdat het niet gecodeerd is. Om de veiligheid van de gegevensoverdracht via de POST-methode te garanderen, wordt het HTTPS-protocol gebruikt. Het codeert gegevens en kan authenticatie uitvoeren. Het implementeert ook aanvullende eisen voor de doorgifte van informatie tussen de transport- en applicatielagen.

De belangrijkste verschillen tussen de POST- en GET-methoden worden weergegeven in Tabel 1.

Figuur 3 toont de basisregels die u moet volgen bij het kiezen van de GET- of POST-methode om werk op uw server te implementeren.

Ik wilde al heel lang een artikel schrijven waarin ik erover zou praten verschil tussen POST-methode en GET-methode, maar op de een of andere manier verschenen er andere onderwerpen en ik schakelde ernaar over. En nu is het eindelijk tijd om dit onderwerp te bespreken, omdat mensen het vaak gewoon niet weten wat is het verschil tussen POST en GET.

Om duidelijker weer te geven verschil tussen POST en GET, geef ik een tabel die laat zien door welke kenmerken ze verschillen.

Op basis van dit kenmerk kunnen we een conclusie trekken wanneer te gebruiken NA en wanneer KRIJGEN. Bijvoorbeeld als de gebruiker een bladwijzer wil maken voor de gegenereerde pagina. Dan zou generatie moeten plaatsvinden KRIJG verzoek, anders kunt u geen bladwijzer voor de pagina maken. Nog een voorbeeld: bij het doorgeven van login en wachtwoord kunt u de methode niet instellen KRIJGEN, omdat het gebaseerd is op het verzenden van gegevens via de adresbalk. Anders, na het indrukken van de knop " Indienen", zoiets verschijnt in de adresbalk: " http://mysite.ru/login.php?log=User&pass=123456", - en iedereen kan het wachtwoord zien, wat natuurlijk niet mag worden toegestaan. Daarom moet je hier de methode gebruiken NA.

Vergeet ook niet dat de grootte van de gegevens die door de methode kunnen worden doorgegeven NA, een orde van grootte groter dan wanneer deze door de methode wordt verzonden KRIJGEN. Analyseer in het algemeen deze tabel en trek een conclusie: welke methode voor gegevensoverdracht in een bepaald geval moet worden gebruikt. Uit eigen naam zal ik dat toevoegen 80% gevallen moeten worden gebruikt NA, maar vergeet niet dat dit verre van is 100% .

Heeft u vragen of wilt u reageren op dit artikel, dan kunt u onderaan de pagina uw reactie achterlaten.

Opmerkingen (15):

dsmt 12.05.2013 14:00:18

Goedemiddag Ik heb zoiets als dit nodig bij het omleiden: header("Location: test.php"); $_POST-waarde is doorgegeven aan deze pagina. De pagina waarvandaan deze waarde moet worden verzonden, heeft geen formulieren. Die. het verwerkt eenvoudigweg de gegevens en genereert een specifiek verzoek. Op dit moment laat ik de overdracht gebeuren met behulp van cookies. Maar ik weet niet zeker of het veilig is. Of heb ik het mis? De gegevens die worden verzonden, mogen niet zichtbaar zijn voor gebruikers.

Antwoord

Alex_ 23.11.2013 23:56:10

Goede dag :), Michail! Ik probeer een plug-in in PHP te schrijven en kwam er natuurlijk achter dat ik geen kennis heb. Vandaar de vraag: als een bepaalde site (betalingssysteem), na mijn acties van mijn kant, mij gegevens naar de site op een specifieke pagina stuurt met behulp van de POST-methode, moet ik deze dan zien als ik print_r($_POST) in het script schrijf ? ? Alleen in mijn geval, bijvoorbeeld print_r($_SERVER); je kunt zien welke gegevens zich in de $_SERVER-array bevinden, maar $_POST is leeg, dat wil zeggen dat de gegevens niet aankomen of dat ik een profane kijk heb op hoe de zaken werkelijk zijn.

Antwoord

23.11.2013 23:59:31

Hallo, Alexander Meestal verzenden betalingssystemen gegevens in omgekeerde volgorde, in gecodeerde vorm en met behulp van veilige protocollen. Het hangt dus allemaal af van het betalingssysteem. Schrijft u een betaalmodule voor een specifiek systeem? Gelieve uw vragen te verduidelijken, anders kan ik u niet helpen.

Antwoord

Alex_ 24.11.2013 02:00:41

Hallo Alexander, bedankt voor je reactie. Ik ben een plug-in aan het schrijven voor cms Wordpress, waarbij ik werk met het betalingssysteem interkassa.com. Als de aankoop succesvol is, wordt u doorgestuurd naar de succesvolle betalingspagina http://my_site/success. Volgens de documentatie komen gegevens die voor mij zichtbaar zijn op deze pagina terecht. Dat wil zeggen, in de instellingen heb ik de GET-overdrachtsmethode geselecteerd en er komt een lange URL, deze link en daarin de parameters http://my_site/success/?&ik_betaling_id=1&ik_paysystem_alias=yandexdengir, alles is zoals het zou moeten zijn. Ik probeerde de POST-transmissiemethode te selecteren en vervolgens schreef ik in het script bijvoorbeeld if (isset($_POST["ik_trans_id"])) echo $_POST["ik_trans_id"]. En het werkte. Vervolgens ben ik met STATUS url gaan werken omdat dan ik_sign_hash binnenkomt, die door de intercash wordt gegenereerd met behulp van een geheime sleutel (die bij mij en de intercash bekend is) en deze keer als (isset($_POST["ik_sign_hash"]) niet werkt omdat het er niet is. Op mijn site is er een plug-in (die doet niet alles zoals we zouden willen) geschreven in OOP (ik ben nog steeds ver verwijderd van het niveau van degene die dit heeft geschreven, misschien is het daarom niet voor de hand liggend). wat daar wordt gebruikt). Deze plug-in verwerkt alles en berekent de hash op zijn kant, omdat ik opzettelijk de geheime sleutel heb gewijzigd (in de plug-in-instellingen) en er een e-mail is verzonden met een melding over onjuist overgedragen gegevens (de hashes kwamen niet overeen) en een verzoek om contact op te nemen met de sitebeheerder. Zoiets.

Antwoord

24.11.2013 02:09:28

Nou, ik heb je plug-in niet gezien, dus ik zal niets specifieks zeggen. Wat betreft de eenvoudige implementatie...Ik heb de interkassa API niet bestudeerd. Je kunt hier een eenvoudige oplossing zien: http://goo.gl/rFnpNc In wezen is het hetzelfde in alle systemen. Ik werk meestal met een robotachtige kassa of onpei, dus neem me niet kwalijk. Over het algemeen is de structuur ongeveer zo. Je moet een implementatie schrijven in overeenstemming met de API-documentatie http://www.interkassa.com/faq.php, zie hier de Interkassa-sectie door de ogen van een programmeur en beheerder + Daar. in de laatste vraag staat technische documentatie voor het downloaden en kleine dingen over de API in het algemeen

Antwoord

Alex_ 24.11.2013 02:16:40

Bedankt Alexander. Ik zag, ik las dit allemaal, ik probeer het nu al een paar dagen en ik google het en ik denk dat ik misschien iets niet begrijp :). http://goo.gl/rFnpNc - en dit is een plug-in van Andrey Morkovin, niet volledig geschreven (waarschijnlijk om niet alle geheimen prijs te geven, is het script nu betaald). Op basis hiervan zijn verschillende videolessen gemaakt over het schrijven van plug-ins op WP. Deze plug-in http://www.icprojects.net/paid-downloads-plugin.html is beschikbaar in betaalde en gratis versies. In de gratis versie is alleen PAYPAL-betaling beschikbaar. maar het is er allemaal en als je een paar waarden verandert, komt de Interkassa-modus in de bètaversie beschikbaar.

Antwoord

24.11.2013 02:23:00

Ja, ik ben me hiervan bewust. Er lag gewoon een plug-in. Of deze nu compleet was of niet, hij werkte. Misschien is er ergens een versie die $ 40 kost. rondslingeren. Ik zal in ieder geval niets specifieks aanbevelen. Lees de Interkassa API-documentatie. En de algoritmen zijn overal hetzelfde. Schrijf een handler die gegevens in gecodeerde vorm verzendt en deze in dezelfde vorm ontvangt en ontsleutelt. Je kunt de oplossing van Levchuk bekijken op zijn wppage;) Als ik tijd heb, zal ik dit onderwerp in meer detail bekijken



GERELATEERDE ARTIKELEN

Wij raden aan

Copyright 2024 - Computer- en laptopreparatie. Videokaarten, harde schijven, internet, monitoren.