thuis-ramen-Parameters van get request php. Leren werken met GET- en POST-verzoeken
Parameters van get request php. Leren werken met GET- en POST-verzoeken
Laatste update: 1/11/2015
De get-methode doet een GET-verzoek aan de server, dat wil zeggen dat alle verzoekgegevens worden doorgegeven in de queryreeks. Het accepteert de volgende parameters:
url: een vereiste parameter die het adres bevat van de bron waartoe het verzoek toegang zal verkrijgen
data: een optionele parameter die een eenvoudig javascript-object of string bevat die samen met het verzoek naar de server wordt verzonden
success(data, textStatus, jqXHR) : optionele parameter - een callback-functie die wordt uitgevoerd wanneer het verzoek succesvol is. Er kunnen drie parameters nodig zijn: data - gegevens ontvangen van de server, textStatus - verzoekstatus en jqXHR - een speciaal jQuery-object dat een uitgebreide versie van het object vertegenwoordigt XMLHttpRequest.
dataType: een optionele parameter die het gegevenstype als een tekenreeks bevat, zoals 'xml' of 'json'
Bij uitvoer retourneert de get-methode een jqXHR-object dat de aanvraaggegevens zal inkapselen. We zullen dit object later in meer detail bekijken.
Laten we dus het voorbeeld uit de vorige paragraaf herschrijven met behulp van de get-methode:
Hier worden de eerste twee parameters gebruikt: het bronadres en de callback-functie. In deze functie ontvangen we de gegevens die we van de server ontvangen als de gegevensparameter en laden deze als opmaak in het selectie-element ($("#news").html(data);). We zouden in wezen hetzelfde kunnen doen met behulp van de laadmethode.
Gegevens verzenden
Met behulp van de dataparameter kunnen we aanvullende gegevens verzenden. U kunt bijvoorbeeld een verzoek verzenden om een element uit de database op te halen op basis van id:
$.get("ajax.php", (id: "1"));
En aangezien bij een GET-verzoek alle gegevens in de queryregel worden verzonden, zal deze code er als volgt uitzien:
$.get("ajax.php?id=1");
Dienovereenkomstig kunnen we aan de serverzijde deze parameter ontvangen en er enkele acties mee uitvoeren, bijvoorbeeld een element uit de database halen voor een bepaalde ID:
Het gegevenstype gebruiken
Deze situatie doet zich vaak voor wanneer de server gegevens in een bepaald formaat verzendt, bijvoorbeeld json of xml. Het php-bestand aan de serverkant zou er dus als volgt uit kunnen zien:
"Start van het Russische kampioenschap", "date"=>"13/07/2013")); ?>
In dit geval retourneert het een json-object. Vervolgens kunnen we aan de clientzijde expliciet het gegevenstype specificeren en de ontvangen gegevens verwerken in de functie:
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 verzenden? 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 krijgt 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 de pagina 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 gaan we niet in op de parameter Autorisatie, 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-compress | 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.
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.
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 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:
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 beginnen. Laten we opnieuw hetzelfde voorbeeld bekijken met de overdracht van login en wachtwoord, maar nu in een nieuw formaat.
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. Een reeks bestaande uit Latijnse letters en cijfers, evenals enkele andere symbolen (helaas weet ik niet meer welke andere) kunnen als rand worden gebruikt. 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 in de verzoekkop wel en de waarde ervan is de grootte van de gehele Entity-Body, die verschijnt na de tweede rn volgende inhoudslengte: 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 er daarom bij het “handmatig maken” van een verzoek voor dat de waarde Content-Type zo wordt ingesteld dat 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 pure 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
De laatste tijd zie ik steeds vaker vragen op het PHPClub-hoofdforum over het maken van POST- en GET-verzoeken, evenals vragen over het onderwerp: "Hoe kan ik een POST-verzoek genereren met behulp van de headerfunctie." Ik ben van mening dat de noodzaak om de puntjes op de i te zetten bij het gebruik van deze technologie al lang had moeten plaatsvinden, omdat beginnende programmeurs de principes van het web als zodanig simpelweg niet begrijpen. Laten we dus beginnen aan onze reis door de wereld van het HTTP-protocol.
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 verzenden? 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.0\r\n\r\n
GET (vertaald uit het Engels betekent "krijgen") - een 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 is het type en de versie van het protocol dat we zullen gebruiken bij de communicatie met de server.
\r\n is het einde van de regel, die twee keer herhaald moet worden, 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 \r\n\r\n. 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:
Verzoeklijn [Algemene kop | Verzoekkop | Entiteitskop ]\r\n[ Entiteitslichaam ]
Verzoeklijn- queryreeks
Formaat: "Methodeverzoek-URI HTTP-versie\r\n"
Methode- De methode waarmee de Request-URI-bron wordt verwerkt, kan GET, POST, PUT, DELETE of HEAD zijn.
Aanvraag-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".
Algemeen-header- het grootste deel van de titel. 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.
Verzoek-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 aanvaardbare verwerkingsmethoden vast. Formaat: "Toestaan: GET | HEAD\n". 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: adderss\r\n". Bijvoorbeeld: "Van: [e-mailadres beveiligd]\r\n".
Indien-gewijzigd-sinds- geeft aan dat het verzoek sindsdien niet is gewijzigd. Formaat: "Indien-gewijzigd-sinds: datum\r\n" 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 werd geïnitieerd, d.w.z. een link naar de pagina vanwaar de gebruiker naar de onze kwam. Formaat: "Verwijzer: url\n". Voorbeeld: "Verwijzer: www.host.ru/index.html\n".
Entiteit-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. Entiteitskop kan de volgende parameters bevatten: Toestaan, Inhoudscodering, Inhoudslengte, Inhoudstype, Verloopt, Laatst gewijzigd, extensie-header.
Toestaan- een parameter vergelijkbaar met Allow from General-Header.
Inhoudscodering- gegevenscoderingstype Entity-Body. Formaat: "Inhoudscodering: x-gzip | x-comprimeren | ander type\n". Voorbeeld: "Inhoudscodering: x-gzip\n". 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-urlencoded\n".
Inhoud lengte- het aantal bytes dat naar de Entiteitsinstantie 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: 26457\n".
Inhoudstype- type verzonden gegevens. Bijvoorbeeld: "Inhoudstype: tekst/html\n".
Verloopt- Het tijdstip waarop de pagina uit de browsercache moet worden verwijderd. Formaat: "Verloopt: datum\n". 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: datum\n". Het datumformaat is hetzelfde als het datumformaat voor de parameter Datum uit General-Header.
extensie-header- een 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: parameterwaarde\n". Deze parameters worden genegeerd als het clientprogramma niet weet hoe deze moet worden verwerkt. Bijvoorbeeld: "Cookie: r=1\r\n" - 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.
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.
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 is te vinden, en PHP heeft de 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.
Hier zien we een voorbeeld van het gebruik van de headervelden Content-Type en Content-Length. Content-Length vertelt hoeveel bytes het datagebied zal bezetten, dat van de header wordt gescheiden door nog een regeleinde \r\n. 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:
POST http://www.site.ru/news.html?type=user HTTP/1.0\r\n
..... \r\n 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 beginnen. Laten we opnieuw hetzelfde voorbeeld bekijken met de overdracht van login en wachtwoord, maar nu in een nieuw formaat.
POST http://www.site.ru/news.html HTTP/1.0\r\n Host: www.site.ru\r\n Verwijzing: http://www.site.ru/index.html\r\n Cookie: inkomen=1\r\n
Laten we nu begrijpen wat er geschreven staat. :-) Ik heb speciaal enkele \r\n-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. Een reeks bestaande uit Latijnse letters en cijfers, evenals enkele andere symbolen (helaas weet ik niet meer welke andere) kunnen als rand worden gebruikt. 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 in de verzoekheader wel en de waarde ervan is de grootte van de gehele Entity-Body, die verschijnt na de tweede \ r\n volgende inhoudslengte: 209\ r\n. 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.
POST http://www.site.ru/postnews.html HTTP/1.0\r\n Host: www.site.ru\r\n Verwijzing: http://www.site.ru/news.html\r\n Cookie: inkomen=1\r\n Inhoudstype: meerdelige/formuliergegevens; grens=1BEF0A57BE110FD467A\r\n Inhoudslengte: 491\r\n \r\n --1BEF0A57BE110FD467A \r\n Inhoud-dispositie: formuliergegevens; naam = "nieuws_header" \r\n \r\n Voorbeeld nieuws \r\n --1BEF0A57BE110FD467A \r\n Inhoud-dispositie: formuliergegevens; naam = "nieuwsbestand"; bestandsnaam = "nieuws.txt" \r\n Inhoudstype: applicatie/octet-stream \r\n Content-overdracht-codering: binair \r\n \r\n En hier is het nieuws, dat zich in het bestand news.txt bevindt \r\n --1BEF0A57BE110FD467A-- \r\n
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 er daarom bij het “handmatig maken” van een verzoek voor dat de waarde Content-Type zo wordt ingesteld dat deze het formaat van het overgedragen bestand het dichtst benadert.
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.
Er is nog een ander type verzoek - Content-Type: multipart/mixed, ik hoop dat je na het lezen van dit artikel dit type zelf gemakkelijk zult begrijpen. Je kunt het gedetailleerd bestuderen
Het is je misschien opgevallen dat je op de meeste sites de volgende adressen kunt zien:
Http://site/index.php?blog=2 Hier kun je, zelfs zonder php te kennen, raden dat we toegang hebben tot een bestand index.php Maar weinig mensen weten wat er na het vraagteken komt. Het is vrij eenvoudig:?blog=2
Dit is een declaratie van de globale variabele "$_GET["blog"]" met de waarde "2". Daarom geef ik een variabele door aan het script die verantwoordelijk is voor het weergeven van informatie uit de database. Laten we een klein script schrijven waarin je alles duidelijk kunt zien: if(isset($_GET["blog"])) ( } ?>
echo $_GET["blog"];
We gebruiken de voorwaardeoperator if() en de volgende regel wordt als voorwaarde gebruikt:
Isset($_GET["blog"])
Met isset() kun je uitzoeken of de variabele die tussen haakjes is opgegeven, bestaat, dat wil zeggen dat de voorwaarde die ik in de code heb beschreven als volgt klinkt: Als de variabele $_GET["blog"] bestaat, geef dan de inhoud van deze variabele weer op het scherm. Dit is wat er gebeurde: Ik denk dat het duidelijk is dat er een globale variabele wordt gemaakt$_GET met de ID die we in de adresbalk hebben aangegeven ()
Nu wil ik één punt verduidelijken. Stel dat we twee variabelen moeten declareren, hoe moet dat dan gebeuren? De eerste variabele wordt gedeclareerd na het vraagteken "?" De tweede variabele wordt gedeclareerd na het “&” teken ( Eerlijk gezegd weet ik niet wat dit teken is), hier is een voorbeelddeclaratie van drie variabelen:
Http://site/index.php?a=1&b=2&c=3
Hier is de uitvoercode:
if(isset($_GET["a"]) AND isset($_GET["b"]) AND isset($_GET["c"])) ( echo $_GET["a"]." "; echo $_GET["b"]." "; echo $_GET["c"]." "; } ?>
De toestand klinkt als volgt:
Als er een globale variabele $_GET["a"] en een globale variabele $_GET["b"] en een globale variabele $_GET["c"] is, geef deze dan op het scherm weer, hier is het resultaat:
Formulieren
Voordat we er zijn na verzoeken, moet u begrijpen wat formulieren zijn? Waarom is het nodig? Omdat de globale variabele $_POST[""] via formulieren wordt aangemaakt. Wat is vorm? Dit zijn velden waarin de gebruiker bepaalde informatie kan invoeren. Er zijn velden met één regel, grote velden, maar ook keuzerondjes en selectievakjes. Laten we alles in volgorde bekijken...
Het formulier is een tag:
Het formulier heeft attributen, ik zal de meest voorkomende opsommen:
Laten we een formulier maken:
Ik heb het bestand ingesteld als een handlerbestand test.php omdat ik daarin voorbeelden voor je schrijf. Ik heb de verzendmethode ingesteld op posten, omdat dit de methoden zijn die in 99,9% van de gevallen worden gebruikt. Ik heb ons formulier ook een naam gegeven: formulier
Laten we nu een duik nemen in de wereld van vormelementen. Het eerste dat u moet begrijpen, is dat bijna alle elementen een tag zijn het enige verschil zit in het attribuut type bij deze labels. Ik zal de gebruikte formulierelementen opsommen:
Ik weet zeker dat je dergelijke velden meer dan eens hebt gezien, dus hier is wat ze zeggen: “geen commentaar”
Laten we nu een kleine trainingsvragenlijst maken, waarmee we verder zullen werken. Onze taak is om een kleine vragenlijst te maken die ons de naam vertelt van de persoon die de vragenlijst invult, het geslacht, het land waar hij of zij vandaan komt, de favoriete kleur en een tekstveld waarin de gebruiker iets over zichzelf kan toevoegen. Dit is wat ik heb:
