Het Hypertext Transfer Protocol (HTTP) is een netwerkprotocol voor gedistribueerde, samenwerkende, hypermedia informatiesystemen. HTTP is het fundament van datacommunicatie voor het World Wide Web.
De ontwikkeling van normen van HTTP is gecoördineerd door de Internet Engineering Task Force (IETF) en het World Wide Web Consortium (W3C), met als hoogtepunt de publicatie van een serie van Requests for Comments (RFC's), met name RFC 2616 (juni 1999) , die definieert HTTP/1.1, de versie van HTTP in gemeenschappelijk gebruik.
Technisch overzicht
HTTP functioneert als een verzoek-response protocol in de client-server computing-model. In HTTP, een webbrowser, bijvoorbeeld, werkt als een klant, terwijl een applicatie die draait op een computer het hosten van een website fungeert als een server. De klant dient een HTTP-verzoek bericht naar de server. De server, welke inhoud winkels, of biedt bronnen, zoals HTML-bestanden, of andere taken uitoefent ten behoeve van de opdrachtgever retourneert een antwoord bericht naar de klant. Een antwoord bevat voltooiing statusinformatie over het verzoek en bevat mogelijk alle content op verzoek van de opdrachtgever in zijn bericht.
Een web browser (of opdrachtgever) wordt vaak aangeduid als een user agent (UA). Andere user agents kan de indexering software wordt gebruikt door zoekmachines, bekend als web crawlers, of variaties van de web browser zoals voice browsers, die een interactief voice user interface aanwezig is.
Het HTTP-protocol is ontworpen om tussenliggende netwerkelementen vergunning voor het verbeteren of om communicatie tussen clients en servers. High-traffic websites vaak baat bij web-cache-servers die content leveren voor rekening van de oorspronkelijke, de zogenaamde origin server om de reactietijd te verbeteren. HTTP-proxy-servers via het netwerk van de grenzen te vergemakkelijken communicatie wanneer klanten zonder een globaal routeerbaar adres bevinden zich in prive-netwerken door het doorgeven van de verzoeken en antwoorden tussen clients en servers.
HTTP is een Application Layer-protocol is ontworpen in het kader van het Internet Protocol Suite. Het protocol definities veronderstellen een betrouwbare Transport Layer-protocol voor host-to-host overdracht van gegevens. Het Transmission Control Protocol (TCP) is de dominante protocol in gebruik is voor dit doel. Echter, HTTP-toepassing gevonden, zelfs met onbetrouwbare protocollen, zoals het User Datagram Protocol (UDP) in methoden, zoals het Simple Service Discovery Protocol (SSDP).
HTTP Resources worden geïdentificeerd en gelegen op het netwerk door Uniform Resource Identifiers (URI's) of, meer specifiek, Uniform Resource Locator (URL's)-met behulp van de http of https URI's. URI's en de Hypertext Markup Language (HTML), vormen een systeem van onderling verbonden middelen, de zogenaamde hypertext documenten op het internet, die leidde tot de oprichting van de World Wide Web in 1990 door Engels natuurkundige Tim Berners-Lee.
De originele versie van HTTP (HTTP/1.0) werd herzien in HTTP/1.1. HTTP/1.0 maakt gebruik van een afzonderlijke aansluiting op dezelfde server voor elke request-response transactie, terwijl de HTTP/1.1 kan een verbinding opnieuw meerdere keren, te downloaden, bijvoorbeeld, beelden voor een rechtvaardige geleverde pagina. Vandaar dat HTTP/1.1 communicatie-ervaring minder latency als het opzetten van TCP-verbindingen biedt veel overhead.
Geschiedenis
De term HyperText werd bedacht door Ted Nelson die op zijn beurt liet zich inspireren door Vannevar Bush 's microfilm-based' Memex '. Tim Berners-Lee voor het eerst voorgesteld het "WorldWideWeb"-project – nu bekend als het World Wide Web. Berners-Lee en zijn team zijn gecrediteerd met het uitvinden van de oorspronkelijke HTTP-protocol, samen met de HTML en de bijbehorende technologie voor een webserver en een op tekst gebaseerde webbrowser. De eerste versie van het protocol had slechts een methode, namelijk de GET, die een pagina van een server zou vragen. De reactie van de server was altijd een HTML-pagina.
De eerste gedocumenteerde versie van HTTP was HTTP v0.9 (1991). Dave Raggett leidde de HTTP Working Group (HTTP WG) in 1995 en wilde het protocol uitgebreide operaties, uitgebreide onderhandelingen, rijkere meta-informatie, gebonden met een beveiligingsprotocol uit te breiden, maar ik heb efficiënter maken door het toevoegen van extra methoden en header velden. RFC 1945 officieel geïntroduceerd en erkend HTTP V1.0 in 1996.
De HTTP WG plan om nieuwe normen te publiceren in december 1995 en de ondersteuning voor pre-standaard HTTP/1.1 op basis van de toenmalige ontwikkeling van RFC 2068 (de zogenaamde HTTP-NG) werd snel door de grote browser-ontwikkelaars in het begin van 1996. In maart 1996, pre-standaard HTTP/1.1 werd gesteund in Arena, Netscape 2.0, Netscape Navigator Gold 2.01, Mosaic 2.7, Lynx 2.5 , en met Internet Explorer 3.0 . Eindgebruiker goedkeuring van de nieuwe browsers is snel. In maart 1996, een web hosting bedrijf meldde dat meer dan 40% van de browsers in gebruik op het internet waren HTTP 1.1 compliant. Dat zelfde web hosting bedrijf meldde dat uiterlijk in juni 1996, 65% van alle browsers toegang tot hun servers waren HTTP/1.1 compliant. De HTTP/1.1 standaard zoals gedefinieerd in RFC 2068 werd officieel uitgebracht in januari 1997. Verbeteringen en updates aan de HTTP/1.1 standaard werden uitgebracht onder RFC 2616 in juni 1999.
HTTP-sessie
Een HTTP-sessie is een reeks van het netwerk van request-response transacties. Een HTTP-client initieert een verzoek door de oprichting van een Transmission Control Protocol (TCP) verbinding met een bepaalde poort op een host (meestal poort 80, zie Lijst van TCP-en UDP-poortnummers). Een HTTP-server luistert op die poort wacht op verzoek van een klant boodschap. Na ontvangst van het verzoek, stuurt de server weer een status regel, zoals "HTTP/1.1 200 OK", en een boodschap van haar eigen, het lichaam van die is misschien wel de aangevraagde bron, een foutmelding of een andere informatie.
Request-bericht
Het verzoek boodschap bestaat uit de volgende:
Verzoek lijn, zoals GET / images / logo.png HTTP/1.1, dat een bron genaamd / images / logo.png van de server aanvragen
Headers, zoals Accept-Taal: nl
Een lege regel
Een optionele berichttekst
Het verzoek lijn en headers moeten alle eindigen met <CR> <LF> (dat wil zeggen, een carriage return, gevolgd door een line feed). De lege regel moet bestaan uit slechts <CR> <LF> en geen andere witruimte. Hoewel <CR> <LF> is vereist <LF> alleen is ook geaccepteerd door de meeste servers. In de HTTP/1.1 protocol, alle headers behalve gastheer zijn optioneel.
Een verzoek regel met alleen de naam van het pad is geaccepteerd door servers om de compatibiliteit met HTTP-cliënten voor de HTTP/1.0 specificatie in RFC1945 te houden.
Verzoek methoden
HTTP definieert negen methoden (soms aangeduid als "werkwoorden") onder vermelding van de gewenste actie uit te voeren op de geïdentificeerde bron. Wat dit middel is, of de reeds bestaande gegevens of gegevens die dynamisch is gegenereerd, afhankelijk van de uitvoering van de server. Vaak is de bron komt overeen met een bestand of de uitgang van een executable die zich op de server.
Vraagt om de reactie identiek aan degene die zou overeenstemmen met een GET-verzoek, maar zonder de reactie van het lichaam. Dit is handig voor het ophalen van meta-informatie geschreven in antwoord headers, zonder dat de gehele inhoud transport.
Vraagt een representatie van de opgegeven bron. Aanvragen met behulp van GET (en een paar andere HTTP-methoden), "moeten niet de betekenis van het nemen van een ander optreden dan ophalen". Het W3C heeft richtsnoeren gepubliceerd principes op dit onderscheid, zeggende: "Web applicatie ontwerp moet worden geïnformeerd door de bovengenoemde beginselen, maar ook door de relevante beperkingen." Zie onderstaande veilige methoden.
Bezorgt gegevens te verwerken (bijvoorbeeld van een HTML-formulier) om de geïdentificeerde bron. De gegevens worden opgenomen in het lichaam van het verzoek. Dit kan resulteren in de creatie van een nieuwe bron of de updates van bestaande middelen, of beide.
Uploadt een weergave van de opgegeven bron.
DELETE
Verwijdert de opgegeven bron.
TRACE
Echo's terug te ontvangen verzoek, zodat een klant kan zien wat er (eventueel) wijzigingen of aanvullingen zijn gemaakt door tussenliggende servers.
OPTIES
Geeft de HTTP-methoden die de server worden ondersteund voor bepaalde URL. Dit kan worden gebruikt om de functionaliteit van een webserver controleren door het vragen van '*' in plaats van een specifieke bron.
CONNECT
Zet het verzoek verbinding met een transparante TCP / IP tunnel, meestal om SSL-versleutelde communicatie (HTTPS) vergemakkelijken door middel van een niet-versleutelde HTTP-proxy.
PATCH
Wordt gebruikt om de gedeeltelijke wijzigingen van toepassing zijn op een bron.
HTTP-servers zijn verplicht om ten minste de GET en de HEAD methoden en, indien mogelijk, ook de opties methode te implementeren.
Veilige methoden
Sommige methoden (bijvoorbeeld, HEAD, GET, opties en TRACE) worden gedefinieerd als veilig, wat betekent dat ze zijn alleen bedoeld voor information retrieval en mag niet veranderen van de status van de server. Met andere woorden, zouden zij niet bijwerkingen hebben, verder dan relatief onschadelijke effecten, zoals logging, caching, het serveren van banneradvertenties of verhogen van een web counter. Het maken van willekeurige GET-verzoeken zonder rekening te houden de context van de staat van de applicatie moet daarom worden als veilig beschouwd.
Daarentegen, methoden, zoals POST, PUT en DELETE zijn bestemd voor acties die beide kunnen bijwerkingen veroorzaken op de server, of externe bijwerkingen zoals financiële transacties of overdracht van e-mail. Dergelijke methoden worden daarom meestal niet gebruikt door zich te conformeren web robots of web crawlers, sommigen die niet voldoen hebben de neiging om vragen te stellen zonder rekening te houden context of gevolgen.
Ondanks de voorgeschreven veiligheid van GET verzoeken, in de praktijk hun behandeling door de server is technisch niet beperkt in any way. Daarom kan onzorgvuldig of opzettelijk programmering leiden tot niet-triviale veranderingen op de server. Dit wordt afgeraden, omdat het kan leiden tot problemen voor het web caching, zoekmachines en andere geautomatiseerde agentia, die onbedoelde veranderingen kunnen maken op de server.
Verder worden methoden zoals TRACE, TRACK en DEBUG beschouwd als potentieel 'onveilig' door een aantal security professionals, omdat ze kunnen worden gebruikt door aanvallers om informatie te verzamelen of te omzeilen security controles tijdens aanvallen. Security-software tools zoals Tenable Nessus en Microsoft URLScan verslag uit over de aanwezigheid van deze methoden als veiligheid.
Idempotent methoden en webapplicaties
Methoden PUT en DELETE zijn gedefinieerd worden idempotent, wat betekent dat meerdere identieke verzoeken moet het hetzelfde effect hebben als een enkel verzoek. Methoden GET, HEAD, opties en TRACE, worden voorgeschreven als veilig, moet ook worden idempotent, zoals HTTP is een stateless protocol.
In tegenstelling, de POST-methode is niet per se idempotent, en dus het sturen van een identieke POST-aanvraag meerdere malen verder kan de staat beïnvloeden of leiden tot verdere bijwerkingen (zoals financiële transacties). In sommige gevallen kan het wenselijk zijn, maar in andere gevallen kan dit te wijten zijn aan een ongeluk, zoals wanneer een gebruiker niet beseffen dat hun actie zal leiden tot het versturen een ander verzoek, of ze kreeg geen adequate feedback, dat hun eerste verzoek was succesvol. Terwijl de web browsers kunnen tonen alert dialoogvensters gebruikers te waarschuwen in sommige gevallen opnieuw laden van een pagina kan opnieuw in te dienen een POST-aanvraag, is het algemeen tot de webapplicatie tot gevallen waarin een POST-aanvraag niet meer dan een keer te worden ingediend af te handelen.
Merk op dat de vraag of een methode is idempotent niet wordt afgedwongen door het protocol of web-server. Het is perfect mogelijk het schrijven van een webapplicatie waarin (bijvoorbeeld) een database te voegen of een andere niet-idempotent actie wordt geactiveerd door een GET of een ander verzoek. Het negeren van deze aanbeveling, maar kan leiden tot ongewenste gevolgen, als een gebruiker-agent gaat ervan uit dat het herhalen van dezelfde aanvraag veilig is wanneer het niet.
Status codes
In HTTP/1.0 en aangezien, is de eerste regel van het HTTP-reactie genaamd de statusregel en bevat een numerieke code-status (zoals "404") en een tekstuele reden zin (zoals "Not Found"). De manier waarop de user agent handelt de respons in de eerste plaats afhankelijk van de code en secundair op de reactie van headers. Custom-status codes kunnen worden gebruikt, omdat, als de user agent tegenkomt een code niet wordt herkend, kan het eerste cijfer van de code gebruiken om de algemene klasse van de respons te bepalen.
Ook de standaard reden zinnen zijn slechts aanbevelingen en kan worden vervangen door "lokale equivalenten" op de web developer 's goeddunken. Als de status-code vermeld een probleem, de user agent kan de reden zin weer te geven aan de gebruiker om meer informatie over de aard van het probleem. De standaard maakt het ook mogelijk de user agent om te proberen de reden zin te interpreteren, maar dit zou niet verstandig zijn, aangezien de standaard uitdrukkelijk bepaalt dat de status codes zijn machine leesbare zinnen en de rede zijn voor mensen leesbare.
Permanente verbindingen
In HTTP/0.9 en 1.0, wordt de verbinding gesloten na een enkele vraag / antwoord paar. In HTTP/1.1 een keep-alive-mechanisme werd ingevoerd, waarbij een verbinding kan worden hergebruikt voor meer dan een verzoek.
Een dergelijke permanente verbindingen merkbaar te verminderen verzoek latency, omdat de cliënt niet opnieuw moet onderhandelen over de TCP-verbinding na het eerste verzoek is verzonden.
Versie 1.1 van het protocol bandbreedte optimalisatie verbeteringen aan HTTP/1.0. Bijvoorbeeld, HTTP/1.1 geïntroduceerd chunked overdracht codering naar inhoud toe te staan op permanente verbindingen moeten worden gestreamd, in plaats van gebufferd. HTTP pipelining vermindert de verdere vertraging, waardoor klanten meerdere aanvragen te sturen voor een eerdere reactie is ontvangen op de eerste. Een andere verbetering van het protocol was byte te dienen, dat is wanneer een server stuurt alleen het gedeelte van een bron uitdrukkelijk verzoek van een klant.
HTTP-sessie staat
HTTP is een stateless protocol. Een staatloze protocol niet vereist dat de server om informatie of status van elke gebruiker te behouden voor de duur van meerdere verzoeken. Bijvoorbeeld, wanneer een web server nodig is om de inhoud van een webpagina aanpassen voor een gebruiker, kan de webapplicatie moet de gebruiker de voortgang volgen van pagina naar pagina. Een gemeenschappelijke oplossing is het gebruik van HTTP-cookies. Andere methoden zijn server side sessies, verborgen variabelen (als de huidige pagina is een vorm) en URL-herschrijven met behulp van URI-gecodeerde parameters, bijvoorbeeld / index.php? Session_id = some_unique_session_code.
Secure HTTP
Er zijn drie manieren om een beveiligde HTTP-verbinding: HTTP Secure, Secure Hypertext Transfer Protocol en de HTTP/1.1 Upgrade header. Browser ondersteuning voor de laatste twee is echter, bijna non-existent, , zodat HTTP-Secure is de dominante methode om een beveiligde HTTP-verbinding.
Voorbeeld sessie
Hieronder staat een voorbeeld gesprek tussen een HTTP-client en een HTTP-server draait op www.example.com, poort 80.
Client verzoek
GET / index.html HTTP/1.1
Host: www.example.com
Een cliënt verzoek (bestaande uit in dit geval van het verzoek lijn en slechts een header) wordt gevolgd door een lege regel, zodat het verzoek eindigt met een dubbele newline, elk in de vorm van een carriage return, gevolgd door een line feed. De "Host" header wordt onderscheid gemaakt tussen de verschillende DNS-namen delen van een enkel IP-adres, zodat de naam-based virtual hosting. Terwijl optioneel in HTTP/1.0, is het verplicht in HTTP/1.1.
Antwoord van de server
HTTP/1.1 200 OK
Datum: maand. De 23 mei 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: woens 8-01-2003 23:11:55 GMT
ETAG: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text / html; charset = UTF-8
Een antwoord van de server wordt gevolgd door een lege regel en de tekst van de opgevraagde pagina. De ETag (entiteit tag) header wordt gebruikt om te bepalen of een cache-versie van de aangevraagde bron is identiek aan de huidige versie van de bron op de server. Content-Type geeft het internet media type van de gegevens overgebracht door de http-bericht, terwijl de Content-Length geeft de lengte in bytes. De HTTP/1.1 webserver publiceert zijn vermogen om op verzoeken om bepaalde byte reeksen van het document reageren door het instellen van de header Accept-Ranges: bytes. Dit is handig, indien de opdrachtgever dient te beschikken over slechts bepaalde delen van een bron die door de server, die wordt genoemd byte serveren. Wanneer Connection: close wordt verzonden in een header, betekent dit dat de webserver van de TCP-verbinding sluit onmiddellijk na de overdracht van deze reactie.
De meeste van de header lijnen zijn optioneel. Bij het Content-Length ontbreekt de lengte wordt bepaald met andere manieren. Chunked overdracht codering maakt gebruik van een chunk size van 0 tot het einde betekenen van de inhoud. Identiteit codering zonder Content-Length leest content totdat de socket is gesloten.
Een Content-Encoding zoals gzip kunnen worden gebruikt om de hoeveelheid data te beperken.