Hypertext Transfer Protocol

Hypertext Transfer Protocol
Familie Internett-protokollfamilie
Funksjon hypertekstoverføring _
Siste versjon 3,0 (2018)
havner 80/TCP
Plassering i protokollstabelen
App HTTP
Transport TCP
Nett IP
standarder
Opprinnelig HTTP (HTTP/0.9, 1991 )

RFC 1945 (HTTP/1.0, 1996 )

RFC 2616 (HTTP/1.1, 1999 )

RFC 2774 ( HTTP/1.2 [ sitering kreves ] , 2000 )

RFC 72372FC , RFC 72302FC , RFC 72302FC , RFC 2774 7233 , RFC 7234 , RFC 7235
(revisjon av HTTP/1.1, 2014 )

RFC 7540 ( HTTP/2 , 2015 )

Hypertext Transfer Protocol versjon 3 ( HTTP/3, 2018 )
( Internett-utkast )

Hypertext Transfer Protocol (på engelsk , Hypertext Transfer Protocol , forkortet HTTP ) er kommunikasjonsprotokollen som tillater informasjonsoverføringer gjennom filer (XML, HTML ...) på World Wide Web . Den ble utviklet av World Wide Web Consortium og Internet Engineering Task Force , et samarbeid som kulminerte med utgivelsen av en serie RFC -er i 1999 , den viktigste av disse var RFC 2616 som spesifiserte versjon 1.1. HTTP definerer syntaksen og semantikken som brukes av programvareelementene i webarkitekturen (klienter, servere, proxyer ) for å kommunisere.

HTTP er en statsløs protokoll , så den lagrer ingen informasjon om tidligere tilkoblinger. Webapplikasjonsutvikling må ofte opprettholdes. Til dette brukes informasjonskapsler , som er informasjon som en server kan lagre på klientsystemet . Dette gjør at nettapplikasjoner kan starte forestillingen om en økt , og lar også brukere spores, siden informasjonskapsler kan lagres på klienten på ubestemt tid.

Beskrivelse

Det er en transaksjonsorientert protokoll og følger forespørsel-svar-skjemaet mellom en klient og en server. Klienten (ofte kalt " brukeragent " ) gjør en forespørsel ved å sende en melding, i et bestemt format, til serveren. Serveren (ofte kalt en webserver) sender deg en svarmelding. Eksempler på klienter er nettlesere og nettspidere (også kjent under deres engelske term, webcrawlers ).

Meldinger

HTTP-meldinger er i ren tekst , noe som gjør det mer lesbart og enklere å feilsøke. Dette har imidlertid den ulempen at meldingene blir lengre. Meldingene har følgende struktur:

Forespørselsmetoder


HTTP definerer et forhåndsdefinert sett med forespørselsmetoder (noen ganger referert til som "verb") som kan brukes. Protokollen har fleksibiliteten til å legge til nye metoder og dermed legge til nye funksjoner. Antall forespørselsmetoder har økt etter hvert som versjonene utviklet seg. [ 1 ] Denne listen inkluderer metodene lagt til av WebDAV .

Hver metode angir handlingen du ønsker skal utføres på den identifiserte ressursen. Hva denne ressursen representerer avhenger av serverapplikasjonen. For eksempel kan ressursen tilsvare en fil som ligger på serveren.

FÅ

GET-metoden ber om en representasjon av den angitte ressursen. Forespørsler som bruker GET skal bare hente data og skal ikke ha noen annen effekt. (Dette gjelder også for noen andre HTTP-metoder.)

HEAD

RFC 2616 . Den ber om et svar som er identisk med det som vil tilsvare en GET-forespørsel, men kroppen returneres ikke i svaret. Dette er nyttig for å kunne hente metadata fra svarhodene, uten å måtte bære hele innholdet.

POST

RFC 2616 . Sender data som skal behandles av ressursen som er identifisert i URL-en til forespørselslinjen. Dataene vil bli inkludert i selve forespørselen. På et semantisk nivå er det rettet mot å lage en ny ressurs, hvis art vil spesifiseres av Content-Type- overskriften . Eksempler:

PUT

( RFC 2616 ) Den sender data til serveren, men i motsetning til POST-metoden refererer ikke URIen til forespørselslinjen til ressursen som skal behandle den, men identifiserer heller selve dataene (se detaljert forklaring i RFC ). En annen forskjell med POST er semantikk (se REST ): mens POST er orientert mot å lage nytt innhold, er PUT mer orientert mot å oppdatere det (selv om det også kan lage det).

Eksempel:

PUT /path/filename.html HTTP/1.1 SLETT

RFC 2616 . Sletter den angitte ressursen.

SPOR

( RFC 2616 ) Denne metoden ber serveren om å sette inn alle dataene den mottar i forespørselsmeldingen i svaret. Den brukes til feilsøking og diagnostiske formål siden klienten kan se hva som kommer til serveren og på denne måten se alt som de mellomliggende serverne legger til meldingen.

ALTERNATIVER

RFC 2616 . Returnerer HTTP-metodene som serveren støtter for en bestemt URL. Dette kan brukes til å sjekke funksjonaliteten til en webserver ved forespørsel i stedet for en spesifikk ressurs.

KOBLE TIL

RFC 2616 . Den brukes til å vite om du har tilgang til en vert, ikke nødvendigvis forespørselen når serveren, denne metoden brukes hovedsakelig for å vite om en proxy gir oss tilgang til en vert under spesielle forhold, som for eksempel krypterte toveis data "strømmer". (som kreves av SSL).

PATCH

( RFC 5789 ). Dens funksjon er den samme som PUT, som fullstendig overskriver en ressurs. Den brukes til å delvis oppdatere en eller flere deler. Den er også orientert for bruk med proxy . [ 2 ]

FLYTT

RFC 2518

MKCOL

RFC 2518

PROPFIND

RFC 2518

PROPPATCH

RFC 2518

SLÅ sammen

RFC 3253

OPPDATERING

RFC 3253

LABEL

RFC 3253

Svarkoder

Svar- eller returkoden er et tall som indikerer hva som har skjedd med forespørselen. Resten av responsinnholdet vil avhenge av verdien av denne koden. Systemet er fleksibelt og faktisk har listen over koder økt for å tilpasse seg endringer og identifisere nye situasjoner. Hver kode har en bestemt betydning. Imidlertid er antall koder valgt på en slik måte at avhengig av om det tilhører hundre eller en annen, kan typen svar gitt av serveren identifiseres:

Overskrifter

Det er metadataene som sendes i HTTP-forespørsler eller svar for å gi viktig informasjon om gjeldende transaksjon. Hver overskrift spesifiseres av et overskriftsnavn etterfulgt av et kolon, et tomt mellomrom og verdien av den overskriften etterfulgt av en vognretur etterfulgt av en linjemating. En tom linje brukes for å indikere slutten av overskrifter. Hvis det ikke er noen overskrifter, skal den tomme linjen forbli.

Overskriftene gir stor fleksibilitet til protokollen, slik at du kan legge til nye funksjoner uten å måtte endre basen. Det er grunnen til at etter hvert som versjonene av HTTP har skjedd, har flere og flere tillatte overskrifter blitt lagt til.

Overskriftene kan inneholde metadata som må behandles av klienten (f.eks. som svar på en forespørsel kan typen innhold den inneholder angis), av serveren (f.eks. typer representasjoner som er akseptable for klienten av innholdet den ber om) eller av mellomledd (f.eks. hvordan administrere hurtigbufring av proxyer )

Avhengig av typen melding som en overskrift kan legges inn i, kan vi klassifisere dem i forespørselshoder, svarhoder og overskrifter som kan gå i både en forespørsel og et svar.

Vi kan klassifisere overskrifter i henhold til deres funksjon. For eksempel:

Eksempel på HTTP-dialog

For å få en ressurs med URL http://www.example.com/index.html

  1. En tilkobling åpnes på port 80 til verten www.example.com . Port 80 er standardporten for HTTP. Hvis du ønsker å bruke XXXX-porten, må du kode den inn i URL-en i formen http://www.example.com:XXXX/index.html
  2. En melding sendes i følgende stil:
FÅ /index.html HTTP/1.1 Vert: www.example.com Henviser: www.google.com Brukeragent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Tilkobling: holde i live [blank linje]

Serversvaret består av overskrifter etterfulgt av den forespurte ressursen, når det gjelder en nettside:

HTTP/1.1 200 OK Dato: fre, 31. desember 2003 23:59:59 GMT Innholdstype: tekst/html Innhold-lengde: 1221 <html lang="eo"> <hode> <meta charset="utf-8"> <title>Nettstedstittel</title> </head> <body> <h1>YourHost-hjemmesiden</h1> (Innhold) . . . </body> </html>

Versjoner

HTTP har gått gjennom flere versjoner av protokollen, hvorav mange er bakoverkompatible. RFC 2145 beskriver bruken av HTTP-versjonsnumre. Klienten forteller serveren i begynnelsen av forespørselen hvilken versjon den bruker, og serveren bruker samme eller en tidligere versjon i sitt svar.

0,9 (utgitt i 1991) Utdatert. Den støtter bare én kommando, GET, og spesifiserer heller ikke HTTP-versjonsnummeret. Støtter ikke overskrifter. Siden denne versjonen ikke støtter POST, kan ikke klienten sende mye informasjon til serveren. HTTP/1.0 (mai 1996) Dette er den første revisjonen av protokollen som spesifiserer versjonen i kommunikasjon, og den er fortsatt mye brukt, spesielt i proxy-servere. Tillater GET-, HEAD- og POST-forespørselsmetoder. HTTP/1.1 (juni 1999) [ 3 ]​ [ 4 ] For tiden mest brukte versjon; [ referanse nødvendig ] Vedvarende tilkoblinger er aktivert som standard og fungerer fint med proxyer . Det lar også klienten sende flere forespørsler samtidig over samme tilkobling ( pipelining ), noe som gjør det mulig å eliminere rundtursforsinkelsestiden for hver forespørsel. HTTP/1.2 (februar 2000) De første 1995-utkastene til PEP - en utvidelsesmekanisme for HTTP- dokument (som foreslår Protocol Extension Protocol , forkortet PEP) ble laget av World Wide Web Consortium og sendt til Internet Engineering Task Force . PEP var opprinnelig ment å bli et særegent område av HTTP/1.2. [ 5 ] I senere utkast ble imidlertid henvisningen til HTTP/1.2 fjernet. RFC 2774 ( eksperimentell), HTTP Extension Framework , inkluderer i stor grad PEP. Den ble publisert i februar 2000. HTTP/2 (mai 2015) I 2012 vises de første utkastene til den nye versjonen av HTTP ( HTTP/2 ). Denne nye versjonen endrer ikke applikasjonssemantikken til http (alle grunnleggende konsepter forblir uendret). Forbedringene fokuserer på hvordan data pakkes og på transport. Legg for eksempel til bruk av en enkelt tilkobling, topptekstkomprimering eller 'server push'-tjenesten. Store nettlesere støtter bare HTTP 2.0 over TLS ved å bruke ALPN- utvidelsen [ 6 ] som krever TLSv1.2 eller høyere. [ 7 ]

HTTP/3 (oktober 2018)

HTTP/3 er den foreslåtte etterfølgeren til HTTP/2, [ 8 ]​ [ 9 ]​ som allerede er i bruk på nettet, og bruker UDP i stedet for TCP for den underliggende transportprotokollen. I likhet med HTTP/2 er den ikke utdatert i tidligere hovedversjoner av protokollen. Støtte for HTTP/3 ble lagt til Cloudflare og Google Chrome i september 2019, [ 10 ] ​[ 11 ]​ og kan aktiveres i stabile versjoner av Chrome og Firefox . [ 12 ]

Se også

Referanser

  1. ↑ Liste over http-metoder
  2. ↑ L. Dusseault, J. Snell (25. november 2009). "PATCH-metode for HTTP draft-dusseault-http-patch-16" (html) . IETF . _ Arkivert fra originalen på https://web.archive.org/web/20170630025624/https://tools.ietf.org/html/draft-dusseault-http-patch-16 . Hentet 15. september 2018 . "Dette forslaget legger til en ny HTTP-metode, PATCH, for å endre en eksisterende HTTP-ressurs. »  
  3. ↑ Januar 1997. Den første versjonen av HTTP/1.1-spesifikasjonen er publisert
  4. ↑ Juni 1999. Siste versjon av HTTP/1.1-spesifikasjonen utgitt
  5. ↑ [1] PEP: An Extension Mechanism for HTTP . Sitat: "For eksperimentelle formål er PEP-kompatibilitet likestilt med HTTP/1.2."
  6. ^ "RFC 7301 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension" . IETF. juli 2014. 
  7. ↑ Belshe, M.; Pawn, R.; Thomson, M. "Hypertext Transfer Protocol versjon 2, bruk av TLS-funksjoner" . Hentet 10. februar 2015 . 
  8. ↑ Biskop, Mike. "Hypertext Transfer Protocol versjon 3 (HTTP/3)" . tools.ietf.org (på engelsk) . Hentet 4. mai 2020 . 
  9. ↑ Cimpanu, Catalin. "HTTP-over-QUIC skal gis nytt navn til HTTP/3" . ZDNet (på engelsk) . Hentet 4. mai 2020 . 
  10. ↑ Cimpanu, Catalin. "Cloudflare, Google Chrome og Firefox legger til HTTP/3-støtte" . ZDNet (på engelsk) . Hentet 4. mai 2020 . 
  11. ^ "HTTP/3: fortiden, nåtiden og fremtiden" . Cloudflare- bloggen . 26. september 2019 . Hentet 4. mai 2020 . 
  12. ↑ "Firefox Nightly støtter HTTP 3" . Cloudflare Community (på amerikansk engelsk) . 6. november 2019 . Hentet 4. mai 2020 . 

Eksterne lenker