Hypertext overdrachtsprotocol

hypertext overdrachtsprotocol
Familie	Internet protocol familie
Functie	hypertekstoverdracht _
Laatste versie	3,0 (2018)
poorten	80/TCP
Locatie in de protocolstack
App HTTP vervoer TCP Netto IK P
normen
Oorspronkelijke HTTP (HTTP/0.9, 1991 ) RFC 1945 (HTTP/1.0, 1996 ) RFC 2616 (HTTP/1.1, 1999 ) RFC 2774 ( HTTP/1.2 [ nodig citaat ] , 2000 ) RFC 7230 , RFC 7231 , RFC 7232 , RFC 7233 , RFC 7234 , RFC 7235 (revisie van HTTP/1.1, 2014 ) RFC 7540 ( HTTP/2 , 2015 ) Hypertext Transfer Protocol versie 3 ( HTTP/3 , 2018 ) ( Internet Draft )

Het Hypertext Transfer Protocol (in het Engels , Hypertext Transfer Protocol , afgekort HTTP ) is het communicatieprotocol dat informatieoverdracht via bestanden (XML, HTML ...) op het World Wide Web mogelijk maakt . Het werd ontwikkeld door het World Wide Web Consortium en de Internet Engineering Task Force , een samenwerking die culmineerde in de publicatie van een reeks RFC's in 1999 , waarvan de belangrijkste RFC 2616 was, waarin versie 1.1 werd gespecificeerd. HTTP definieert de syntaxis en semantiek die worden gebruikt door de software-elementen van de webarchitectuur (clients, servers, proxy's ) om te communiceren.

HTTP is een staatloos protocol , dus het slaat geen informatie op over eerdere verbindingen. De ontwikkeling van webapplicaties moet vaak op peil blijven. Hiervoor worden cookies gebruikt , dit is informatie die een server op het clientsysteem kan opslaan . Hierdoor kunnen webapplicaties het idee van een sessie instellen en kunnen gebruikers ook worden gevolgd, aangezien cookies voor onbepaalde tijd op de client kunnen worden opgeslagen.

Beschrijving

Het is een transactiegericht protocol en volgt het verzoek-antwoordschema tussen een client en een server. De client (vaak " user agent " genoemd ) doet een verzoek door een bericht, in een bepaald formaat, naar de server te sturen. De server (gewoonlijk een webserver genoemd) stuurt u een antwoordbericht. Voorbeelden van clients zijn webbrowsers en webspiders (ook bekend onder de Engelse term webcrawlers ).

Berichten

HTTP-berichten zijn in platte tekst , wat het leesbaarder en gemakkelijker te debuggen maakt. Dit heeft echter het nadeel dat berichten langer worden. De berichten hebben de volgende opbouw:

• Beginregel (eindigt met regelterugloop en een regelinvoer) met
  • Voor verzoeken: de door de server vereiste actie ( verzoekmethode ) gevolgd door de URL van de bron en de HTTP-versie die door de client wordt ondersteund.
  • Voor antwoorden: de versie van de gebruikte HTTP gevolgd door de antwoordcode (die aangeeft wat er met het verzoek is gebeurd, gevolgd door de URL van de bron) en de zin die bij die terugkeer hoort.
• Berichtkoppen die eindigen op een lege regel. Het zijn metagegevens . Deze headers geven het protocol een grote flexibiliteit.
• Bericht lichaam. Het is optioneel. Zijn aanwezigheid hangt af van de vorige regel van het bericht en het type bron waarnaar de URL verwijst. Het heeft meestal de gegevens die worden uitgewisseld tussen client en server. Voor een verzoek kan het bijvoorbeeld bepaalde gegevens bevatten die u naar de server wilt sturen voor verwerking. Voor een reactie kunt u de gegevens opnemen waar de opdrachtgever om heeft gevraagd.

Methoden aanvragen

Een HTTP-verzoek via telnet . De request , response headers en response body zijn gemarkeerd.

HTTP definieert een vooraf gedefinieerde set aanvraagmethoden (soms "werkwoorden" genoemd) die kunnen worden gebruikt. Het protocol heeft de flexibiliteit om nieuwe methoden toe te voegen en zo nieuwe functionaliteiten toe te voegen. Het aantal aanvraagmethoden is toegenomen naarmate de versies vorderden. Deze lijst bevat de methoden die door WebDAV zijn toegevoegd .

Elke methode geeft de actie aan die u wilt uitvoeren op de geïdentificeerde resource. Wat deze bron vertegenwoordigt, hangt af van de servertoepassing. De bron kan bijvoorbeeld overeenkomen met een bestand dat zich op de server bevindt.

KRIJGEN

De GET-methode vraagt ​​om een ​​representatie van de opgegeven resource. Verzoeken die GET gebruiken, mogen alleen gegevens ophalen en mogen geen ander effect hebben. (Dit geldt ook voor sommige andere HTTP-methoden.)

HOOFD

RFC2616 . Het vraagt ​​om een ​​antwoord dat identiek is aan het antwoord dat zou overeenkomen met een GET-verzoek, maar de hoofdtekst wordt niet geretourneerd in het antwoord. Dit is handig om de metadata uit de responsheaders te kunnen halen, zonder dat je de hele inhoud hoeft te dragen.

POST

RFC2616 . Verzendt gegevens die moeten worden verwerkt door de bron die is geïdentificeerd in de URL van de aanvraagregel. De gegevens worden opgenomen in de hoofdtekst van het verzoek. Op semantisch niveau is het gericht op het creëren van een nieuwe bron, waarvan de aard wordt gespecificeerd door de Content-Type- header . Voorbeelden:

• Voor formuliergegevens die zijn gecodeerd als een URL (hoewel het in de hoofdtekst van het verzoek reist, niet in de URL): application/x-www-form-urlencoded
• Om blokken te beklimmen, bijv. bestanden: multipart/form-data
• Naast het bovenstaande is er geen verplichte standaard en kunnen het ook andere zijn zoals text/plain , application/json , application/octet-stream ,...

PUT

( RFC 2616 ) Het stuurt gegevens naar de server, maar in tegenstelling tot de POST-methode, verwijst de URI van de verzoekregel niet naar de bron die het zal verwerken, maar identificeert eerder de gegevens zelf (zie gedetailleerde uitleg in de RFC ). Een ander verschil met POST is de semantiek (zie REST ): terwijl POST is gericht op het maken van nieuwe inhoud, is PUT meer gericht op het bijwerken ervan (hoewel het deze ook zou kunnen maken).

Voorbeeld:

PUT /pad/bestandsnaam.html HTTP/1.1

VERWIJDEREN

RFC2616 . Verwijdert de opgegeven bron.

TRACE

( RFC 2616 ) Deze methode vraagt ​​de server om in het antwoord alle gegevens in te voegen die het ontvangt in het verzoekbericht. Het wordt gebruikt voor foutopsporing en diagnostische doeleinden, omdat de client kan zien wat er op de server aankomt en op deze manier alles kan zien wat de tussenliggende servers aan het bericht toevoegen.

OPTIES

RFC2616 . Retourneert de HTTP-methoden die de server ondersteunt voor een specifieke URL. Dit kan worden gebruikt om de functionaliteit van een webserver op verzoek te controleren in plaats van een specifieke bron.

VERBINDEN

RFC2616 . Het wordt gebruikt om te weten of u toegang hebt tot een host, niet noodzakelijkerwijs bereikt het verzoek de server, deze methode wordt voornamelijk gebruikt om te weten of een proxy ons toegang geeft tot een host onder speciale voorwaarden, zoals versleutelde bidirectionele gegevensstromen. (zoals vereist door SSL).

PATCH

( RFC 5789 ). De functie is hetzelfde als PUT, die een resource volledig overschrijft. Het wordt gebruikt om een ​​of meer onderdelen gedeeltelijk bij te werken. Het is ook bedoeld voor gebruik met proxy . ]

VERPLAATSEN

RFC 2518

MKCOL

RFC 2518

PROPFIND

RFC 2518

PROPPATCH

RFC 2518

SAMENVOEGEN

RFC 3253

BIJWERKEN

RFC 3253

ETIKET

RFC 3253

Responscodes

De antwoord- of retourcode is een getal dat aangeeft wat er met het verzoek is gebeurd. De rest van de inhoud van het antwoord hangt af van de waarde van deze code. Het systeem is flexibel en in feite is de lijst met codes steeds langer geworden om zich aan te passen aan veranderingen en nieuwe situaties te identificeren. Elke code heeft een specifieke betekenis. Het aantal codes wordt echter zo gekozen dat, afhankelijk van of het bij honderd of een ander hoort, het type antwoord van de server kan worden geïdentificeerd:

• 1xx formaat codes: informatieve reacties. Geeft aan dat het verzoek is ontvangen en wordt verwerkt.
• Codes met 2xx-formaat: juiste antwoorden. Geeft aan dat het verzoek correct is verwerkt.
• Codes met 3xx formaat: Redirect reacties. Geeft aan dat de client verdere actie moet ondernemen om het verzoek te voltooien.
• Codes met 4xx-formaat: Fouten veroorzaakt door de klant. Geeft aan dat er een fout is opgetreden bij het verwerken van het verzoek omdat de client iets verkeerd heeft gedaan.
• 5xx-formaatcodes: fouten veroorzaakt door de server. Geeft aan dat er een fout is opgetreden bij het verwerken van het verzoek vanwege een serverstoring.

Kopteksten

Het zijn de metadata die worden verzonden in HTTP-verzoeken of -antwoorden om essentiële informatie over de huidige transactie te verstrekken. Elke koptekst wordt gespecificeerd door een koptekstnaam gevolgd door een dubbele punt, een spatie en de waarde van die kop, gevolgd door een regelterugloop gevolgd door een regelinvoer. Een lege regel wordt gebruikt om het einde van kopteksten aan te geven. Als er geen koppen zijn, moet de lege regel blijven staan.

De headers geven een grote flexibiliteit aan het protocol waardoor nieuwe functionaliteiten kunnen worden toegevoegd zonder de basis te hoeven veranderen. Dat is de reden waarom naarmate de versies van HTTP plaatsvinden, er steeds meer toegestane headers zijn toegevoegd.

De headers kunnen metadata bevatten die door de client moeten worden verwerkt (bijv. in reactie op een verzoek kan het type inhoud dat het bevat worden aangegeven), door de server (bijv. soorten representaties die acceptabel zijn voor de client van de inhoud die het vraagt) of door tussenpersonen (bijvoorbeeld hoe caching door proxy's te beheren )

Afhankelijk van het type bericht waarin een header kan komen, kunnen we ze indelen in request headers, response headers en headers die zowel in een request als een response kunnen gaan.

We kunnen headers classificeren op basis van hun functie. Bijvoorbeeld:

• Headers die de mogelijkheden aangeven die door de afzender van het bericht zijn geaccepteerd: Accept (geeft de geaccepteerde MIME aan), Accept-Charset (geeft de geaccepteerde tekencode aan), Accept-Encoding (geeft de geaccepteerde compressiemethode aan), Accept-Language (geeft de geaccepteerde tekencode aan), Accept-Encoding (geeft de geaccepteerde compressiemethode aan), Accept-Language (geeft de geaccepteerde taal), User-Agent (om de client te beschrijven), Server (geeft het type server aan), Toestaan ​​(toegestane methoden voor de bron)
• Headers die de inhoud beschrijven: inhoudstype ( geeft de MIME van de inhoud aan), inhoudslengte (lengte van het bericht), inhoudsbereik , inhoudscodering , inhoudstaal , inhoudslocatie .
• Headers die verwijzen naar URI's: Locatie (geeft aan waar de inhoud zich bevindt), Referer (geeft de oorsprong van het verzoek aan).
• Streambesparende headers : Datum (aanmaakdatum), If-Modified-Since , If-Unmodified-Since , If-Match , If-None-Match , If-Range , Expires , Last-Modified , Cache-Control , Via , Pragma , Etag , Leeftijd , Opnieuw proberen .
• Cookie control headers: Set-Cookie , Cookie
• Headers voor authenticatie: Authorization , WW-Authenticate
• Headers om de communicatie te beschrijven: Host (geeft de bestemmingsmachine van het bericht aan), Connection (geeft aan hoe de verbinding tot stand moet worden gebracht)
• Anderen: Bereik (om alleen delen van de bron te downloaden), Max-Forward (limiet van headers toegevoegd in TRACE).

HTTP-dialoogvoorbeeld

Een bron ophalen met de URL http://www.example.com/index.html

1. Er wordt een verbinding geopend op poort 80 van de host www.example.com . Poort 80 is de standaardpoort voor HTTP. Als u de XXXX-poort wilt gebruiken, moet u deze coderen in de URL in de vorm http://www.example.com:XXXX/index.html
2. Een bericht wordt in de volgende stijl verzonden:

GET /index.html HTTP/1.1
 Host: www.voorbeeld.com
 Verwijzer: www.google.com
 Gebruikersagent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/2010101 Firefox/45.0
 Verbinding: keep-alive
 [blanco lijn]

De serverrespons bestaat uit headers gevolgd door de gevraagde bron, in het geval van een webpagina:

HTTP/1.1 200 OK
Datum: vr 31 dec 2003 23:59:59 GMT
Inhoudstype: tekst/html
Inhoud-lengte: 1221

<html lang="eo">
<head>
<meta charset="utf-8">
<title>Sitetitel</title>
</head>
<lichaam>
<h1>YourHost-startpagina</h1>
(Inhoud)
  .
  .
  .
</body>
</html>

Versies

HTTP heeft meerdere versies van het protocol doorlopen, waarvan vele achterwaarts compatibel zijn. RFC 2145 beschrijft het gebruik van HTTP-versienummers. De client vertelt de server aan het begin van het verzoek welke versie hij gebruikt, en de server gebruikt dezelfde of een eerdere versie in zijn antwoord.

0.9 (uitgebracht in 1991)

verouderd. Het ondersteunt slechts één opdracht, GET, en specificeert ook niet het HTTP-versienummer. Ondersteunt geen kopteksten. Aangezien deze versie POST niet ondersteunt, kan de client niet veel informatie naar de server sturen.

HTTP/1.0 (mei 1996)

Dit is de eerste herziening van het protocol die de versie ervan specificeert in communicatie, en het wordt nog steeds veel gebruikt, vooral in proxyservers. Staat GET-, HEAD- en POST-verzoekmethoden toe.

HTTP/1.1 (juni 1999) ]

Momenteel meest gebruikte versie; ^{[ nodig citaat ]} Persistente verbindingen zijn standaard ingeschakeld en werken prima met proxy's . Het stelt de klant ook in staat om meerdere verzoeken tegelijkertijd over dezelfde verbinding te verzenden ( pipelining ), wat het mogelijk maakt om de Round-Trip-vertragingstijd voor elk verzoek te elimineren.

HTTP/1.2 (februari 2000)

De eerste ontwerpen uit 1995 van het PEP - een Extension Mechanism for HTTP- document (dat het Protocol Extension Protocol voorstelt , afgekort PEP) werden gemaakt door het World Wide Web Consortium en ingediend bij de Internet Engineering Task Force . De PEP was oorspronkelijk bedoeld om een ​​onderscheidend bereik van HTTP/1.2 te worden. In latere versies is de verwijzing naar HTTP/1.2 echter verwijderd. RFC 2774 ( experimenteel), HTTP Extension Framework , bevat zwaar PEP. Het werd gepubliceerd in februari 2000.

HTTP/2 (mei 2015)

In 2012 verschijnen de eerste concepten van de nieuwe versie van HTTP ( HTTP/2 ). Deze nieuwe versie verandert niets aan de applicatiesemantiek van http (alle basisconcepten blijven ongewijzigd). De verbeteringen zijn gericht op de manier waarop gegevens worden verpakt en op transport. Voeg bijvoorbeeld het gebruik van een enkele verbinding, headercompressie of de 'server push'-service toe. Grote browsers ondersteunen alleen HTTP 2.0 via TLS met behulp van de ALPN- extensie ​waarvoor TLSv1.2 of hoger vereist is. ]

HTTP/3 (oktober 2018)

HTTP/3 is de voorgestelde opvolger van HTTP/2, ​ dat al in gebruik is op het web, met UDP in plaats van TCP voor het onderliggende transportprotocol. Net als HTTP/2 is het niet verouderd in eerdere hoofdversies van het protocol. Ondersteuning voor HTTP/3 is toegevoegd aan Cloudflare en Google Chrome in september 2019 ​ en kan worden ingeschakeld in stabiele versies van Chrome en Firefox . ]

Zie ook

• Beveiliging van transportlaag
• HTTPS
• HTTP strikte transportbeveiliging
• HTTP (P2P)
• HTTP/2
• .har

Externe links

• RFC-2616
• HTTP - Hypertext Transfer Protocol. W3C
• HTTP echt gemakkelijk gemaakt. door James Marshall, 1997
• HTTP-headersvalidatie Online URL-verificatie
• HTTP/2-compatibiliteitstest