Hypertext Transfer Protocol - Hypertext Transfer Protocol

Hypertext Transfer Protocol

International standard	RFC  1945 HTTP/1.0 (1996) RFC  2068 HTTP/1.1 (1997) RFC  2616 HTTP/1.1 (1999) RFC  7230 HTTP/1.1: Syntax for meddelelser og routing (2014) RFC  7231 HTTP/1.1: Semantik og indhold (2014) RFC  7232 HTTP/1.1: Betingede anmodninger ( 2014) RFC  7233 HTTP/1.1: Range Requests (2014) RFC  7234 HTTP/1.1: Caching (2014) RFC  7235 HTTP/1.1: Godkendelse (2014) RFC  7540 HTTP/2 (2015) RFC  7541 HTTP/2: HPACK Header Compression (2015) RFC  8164 HTTP/2: Opportunistisk sikkerhed til HTTP/2 (2017) RFC  8336 HTTP/2: ORIGIN HTTP/2 Frame (2018) RFC  8441 HTTP/2: Bootstrapping WebSockets med HTTP/2 (2018) RFC  8740 HTTP/2: Brug af TLS 1.3 med HTTP/2 (2020)
Udviklet af	oprindeligt CERN ; IETF , W3C
Introduceret	1991 ; 30 år siden ( 1991 )

Den Hypertext Transfer Protocol ( HTTP ) er et applikationslaget protokol i internetprotokol model for distribuerede, kollaborative, hypermedier informationssystemer. HTTP er grundlaget for datakommunikation for World Wide Web , hvor hypertekstdokumenter indeholder hyperlinks til andre ressourcer, som brugeren let kan få adgang til, f.eks. Ved et museklik eller ved at trykke på skærmen i en webbrowser.

Udviklingen af ​​HTTP blev initieret af Tim Berners-Lee på CERN i 1989 og opsummeret i et simpelt dokument, der beskriver en klients og en servers adfærd ved hjælp af den første HTTP-protokolversion, der blev navngivet 0.9.

Udvikling af tidlige HTTP -anmodninger om kommentarer (RFC'er) startede et par år senere, og det var en koordineret indsats fra Internet Engineering Task Force (IETF) og World Wide Web Consortium (W3C), hvor arbejdet senere flyttede til IETF.

HTTP/1 blev første gang dokumenteret (som version 1.0) i 1996. Det udviklede sig (som version 1.1) i 1997.

HTTP/2 er et mere effektivt udtryk for HTTPs semantik "on the wire", og blev udgivet i 2015 og bruges af 45% af webstederne; det understøttes nu af stort set alle webbrowsere og større webservere via Transport Layer Security (TLS) ved hjælp af en Application-Layer Protocol Negotiation (ALPN) udvidelse, hvor TLS 1.2 eller nyere er påkrævet.

HTTP/3 er den foreslåede efterfølger til HTTP/2, og to tredjedele af webbrowser-brugere (både på desktop og mobil) kan allerede bruge HTTP/3 på de 20% af websteder, der allerede understøtter det; den bruger QUIC i stedet for TCP til den underliggende transportprotokol. Ligesom HTTP/2 forælder den ikke tidligere større versioner af protokollen. Support til HTTP/3 blev tilføjet til Cloudflare og Google Chrome først og er også aktiveret i Firefox .

Teknisk oversigt

URL, der begynder med HTTP -skemaet og WWW -domænenavnetiketten

HTTP fungerer som en anmodning -svar -protokol i klient -server -computermodellen. En webbrowser kan f.eks. Være klienten, og et program, der kører på en computer, der er vært for et websted, kan være serveren . Klienten sender en HTTP -anmodningsmeddelelse til serveren. Serveren, der giver ressourcer såsom HTML -filer og andet indhold, eller udfører andre funktioner på vegne af klienten, returnerer en reaktion besked til klienten. Svaret indeholder oplysninger om færdiggørelsesstatus om anmodningen og kan også indeholde anmodet indhold i meddelelsesteksten.

En webbrowser er et eksempel på en brugeragent (UA). Andre typer brugeragenter omfatter indekseringssoftwaren, der bruges af søgeudbydere ( webcrawlere ), stemmebrowsere , mobilapps og anden software, der tilgår, forbruger eller viser webindhold.

HTTP er designet til at tillade mellemliggende netværkselementer at forbedre eller muliggøre kommunikation mellem klienter og servere. Websteder med høj trafik drager ofte fordel af webcache- servere, der leverer indhold på vegne af upstream-servere for at forbedre svartiden. Webbrowsere cacher tidligere adgang til webressourcer og genbruger dem, når det er muligt, for at reducere netværkstrafik. HTTP -proxyservere ved private netværksgrænser kan lette kommunikation for klienter uden en globalt routbar adresse ved at videresende meddelelser til eksterne servere.

For at give mellemliggende HTTP-noder (proxyservere, webcaches osv.) Mulighed for at udføre deres funktioner, administreres nogle af HTTP-headere (findes i HTTP-anmodninger/svar) hop-by-hop, mens andre HTTP-headere administreres end-to- ende (administreres kun af kildeklienten og af målwebserveren).

HTTP er en applikationslagsprotokol designet inden for rammerne af internetprotokolpakken . Dets definition forudsætter en underliggende og pålidelig transportlagsprotokol , og derfor bruges Transmission Control Protocol (TCP) almindeligt. HTTP kan dog tilpasses til at bruge upålidelige protokoller, f.eks. User Datagram Protocol (UDP), f.eks. I HTTPU og Simple Service Discovery Protocol (SSDP).

HTTP -ressourcer identificeres og findes på netværket af Uniform Resource Locators (URL'er) ved hjælp af Uniform Resource Identifiers (URI's) -skemaerne http og https . Som defineret i RFC  3986 er URI'er kodet som hyperlinks i HTML -dokumenter for at danne sammenkoblede hypertekstdokumenter .

HTTP/1.1 er en revision af den originale HTTP (HTTP/1.0). I HTTP/1.0 oprettes en separat forbindelse til den samme server for hver ressourceforespørgsel. HTTP/1.1 kan i stedet genbruge en forbindelse til at foretage flere ressourceforespørgsler (dvs. HTML -sider, rammer, billeder, scripts , stylesheets osv.).

HTTP/1.1 -kommunikation oplever derfor mindre forsinkelse, da etablering af TCP -forbindelser præsenterer betydelige omkostninger, især under høje trafikforhold.

HTTP/2 er en revision af tidligere HTTP/1.1 for at bevare den samme klient-server-model og de samme protokolmetoder, men med disse forskelle i rækkefølge:

• at bruge en komprimeret binær repræsentation af metadata (HTTP -overskrifter) i stedet for en tekstlig, så overskrifter kræver meget mindre plads;
• at bruge en enkelt TCP/IP (normalt krypteret ) forbindelse pr. server domæne i stedet for 2..8 TCP/IP forbindelser;
• til anvendelse af en eller flere tovejs strømme pr TCP / IP-forbindelse, i hvilken HTTP-forespørgsler og svar nedbrydes og transmitteres i små pakker for at løse problemet med den HOLB ( hoved linje blokering , BEMÆRK: I praksis disse strømme anvendes som multipel TCP /IP-underforbindelser til multipleks samtidige anmodninger/svar, hvilket reducerer antallet af reelle TCP/IP-forbindelser på serversiden kraftigt fra 2..8 pr. Klient til 1, og gør det muligt at betjene mange flere klienter på én gang);
• at tilføje en push -kapacitet for at tillade serverapplikation at sende data til klienter, når nye data er tilgængelige (uden at tvinge klienter til at anmode om regelmæssigt nye data til serveren ved hjælp af pollingmetoder ).

HTTP/2 -kommunikation oplever derfor meget mindre latenstid og i de fleste tilfælde endnu mere hastighed end HTTP/1.1 -kommunikation.

HTTP/3 er en revision af tidligere HTTP/2 for at kunne bruge UDP + QUIC transportprotokoller i stedet for TCP/IP -forbindelser og på den måde overvinde problemet med TCP/IP -forbindelse, der kan blokere eller bremse datastrømmen for alle dets vandløb.

Historie

Tim Berners-Lee

Begrebet hypertekst blev opfundet af Ted Nelson i 1965 i Xanadu-projektet , som igen var inspireret af Vannevar Bushs vision fra 1930'erne om det mikrofilmbaserede informationssøgning og " memex " -system beskrevet i sit essay fra 1945 " As We May Think ". Tim Berners-Lee og hans team på CERN krediteres med at have opfundet den originale HTTP sammen med HTML og den tilhørende teknologi til en webserver og en tekstbaseret webbrowser. Berners-Lee foreslog første gang projektet "WorldWideWeb" i 1989-nu kendt som World Wide Web . Den første webserver gik live i 1990. Den anvendte protokol havde kun én metode, nemlig GET, som ville anmode om en side fra en server. Svaret fra serveren var altid en HTML -side.

Den første dokumenterede version af HTTP blev skrevet i 1991. Dave Raggett ledede HTTP Working Group (HTTP WG) i 1995 og ønskede at udvide protokollen med udvidede operationer, udvidede forhandlinger, rigere metainformation, knyttet til en sikkerhedsprotokol, der blev mere effektiv ved at tilføje yderligere metoder og headerfelter . RFC  1945 blev officielt introduceret og anerkendt HTTP version 1.0 i 1996.

HTTP WG planlagde at udgive nye standarder i december 1995, og understøttelsen af ​​pre-standard HTTP/1.1 baseret på den derefter udviklende RFC  2068 (kaldet HTTP-NG) blev hurtigt vedtaget af de store browserudviklere i begyndelsen af ​​1996. Slutbruger adoption af de nye browsere var hurtig. I marts 1996 rapporterede et webhostingfirma, at over 40% af browsere, der blev brugt på Internettet, var HTTP 1.1 -kompatible. Det samme webhostingfirma rapporterede, at i juni 1996 var 65% af alle browsere, der fik adgang til deres servere, HTTP/1.1 -kompatible. HTTP/1.1 -standarden som defineret i RFC  2068 blev officielt frigivet i januar 1997. Forbedringer og opdateringer af HTTP/1.1 -standarden blev frigivet under RFC  2616 i juni 1999.

I 2007 blev HTTP -arbejdsgruppen delvis dannet for at revidere og præcisere HTTP/1.1 -specifikationen.

I juni 2014 udgav WG en opdateret seksdelt specifikation, der forældede RFC  2616 :

• RFC  7230 , HTTP/1.1: Beskedsyntaks og routing
• RFC  7231 , HTTP/1.1: Semantik og indhold
• RFC  7232 , HTTP/1.1: Betingede anmodninger
• RFC  7233 , HTTP/1.1: Anmodninger om område
• RFC  7234 , HTTP/1.1: Caching
• RFC  7235 , HTTP/1.1: Godkendelse

I maj 2015 blev HTTP/2 offentliggjort som RFC  7540 .

Siden 2016 er mange produktledere og udviklere af brugeragenter (browsere osv.) Og webservere begyndt at planlægge gradvist at afskrive og afvise support til HTTP/0.9 -protokollen, hovedsageligt af følgende årsager:

• det er klart forældet, fordi det er så enkelt, at ingen gider at skrive et RFC -dokument (der er kun det originale dokument);
• den har ingen HTTP -headere, og den mangler også mange andre funktioner, som i dag virkelig er påkrævet af minimale sikkerhedsmæssige årsager;
• det er ikke rigtig blevet brugt siden 1999..2000 (på grund af HTTP/1.0 og HTTP/1.1);
• det ligner, at det kun tilfældigt bruges af nogle meget gamle netværkshardware, dvs. routere osv.

I 2021 findes der stadig HTTP/0.9 -support i mange webservere og browsere (kun for serversvar), så det er ikke klart, hvor lang tid denne udsendelse vil tage, måske bliver den først afsluttet i brugeragenter (browsere osv.) Og derefter i webservere.

HTTP -session

En HTTP -session er en sekvens af netværksanmodning -svartransaktioner. En HTTP -klient starter en anmodning ved at etablere en TCP -forbindelse ( Transmission Control Protocol ) til en bestemt port på en server (typisk port 80, lejlighedsvis port 8080; se Liste over TCP- og UDP -portnumre ). En HTTP -server, der lytter på den port, venter på en klients anmodningsmeddelelse. Ved modtagelse af anmodningen sender serveren en statuslinje tilbage, f.eks. " HTTP/1.1 200 OK " og en egen meddelelse. Denne meddelelses brødtekst er typisk den ønskede ressource, selvom en fejlmeddelelse eller andre oplysninger også kan returneres.

Vedvarende forbindelser

I HTTP/0.9 lukkes TCP/IP -forbindelsen altid, efter at serverrespons er blevet sendt.

I HTTP/1.0, som angivet i RFC 1945, skal TCP/IP -forbindelsen altid lukkes af serveren, efter at et svar er blevet sendt. BEMÆRK: siden slutningen af ​​1996 begyndte nogle udviklere af populære HTTP/1.0-browsere og servere (især dem, der også havde planlagt support til HTTP/1.1), at implementere (som en uofficiel udvidelse) en slags keep-alive-mekanisme (ved hjælp af nye HTTP -headere) for at holde TCP/IP -forbindelsen åben for mere end et anmodnings-/svarpar og dermed for at fremskynde udvekslingen af ​​flere anmodninger/svar.

I HTTP/1.1 blev der officielt introduceret en hold-i-live-mekanisme, så en forbindelse kunne genbruges til mere end én forespørgsel/svar. Sådanne vedvarende forbindelser reducerer anmodning latenstid mærkbart fordi kunden ikke behøver at genforhandle TCP 3-vejs-Handshake forbindelse efter den første anmodning er sendt. En anden positiv bivirkning er, at forbindelsen generelt bliver hurtigere med tiden på grund af TCP's slow -start -mekanisme.

HTTP/1.1 tilføjede også HTTP -pipelining for yderligere at reducere forsinkelsestid ved brug af vedvarende forbindelser ved at lade klienter sende flere anmodninger, før de venter på hvert svar. Denne optimering blev aldrig betragtet som virkelig sikker, fordi et par webservere og mange proxyservere , specielt transparente proxyservere placeret på Internettet / Intranet mellem klienter og servere, ikke håndterede pipelinerede anmodninger korrekt (de betjente kun den første anmodning om at kassere de andre, eller de lukkede forbindelsen, fordi de så flere data efter den første anmodning osv.). Udover dette kunne kun GET- og HEAD -anmodninger pipelineres i en sikker og idempotent tilstand. Efter mange års kamp med de problemer, der blev introduceret ved at muliggøre pipeline, blev denne funktion først deaktiveret og derefter fjernet fra de fleste browsere også på grund af den annoncerede vedtagelse af HTTP/2.

HTTP/2 udvidede brugen af vedvarende forbindelser ved at multiplexere mange samtidige anmodninger/svar via en enkelt TCP/IP -forbindelse.

HTTP/3 bruger ikke TCP/IP -forbindelser, men UDP + QUIC for at undgå problemet med TCP/IP -overbelastning af en forbindelse.

Optimeringer af indholdsindhentning

I HTTP/0.9 blev en anmodet ressource altid sendt helt.

HTTP/1.0 tilføjede overskrifter til at styre ressourcer, der gemmes af klienten for at tillade betingede GET -anmodninger ; i praksis skal en server kun returnere hele indholdet af den anmodede ressource, hvis den sidste ændrede tid ikke er kendt af klienten, eller hvis den er ændret siden sidste fulde svar på GET -anmodning.

HTTP/1.0 tilføjede overskriften "Indholdskodning" for at angive, om det returnerede indhold i en ressource var eller ikke var komprimeret .

I HTTP/1.0, hvis den samlede længde af indholdet af en ressource ikke var kendt på forhånd (dvs. fordi den blev dynamisk genereret osv.), Så var headeren "Content-Length: number"ikke til stede i HTTP -headere, og klienten antog, at når serveren lukkede forbindelsen , var indholdet helt sendt. Denne mekanisme kunne ikke skelne mellem en vellykket ressourceoverførsel og en afbrudt (på grund af en server- / netværksfejl eller noget andet).

HTTP/1.1 tilføjede nye overskrifter til bedre at styre den betingede hentning af cachelagrede ressourcer.

HTTP/1.1 introducerede chunked transfer -kodning for at tillade indhold at blive streamet i bidder for pålideligt at sende det, selvom serveren ikke på forhånd kender dets længde (dvs. fordi det er dynamisk genereret osv.).

HTTP/1.1 tilføjede også byteområdevisning , hvor en klient kun kan anmode om en eller flere portioner (bytes) af en ressource (dvs. den første del, en del i midten eller i slutningen af ​​hele indholdet osv.) og serveren sender normalt kun de eller de ønskede dele. Dette er nyttigt for at genoptage en afbrudt download (når en fil er virkelig stor), når kun en del af et indhold skal vises eller dynamisk tilføjes til den allerede synlige del af en browser (dvs. kun de første eller følgende n kommentarer af en webside) for at spare tid, båndbredde og systemressourcer osv.

HTTP/2 og HTTP/3 har beholdt de ovennævnte funktioner i HTTP/1.1.

HTTP -sessionstilstand

HTTP er en statsløs protokol . En statsløs protokol kræver ikke, at HTTP -serveren opbevarer oplysninger eller status om hver bruger i varigheden af ​​flere anmodninger. Nogle webapplikationer implementerer imidlertid tilstande eller serversider ved hjælp af f.eks. HTTP -cookies eller skjulte variabler i webformularer .

HTTP -godkendelse

HTTP leverer flere godkendelsesordninger, såsom grundlæggende adgangsgodkendelse og godkendelsesadgangsgodkendelse, der fungerer via en udfordringsresponsmekanisme, hvorved serveren identificerer og udsender en udfordring, inden det ønskede indhold serveres.

HTTP giver en generel ramme for adgangskontrol og godkendelse via et udvideligt sæt udfordringsrespons -godkendelsesordninger, som kan bruges af en server til at udfordre en klientanmodning og af en klient til at levere godkendelsesoplysninger.

Godkendelsesområder

HTTP-godkendelsesspecifikationen giver også en vilkårlig, implementeringsspecifik konstruktion til yderligere opdeling af ressourcer, der er fælles for en given rod- URI . Rigværdistrengen, hvis den findes, kombineres med den kanoniske rod URI for at danne udfordringens beskyttelsesrumskomponent. Dette gør det i realiteten muligt for serveren at definere separate autentificeringsomfang under en rod -URI.

Anmod om beskeder

Anmod om syntaks

En klient sender anmodningsmeddelelser til serveren, som består af:

• en anmodningslinje, der består af den case-sensitive anmodningsmetode, et mellemrum , forespørgselsmålet, et andet mellemrum, protokolversionen, en vognretur og et liniefeed , f.eks .:

GET /images/logo.png HTTP/1.1

• nul eller flere forespørgselsoverskriftsfelter (mindst 1 eller flere overskrifter i tilfælde af HTTP/1.1), der hver består af det ufølsomme feltnavn, et kolon, valgfrit ledende mellemrum , feltværdien, et valgfrit efterfølgende mellemrum og slutter med et vognretur og et liniefoder, f.eks .:

Host: www.example.com
Accept-Language: en

• en tom linje, der består af en vognretur og et liniefoder;
• en valgfri beskedtekst .

I HTTP/1.1 -protokollen er alle overskriftsfelter undtagen Host: hostnamevalgfrie.

En anmodningslinje, der kun indeholder stinavnet, accepteres af servere for at opretholde kompatibilitet med HTTP -klienter før HTTP/1.0 -specifikationen i RFC  1945 .

Anmod om metoder

En HTTP/1.1 -anmodning fremsat ved hjælp af telnet. Den anmodning besked, svar header sektionen, og respons krop er fremhævet.

HTTP definerer metoder (undertiden omtalt som verber , men intetsteds i beskrivelsen nævner det verbum , og OPTIONS eller HEAD er ikke et verbum) for at angive den ønskede handling, der skal udføres på den identificerede ressource. Hvad denne ressource repræsenterer, uanset om eksisterende data eller data, der genereres dynamisk, afhænger af serverens implementering. Ofte svarer ressourcen til en fil eller output fra en eksekverbar, der findes på serveren. HTTP/1.0 -specifikationen definerede GET-, HEAD- og POST -metoderne, og HTTP/1.1 -specifikationen tilføjede fem nye metoder: PUT, DELETE, CONNECT, OPTIONS og TRACE. Ved at blive specificeret i disse dokumenter er deres semantik velkendt og kan være afhængig af. Enhver klient kan bruge enhver metode, og serveren kan konfigureres til at understøtte enhver kombination af metoder. Hvis en metode er ukendt for et mellemprodukt, vil den blive behandlet som en usikker og ikke-idempotent metode. Der er ingen grænse for antallet af metoder, der kan defineres, og dette gør det muligt at specificere fremtidige metoder uden at bryde eksisterende infrastruktur. For eksempel definerede WebDAV syv nye metoder, og RFC  5789 specificerede PATCH -metoden.

Metodenavne er store og små bogstaver. Dette er i modsætning til HTTP-headerfeltnavne, som ikke er store og små bogstaver.

FÅ

GET -metoden anmoder om, at målressourcen overfører en repræsentation af dens tilstand. GET -anmodninger bør kun hente data og bør ikke have anden effekt. (Dette er også sandt for nogle andre HTTP -metoder.) W3C har offentliggjort vejledningsprincipper om denne sondring og siger: " Webapplikationsdesign bør informeres af ovenstående principper, men også af de relevante begrænsninger." Se sikre metoder herunder.

HOVED

HEAD -metoden anmoder om, at målressourcen overfører en repræsentation af dens tilstand, ligesom for en GET -anmodning, men uden repræsentationsdataene, der er vedlagt svarorganet. Dette er nyttigt til at hente repræsentationsmetadataene i svaroverskriften uden at skulle overføre hele repræsentationen.

STOLPE

De POST metoden anmoder om, at målressourcen bearbejder repræsentationen indesluttet i anmodningen i henhold til semantik af målressourcen. For eksempel bruges den til at sende en besked til et internetforum , abonnere på en mailingliste eller gennemføre en online shoppingtransaktion .

SÆTTE

PUT -metoden anmoder om, at målressourcen opretter eller opdaterer sin tilstand med den tilstand, der er defineret af repræsentationen, der er vedlagt anmodningen.

SLET

DELETE -metoden anmoder om, at målressourcen sletter sin tilstand.

FORBINDE

CONNECT -metoden anmoder om, at mellemmanden opretter en TCP/IP -tunnel til originalserveren identificeret af forespørgselsmålet. Det bruges ofte til at sikre forbindelser via en eller flere HTTP -proxyer med TLS . Se HTTP CONNECT -metode .

MULIGHEDER

OPTIONS -metoden anmoder om, at målressourcen overfører de HTTP -metoder, den understøtter. Dette kan bruges til at kontrollere funktionaliteten af ​​en webserver ved at anmode om '*' i stedet for en bestemt ressource.

SPOR

TRACE -metoden anmoder om, at målressourcen overfører den modtagne anmodning til svarlegemet. På den måde kan en klient se, hvilke (hvis nogen) ændringer eller tilføjelser der er foretaget af mellemmænd.

LAPPE

PATCH -metoden anmoder om, at målressourcen ændrer sin tilstand i henhold til den delvise opdatering, der er defineret i repræsentationen, der er vedlagt anmodningen.

Alle generelle HTTP-servere er påkrævet for at implementere mindst GET- og HEAD-metoderne, og alle andre metoder betragtes som valgfri af specifikationen.

Sikre metoder

En anmodningsmetode er sikker, hvis en anmodning med denne metode ikke har nogen tilsigtet effekt på serveren. Metoderne GET, HEAD, OPTIONS og TRACE er defineret som sikre. Med andre ord er sikre metoder beregnet til at være skrivebeskyttet . De udelukker dog ikke bivirkninger , f.eks. Tilføjelse af anmodningsoplysninger til en logfil eller opkrævning af en annoncekonto , da de ikke er anmodet om af klienten pr. Definition.

I modsætning hertil er metoderne POST, PUT, DELETE, CONNECT og PATCH ikke sikre. De kan ændre serverens tilstand eller have andre effekter, f.eks. At sende en e -mail . Sådanne metoder bruges derfor normalt ikke af tilpassede webrobotter eller webcrawlere; nogle, der ikke er i overensstemmelse, har en tendens til at fremsætte anmodninger uden hensyn til kontekst eller konsekvenser.

På trods af den foreskrevne sikkerhed for GET -anmodninger er håndteringen af ​​serveren i praksis ikke teknisk begrænset på nogen måde. Derfor kan skødesløs eller bevidst programmering forårsage ikke-trivielle ændringer på serveren. Dette frarådes, fordi det kan forårsage problemer for webcaching , søgemaskiner og andre automatiserede agenter, som kan foretage utilsigtede ændringer på serveren. For eksempel kan et websted muliggøre sletning af en ressource via en webadresse, f.eks. Https://example.com/article/1234/delete , som hvis det hentes vilkårligt, selv ved hjælp af GET , simpelthen ville slette artiklen.

Et eksempel på, at dette skete i praksis, var under den kortvarige Google Web Accelerator- beta , som forud hentede vilkårlige webadresser på den side, en bruger så, hvilket fik poster til automatisk at blive ændret eller slettet massivt . Beta blev suspenderet kun uger efter dens første udgivelse efter omfattende kritik.

Idempotente metoder

En anmodningsmetode er idempotent, hvis flere identiske anmodninger med den metode har den samme tilsigtede effekt som en enkelt sådan anmodning. Metoderne PUT og DELETE og sikre metoder er defineret som idempotent.

I modsætning hertil er metoderne POST, CONNECT og PATCH ikke nødvendigvis idempotente, og derfor kan afsendelse af en identisk POST -anmodning flere gange ændre serverens tilstand yderligere eller have yderligere effekter, såsom at sende en e -mail . I nogle tilfælde kan dette være ønskeligt, men i andre tilfælde kan det skyldes en ulykke, f.eks. Når en bruger ikke er klar over, at deres handling vil resultere i at sende en anden anmodning, eller de ikke har modtaget tilstrækkelig feedback om, at deres første anmodning var vellykket. Selvom webbrowsere kan vise advarselsdialogbokse for at advare brugere i nogle tilfælde, hvor genindlæsning af en side kan indsende en POST-anmodning igen, er det generelt op til webapplikationen at håndtere tilfælde, hvor en POST-anmodning ikke skal indsendes mere end én gang.

Bemærk, at om en metode er idempotent, ikke håndhæves af protokollen eller webserveren. Det er fuldstændig muligt at skrive en webapplikation, hvor (for eksempel) en databaseindsats eller anden ikke-idempotent handling udløses af en GET eller anden anmodning. At ignorere denne anbefaling kan imidlertid resultere i uønskede konsekvenser, hvis en brugeragent antager, at det er sikkert at gentage den samme anmodning, når den ikke er det.

Metoder, der kan gemmes

En anmodning metode er cache , hvis svar på anmodninger med denne metode kan opbevares til fremtidig genbrug. Metoderne GET, HEAD og POST er defineret som cachelagrede.

I modsætning hertil kan metoderne PUT, DELETE, CONNECT, OPTIONS, TRACE og PATCH ikke cachelagres.

Anmod om overskriftsfelter

Anmodningshovedfelter giver klienten mulighed for at videregive yderligere oplysninger ud over anmodningslinjen, der fungerer som anmodningsmodifikatorer (på samme måde som parametrene for en procedure). De giver oplysninger om klienten, om målressourcen eller om den forventede håndtering af anmodningen.

Svarbeskeder

Svar syntaks

En server sender svarbeskeder til klienten, som består af:

• en statuslinje, der består af protokolversionen, et mellemrum , svarstatuskoden , et andet mellemrum, en muligvis tom årsagssætning, en vognretur og et liniefeed , f.eks .:

HTTP/1.1 200 OK

• nul eller flere svaroverskriftsfelter , der hver består af det store bogstavsfølsomme feltnavn, et kolon, valgfrit ledende mellemrum , feltværdien, et valgfrit efterfølgende hvidt mellemrum og slutter med en vognretur og et liniefeed, f.eks .:

Content-Type: text/html

• en tom linje, der består af en vognretur og et liniefoder;
• en valgfri beskedtekst .

Svarstatuskoder

I HTTP/1.0 og siden kaldes den første linje i HTTP -svaret statuslinjen og indeholder en numerisk statuskode (f.eks. " 404 ") og en tekstlig årsagssætning (f.eks. "Ikke fundet"). Svarstatuskoden er en trecifret heltalskode, der repræsenterer resultatet af serverens forsøg på at forstå og tilfredsstille klientens tilsvarende anmodning. Den måde, hvorpå klienten håndterer svaret, afhænger primært af statuskoden og sekundært af de andre svaroverskriftsfelter. Klienter forstår muligvis ikke alle registrerede statuskoder, men de skal forstå deres klasse (givet ved det første ciffer i statuskoden) og behandle en ikke -genkendt statuskode som værende ækvivalent med x00 -statuskoden for denne klasse.

Standard grund sætninger er kun anbefalinger, og kan erstattes med "lokale ækvivalenter" på web-udvikler 's skøn. Hvis statuskoden angav et problem, viser brugeragenten muligvis årsagssætningen til brugeren for at give yderligere oplysninger om problemets art. Standarden giver også brugeragenten mulighed for at forsøge at fortolke årsagssætningen , selvom dette kan være uklogt, da standarden eksplicit angiver, at statuskoder er maskinlæsbare og årsagssætninger er læsbare for mennesker.

Det første ciffer i statuskoden definerer dets klasse:

1XX (oplysende)

Anmodningen blev modtaget og fortsatte processen.

2XX (vellykket)

Anmodningen blev modtaget, forstået og accepteret.

3XX (omdirigering)

Yderligere foranstaltninger skal træffes for at fuldføre anmodningen.

4XX (klientfejl)

Anmodningen indeholder en dårlig syntaks eller kan ikke opfyldes.

5XX (Server Fejl)

Serveren opfyldte ikke en tilsyneladende gyldig anmodning.

Svaroverskriftsfelter

Svaroverskriftsfelterne tillader serveren at videregive yderligere oplysninger ud over statuslinjen og fungere som svarmodifikatorer. De giver oplysninger om serveren eller om yderligere adgang til målressourcen eller relaterede ressourcer.

Hvert svaroverskriftsfelt har en defineret betydning, som kan forbedres yderligere af semantikken i anmodningsmetoden eller svarstatuskode.

Krypterede forbindelser

Den mest populære måde at etablere en krypteret HTTP -forbindelse på er HTTPS . To andre metoder til etablering af en krypteret HTTP -forbindelse findes også: Secure Hypertext Transfer Protocol og brug af HTTP/1.1 -opgraderingsoverskriften til at angive en opgradering til TLS. Browsersupport til disse to er imidlertid næsten ikkeeksisterende.

Eksempel session

Nedenfor er en eksempelsamtale mellem en HTTP -klient og en HTTP -server, der kører på www.example.com , port 80.

Kundeanmodning

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

En klientanmodning (bestående i dette tilfælde af anmodningslinjen og et par overskrifter, der kun kan reduceres til "Host: hostname"overskriften) efterfølges af en tom linje, så anmodningen slutter med en dobbelt ende af linjen, hver i form af en vognretur efterfulgt af et liniefoder . Den "Host: hostname"header værdi skelner mellem forskellige DNS navne deler en enkelt IP-adresse , så navn-baserede virtuel hosting . Selvom det er valgfrit i HTTP/1.0, er det obligatorisk i HTTP/1.1. (Et " /" (skråstreg) vil normalt hente en /index.html -fil, hvis der er en.)

Server svar

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

Den ETag (enhed tag) header felt bruges til at afgøre, om en cached version af den anmodede ressource er identisk med den aktuelle version af ressourcen på serveren. "Content-Type"angiver internetmedietypen for de data, der overføres af HTTP -meddelelsen, mens den "Content-Length"angiver dens længde i bytes. HTTP/1.1 webserveren offentliggør sin evne til at besvare anmodninger om bestemte byteområder i dokumentet ved at angive feltet "Accept-Ranges: bytes". Dette er nyttigt, hvis klienten kun skal have bestemte dele af en ressource sendt af serveren, som kaldes byteservering . Når den "Connection: close"er sendt, betyder det, at webserveren lukker TCP -forbindelsen umiddelbart efter afslutningen af ​​overførslen af ​​dette svar.

De fleste af overskriftslinjerne er valgfri, men nogle er obligatoriske. Når header "Content-Length: number"mangler i et svar med en enhedslegeme, bør dette betragtes som en fejl i HTTP/1.0, men det er muligvis ikke en fejl i HTTP/1.1, hvis header "Transfer-Encoding: chunked"er til stede. Chunked transfer kodning bruger en del på 0 til at markere slutningen på indholdet. Nogle gamle implementeringer af HTTP/1.0 udelod overskriften, "Content-Length"når kropsenhedens længde ikke var kendt i begyndelsen af ​​svaret, og så fortsatte overførslen af ​​data til klienten, indtil serveren lukkede soklen.

A kan bruges til at informere klienten om, at kropsenhedsdelen af ​​de transmitterede data komprimeres af gzip -algoritmen. "Content-Encoding: gzip"

Lignende protokoller

• Den Gopher protokol er en levering af indhold protokol, blev fortrængt af HTTP i begyndelsen af 1990'erne.
• Den SPDY protokollen er et alternativ til HTTP udviklet på Google , afløst af HTTP / 2 .
• Den Gemini-protokollen er en Gopher-inspirerede protokol, som mandater beskyttelse af personlige oplysninger funktioner.

Se også

• Sammenligning af filoverførselsprotokoller
• Begrænset applikationsprotokol -en semantisk lignende protokol til HTTP, men brugte UDP- eller UDP-lignende meddelelser målrettet mod enheder med begrænset behandlingskapacitet; genbruger HTTP og andre internetkoncepter som internetmedietype og weblinkning (RFC 5988)
• Indholdsforhandling
• Digest -adgangsgodkendelse
• HTTP -komprimering
• HTTP/2 - udviklet af IETF's arbejdsgruppe for Hypertext Transfer Protocol (httpbis)
• Liste over HTTP -headerfelter
• Liste over HTTP -statuskoder
• Overførsel af repræsentationsstat (REST)
• Variant objekt
• Webcache
• WebSocket

Referencer

eksterne links

• "Ændringshistorik for HTTP" . W3.org . Hentet 2010-08-01 . En detaljeret teknisk historie med HTTP.
• "Designproblemer til HTTP" . W3.org . Hentet 2010-08-01 . Designproblemer af Berners-Lee, da han designede protokollen.
• HTTP 0.9 - Som implementeret i 1991