[HTTP]Responses en Requests

Het HTTP of HyperText Transfer Protocol is één van de meest gebruikte en successvolle protocollen op het internet. Het behoort tot de toepassingslaag van het OSI model en was oorspronkelijk bedoelt om niet meer dan hypertext over netwerken te versturen. Maar vandaag kan het heel wat meer soorten objecten en bestanden overbrengen.
In deze tutorial bespreken we de algemene werking van het HTTP.

1. Geschiedenis
2. Terminologie
3. Request
4. Response
5. Extra
6. Bronnen

---

1. Geschiedenis

---

De eerste versie van het protocol, HTTP 0.9 is geschreven door Tim Berners-Lee in 1991. Deze versie was aanvankelijk heel simpel, en is later in 1996 opgenomen als subset van HTTP 1.0(ook geschreven door Tim Berners-Lee), waardoor het backwards compatible werd met versie 0.9. Vandaag de dag gebruiken we HTTP 1.1, ingediend door Tim Berners-Lee als RFC en uiteindelijk als standaard bekrachtigd door de IETF. Grote verschillen tussen versie 1.0 en 1.1 zijn dat HTTP 1.1 caching en meerder requests per geopende connectie ondersteund tov HTTP 1.0(persistente connecties).
Hedendaags is de werkgroup HTTPbis van het IETF actief bezig met het 'verfijnen' van de oorspronkelijke RFC. Er wordt gestreefd naar het corrigeren van fouten, het wegnemen van verwaarloosde functionaliteiten en het implenteren van nieuwe functionaliteiten.

top

---

2. Terminologie

---

Een protocol gaat gepaard met vele begrippen. Hieronder vind je een lijst met de belangrijkste termen, die je tevens ook in deze tutorial zal tegenkomen. Enkele begrippen zijn misschien al bekend, maar kunnen hier een andere betekenis hebben.

Message
HTTP ‘datapakketje’ kan zowel een request als een response zijn
User Agent of Client
Het medium waarmee de gebruiker HTTP messages verstuurd en ontvangt, meestal is dit de browser.
Request
De aanvraag van een client of user agent om bepaalde data
Response
Het antwoord van de server op een request.
Entity
Data of resource die wordt verstuurd bij een request of response. Een entity bestaat uit een entity-body en entity-headers. De entity headers zijn gewone headers, maar met betrekking tot de entity-body. Zowel de POST data als een webpagina zijn voorbeelden van een entity-body.
Server
In dit geval niet een server als hardware, maar de HTTP server software, de applicatie die op de server draait en requests ontvangt en beantwoord met responses.
Header-fields
Ook wel headers genoemd. Headers zijn stukjes data die je in een message kan terugvinden en additionele informatie over de user agent, de server of de message bevatten.
URI
Universal Resource Identifier. Dit is een naamgeving voor resources op het internet. Een URI kan bestaan uit een URL(Universal resource locator), een URN(Universal Resource Name) of beide. Een URN geeft de naam van een resource weer, maar niet waar deze zich bevind. Een URL geeft dan wel de locatie van de resource weer.

top

---

3. Request

---

Wanneer je naar sitemasters.be wil surfen, tik je dit in je browser in en verstuurt die voor jou een request die er als volgt kan uitzien:


Laten we deze even kort ontleden:


Dit is de belangrijkste regel uit onze request. Het vertelt de server namelijk dat we de webroot van de server willen opvragen, dit komt in dit geval overeen met index.php. We verstuurden zonet een request met de request method GET, dit wil zeggen dat we de opgevraagde resource willen ontvangen voor presentatie(in bijvoorbeeld een browser). Er zijn verschillende request methods, de meest gebruikte is GET. Hieronder volgt een overzicht:

GET
Vraagt data op om deze te presenteren.
POST
Verstuurt data naar de server, zodat deze daar een bepaalde handeling mee of op kan verrichten. Wanneer je inlogt op sitemasters verstuur je je logingegevens via een POST request naar de server.
HEAD
Vraagt alleen de response headers terug. Dit kan handig zijn om bijvoorbeeld meta data op te vragen zonder de hele pagina te moeten ontvangen.
PUT
Plaatst een opgegeven resource op de server. Deze request method wordt gebruikt bij het uploaden van bestanden.
DELETE
Verwijdert de opgegeven resource
TRACE
Stuurt de request terug zoals de server ze heeft ontvangen. Dit kan gebruikt worden om te kijken of er bepaalde wijzigingen worden aangebracht aan de request terwijl het wordt verstuurd(Bijvoorbeeld om een proxy te detecteren).
OPTIONS
Stuurt de request methods terug die de server voor de opgegeven URI ondersteund.
CONNECT
Verandert de connectie in een TCP/IP ‘tunnel’ waarin SSL connecties kunnen plaatsvinden. De server zelf functioneert dus als een proxy van waaruit SSL connecties kunnen gelegd worden.


Deze regel is ook niet geheel onbelangrijk, aangezien het een verplichte header is. Het geeft de naam en eventueel ook het poortnummer van de internet host waarnaar we onze request sturen aan.


Dit zijn tenslotte de headers. Deze zijn niet verplicht, maar zoals je kan zien geven de headers veel informatie aan de server over de user agent. Dit kan door de server gebruikt worden voor Content Negotiation. Maar daar gaan we in deze tutorial niet verder op in.

top

---

4. Response

---

Nadat de user agent een request heeft verstuurd, moet de server daar natuurlijk op antwoorden met een response. De response op bovenstaande request kan er zo uitzien:


Laten we ook deze response ontleden:


Het belangrijkste deel van onze response, de status code. De status code is hier 200 en betekend dat het request succesvol kan worden teruggestuurd. Afhankelijk van welke request method er gebruikt wordt, kan de gevraagde resource/actie worden teruggestuurd/uitgevoerd.
Het HTTP kent een groot aantal status codes, een volledige lijst kan je terugvinden in de sectie Bronnen.


Dit zijn ook weer onze headers, die deze keer informatie bevatten over de server en de verbinding. De Headers met betrekking tot Keep-alive kan men vrijwel als nutteloos beschouwen. Ze zouden namelijk moeten aanduiden dat de connectie geopend moet blijven voor eventueel volgende requests. Maar connecties naar HTTP 1.1 servers zijn standaard altijd persistent, tenzij dit anders wordt aangegeven.

Bij deze response zijn er ook 2 headers terug te vinden die oorspronkelijk geen officiële HTTP headers zijn, nl. “Keep-alive" en “X-powered-by". Hoewel het hier om twee niet officiële headers gaat, zijn ze toch algemeen gekend en de request wordt door de user agent begrepen. Headers die niet door de user agent of server worden herkend, worden gewoonweg genegeerd, ze hebben geen verder invloed op de response of request. De header “X-Powered-By" wordt toegevoegd door PHP, en de header" Keep-Alive" wordt door de meeste user agents(lees: browsers) herkend omdat een groot aantal server distributies deze gebruikt.


Ik heb hier de echte entity vervangen, omdat ik de hele html broncode code van sitemasters.be hier niet ga weergeven. Maar dat is dus wel de echte response entity die deze response bevat.

top

---

5. Extra

---

In de twee vorige puntjes heb je kunnen zien hoe een request en zijn bijbehorende response er kunnen uitzien. Hierbij hebben we echter maar één request gestuurd, een request om de index pagina van sitemasters op te halen. Je hebt dus nog geen CSS, afbeeldingen of externe Javascript opgevraagd. Het is niet zo dat het HTTP maar één connectie toestaat. De browser weet echter nog niet dat er bij de opgevraagde resource(index.php) ook nog een groot aantal andere resources bijhoren. De browser moet eerst de gekregen index pagina interpreteren, voor hij inziet dat er nog meerdere resources bij de index pagina horen. Bijgevolg stuurt de browser dus voor elke afbeelding, stylesheet en javascript een nieuwe request.

top

---

6. Bronnen

---

Je kan alle richtlijnen ivm het HTTP nalezen in RFC 2616. Het is ook aan te raden zelf wat HTTP requests en responses te bekijken. Je vindt genoeg applicaties of browser addons waarmee je je HTTP messages kan bekijken.

top