POST (HTTP) - POST (HTTP)

I computing er POST en anmodningsmetode, der understøttes af HTTP, der bruges af World Wide Web . Ved design anmoder POST -anmodningsmetoden om, at en webserver accepterer de data, der er indeholdt i forespørgselsmeddelelsens brødtekst, sandsynligvis til lagring af dem. Det bruges ofte, når du uploader en fil, eller når du sender en udfyldt webformular .

I modsætning hertil henter HTTP GET -anmodningsmetoden oplysninger fra serveren. Som en del af en GET -anmodning kan nogle data videregives inden for webadressens forespørgselsstreng ved at angive (f.eks.) Søgeudtryk, datointervaller eller andre oplysninger, der definerer forespørgslen.

Som en del af en POST -anmodning kan en vilkårlig mængde data af enhver type sendes til serveren i forespørgselsmeddelelsens brødtekst. Et overskriftsfelt i POST -anmodningen angiver normalt meddelelsesorganets internetmedietype.

Udstationering af data

World Wide Web og HTTP er baseret på en række anmodningsmetoder eller 'verber', herunder POST og GET samt PUT, DELETE og flere andre. Webbrowsere bruger normalt kun GET og POST, men RESTful online apps gør brug af mange af de andre. POSTs sted inden for rækkevidde af HTTP -metoder er at sende en repræsentation af en ny dataenhed til serveren, så den vil blive gemt som en ny underordnet ressource identificeret af URI . For eksempel kan det for URI forventes http://example.com/customers, at POST -anmodninger repræsenterer nye kunder, hver med navn, adresse, kontaktoplysninger og så videre. Tidlige webstedsdesignere forvildede sig fra dette originale koncept på to vigtige måder. For det første er der ingen teknisk grund for en URI til tekstmæssigt at beskrive webressourcen underordnet, som POST -data vil blive gemt til. Faktisk, medmindre der gøres en indsats, vil den sidste del af en URI mere sandsynligt beskrive webapplikationens behandlingsside og dens teknologi, som f.eks . For det andet i betragtning af de fleste webbrowsers naturlige begrænsning til kun at bruge GET eller POST, følte designere behovet for at omformulere POST til at udføre mange andre dataoverførsels- og datahåndteringsopgaver, herunder ændring af eksisterende poster og deres sletning. http://example.com/applicationform.php

Nogle indflydelsesrige forfatteres bestræbelser på at afhjælpe det første punkt begyndte allerede i 1998. Webapplikationsrammer som Ruby on Rails og andre gør det lettere for designere at give deres brugere semantiske webadresser . Med hensyn til det andet punkt er det muligt at bruge scripting på klientsiden eller skrive selvstændige apps til at gøre brug af de andre HTTP-metoder, hvor de er relevante, men uden for dette fortsætter de fleste webformularer, der sender eller ændrer serverdata, fortsat at bruge POST til formålet.

Det er ikke at sige, at enhver webform skal angive method="post"i sit åbningstag . Mange formularer bruges til mere præcist at angive hentning af oplysninger fra serveren uden nogen hensigt om at ændre hoveddatabasen. Søgeformularer er f.eks. Ideelt egnet til at have method="get"specificeret.

Der er tidspunkter, hvor HTTP GET er mindre egnet, selv til datahentning. Et eksempel på dette er, når der skal specificeres en masse data i URL'en. Browsere og webservere kan have grænser for længden af ​​URL'en, som de håndterer uden afkortning eller fejl. Procent-kodning af reserverede tegn i webadresser og forespørgselsstrenge kan øge deres længde betydeligt, og mens Apache HTTP-server kan håndtere op til 4.000 tegn i en URL, er Microsoft Internet Explorer begrænset til 2.048 tegn i enhver URL. På samme måde bør HTTP GET ikke bruges, hvor følsomme oplysninger, f.eks. Brugernavne og adgangskoder, skal indsendes sammen med andre data for at anmodningen kan udfyldes. Selvom HTTPS bruges, hvilket forhindrer data i at blive opsnappet under transit, vil browserhistorikken og webserverens logfiler sandsynligvis indeholde den fulde URL i ren tekst, som kan blive afsløret, hvis et af systemerne er hacket. I disse tilfælde skal HTTP POST bruges.

Brug til at indsende webformularer

Når en webbrowser sender en POST-anmodning fra et webformularelement , er standardtypen for internetmedier " application/x-www-form-urlencoded ". Dette er et format til kodning af nøgle-værdipar med muligvis dublerede nøgler. Hvert nøgleværdipar adskilles med et '&'-tegn, og hver nøgle adskilles fra værdien med et '='-tegn. Nøgler og værdier undslippes begge ved at erstatte mellemrum med '+'- tegnet og derefter bruge procent-kodning på alle andre ikke- alfanumeriske tegn.

For eksempel par-nøgle-værdien

Name: Gareth Wylie
Age: 24
Formula: a+b == 21

er kodet som

Name=Gareth+Wylie&Age=24&Formula=a%2Bb+%3D%3D+21

Fra og med HTML 4.0 kan formularer også indsende data i multipart/form-data som defineret i RFC 2388 (Se også RFC 1867 for en tidligere eksperimentel version defineret som en udvidelse til HTML 2.0 og nævnt i HTML 3.2).

Det særlige tilfælde af en POST til den samme side, som formularen tilhører, er kendt som en postback .

Påvirker servertilstand

Ifølge RFC 7231 er POST -metoden ikke idempotent , hvilket betyder, at flere identiske anmodninger muligvis ikke har den samme effekt end at sende anmodningen kun én gang. POST er derfor velegnet til anmodninger, der ændrer tilstanden hver gang de udføres, f.eks. Indsendelse af en kommentar til et blogindlæg eller afstemning i en online meningsmåling. GET er defineret til at være nullipotent , uden bivirkninger, og idempotente operationer har "ingen bivirkninger ved andre eller fremtidige anmodninger". Af denne grund bruger webcrawlere såsom søgemaskineindeksere normalt udelukkende GET- og HEAD -metoderne for at forhindre, at deres automatiserede anmodninger udfører sådanne handlinger.

Der er dog grunde til, at POST bruges selv til idempotente anmodninger, især hvis anmodningen er meget lang. På grund af begrænsninger på webadresser kan forespørgselsstrengen, som GET-metoden genererer, blive meget lang, især på grund af procent-kodning .

Referencer

eksterne links