door Over de auteur: Staat achter de filosofiën van GNU en OpenSource, omdat dit het verspreiden van kennis bevordert. Hoewel hij er weinig tijd voor heeft, speelt hij graag saxofoon. Inhoud: Geschiedenis Het HTTP-protocol Functionaliteit Tot slot Talkback voor dit artikel

Apache - deel I

Kort:

Dit artikel gaat over de meest gebruikte webserver genaamd Apache. Het is verdeeld in twee delen. In het eerste deel beschrijf ik in het kort de gescheidenis van het World Wide Web en in het tweede deel geef ik een introductie over het HTTP-protocol.

Geschiedenis

Apache is de naam van een server die het HTTP protocol spreekt, en dus een zogenaamde webserver is. De naam Apache heeft een onduidelijke achtergrond: sommige mensen zeggen dat het een verbastering is van een "a patchy" (=gebrekkige) server, omdat het begin van de ontwikkeling veel patches (=verbeteringen) nodig waren om de server bruikbaar te maken.
Andere mensen beweren dat het programma vernoemd is naar de Amerikaanse Apache-indianen, die zeer goed met onverwachte omstandigheden konden omgaan.

Apache is veruit de meest gebruikte webserver voor het internet. Het berust op versie 1.1 van het HTTP-protocol dat is vastgesteld door het World Wide Web Consortium (W3C). Een onderzoek van Netcraft uit juni 1999 wees uit dat meer dan 60 procent van alle webservers de Apache software gebruikt.

Een webserver is de "server" kant in een client-server-model, dat letterlijk vertaald klant-dienstverlener betekent. Een webserver beantwoort vragen van de "webclient" zoals Netscape of Lynx. De vragen die de webclient -of webbrowser- stelt zijn van de vorm: "Heb jij die ene webpagina?". Het antwoord dat de webserver daarna geeft is van de vorm: "Het artikel luidt: ..." of "Ik kan de webpagina niet vinden.".  

Het HTTP-protocol

1. De vraag:
   

   dit is een regel tekst die verdeeld is in drie stukken:

   [vraagtype] [URL] [protocolversie]
   1. [vraagtype]
      Mogelijke vraagtypen zijn: GET, POST, HEAD, PUT, DEL en TRACE.
   2. [URL]
      De URL (Uniform Request Locator) is de bestandsnaam en directory van de webpagina die je wilt opvragen. Voorbeeld: als je de webpagina http://www.linuxfocus.org/Nederlands/index.html wilt opvragen, is de URL in de clientvraag /Nederlands/index.html.
   3. [protocolversie]
      De protocolversie kan HTTP/1.0 en HTTP/1.1 zijn.
   Deze vereiste regel mag gevolgd worden door andere regels om de clientvraag toe te lichten, zoals we zullen zien in een HTTP/1.1 vraag.

2. Het antwoord :

   
   

   Het antwoord van de server is opgebouwd uit een header (=kopregels) en een inhoud.

     Een voorbeeld. We kunnen het gedrag van een webclient nabootsen met een telnet programma. De webserver is te bereiken via een serveradres en een poortnummer. In het volgende voorbeeld is het adres van de webserver www.linuxfocus.org en het poortnummer is 80, het standaard poortnummer voor webservers.

   >telnet www.linuxfocus.org 80 Trying 195.53.25.18... Connected to nova.linuxfocus.org. Escape character is '^]'. GET / HTTP/1.0 <return> <return> HTTP/1.1 200 OK Date: Mon, 27 Sep 1999 21:23:20 GMT Server: Apache/1.3.3 (Unix)  (Red Hat/Linux) Last-Modified: Sun, 26 Sep 1999 16:40:44 GMT ETag: "4b005-1616-37ee4c8c" Accept-Ranges: bytes Content-Length: 5654 Connection: close Content-Type: text/html <PAGE HTML>

   Wat staat hier nou eigenlijk?
   De eerste regel van het antwoord geeft de gebruikte protocolversie (HTTP/1.1), een antwoordnummer (200) en tenslotte de tekst "OK". Het antwoordnummer geeft informatie over de aard van het antwoord. Een nummer groter dan 400, geeft aan dat er een fout is opgetreden. De meest voorkomende fout, is de 404-fout, dat aangeeft dat de opgevraagde webpagine niet aanwezig is.
   Daarna volgen een aantal regels die (met de eerste regel) de header vormen. Deze regels geven telkens informatie in de vorm "Naam: info". Zo geven de volgende regels een datum, de versie van de server en de datum van de laatste verandering van de webpagina (hierdoor kan de client nagaan of zijn cache nog geldig is). De regel die begint met Content-Length geeft de lengte van de inhoud van het antwoord waarin de echt informatie staat en Content-Type vertelt de client van welk MIME-type de teruggegeven informatie is (tekst, HTML, plaatjes ...).

   Dit is geen volledige beschrijving; sommige lijnen zijn voor mij ook een raadsel ;-)
   Laten we eens kijken of we een fout kunnen veroorzaken:

   >telnet www.linuxfocus.org 80 Trying 195.53.25.18... Connected to nova.linuxfocus.org. Escape character is '^]'. GET / HTTP/1.0 <return> <return> HTTP/1.1 501 Method Not Implemented Date: Mon, 27 Sep 1999 21:22:03 GMT Server: Apache/1.3.3 (Unix)  (Red Hat/Linux) Allow: GET, HEAD, OPTIONS, TRACE Connection: close Content-Type: text/html

   Zoals je ziet, geeft de header heel veel informatie ;-)
   Het HTTP-protocol is erg eenvoudig zoals we ook in de volgende voorbeelden zullen zien:

   >telnet www.linuxfocus.org 80 Trying 195.53.25.18... Connected to nova.linuxfocus.org. Escape character is '^]'. GET / <return>

   [de inhoud van de webpagina index.html van de website www.linuxfocus.org wordt dan getoond ] ..

   Wat doet de Apache server nou eigenlijk?
   In het bovenstaande voorbeeld heb je met telnet via poort 80 contact gemaakt met de webserver van www.linuxfocus.org (IP adres 195.53.25.1). De server wachtte vervolgens op een vraag en die gaf je door GET / te typen gevolgd door twee keer een carraige return.
   Waarom is één carriage return niet genoeg?
   De lege regel na de GET-opdracht geeft de server het teken dat dit het eind van de vraag is. De server begint na dit signaal met het beantwoorden van de vraag en het sturen van het antwoord. Als het gesprek voorbij is wordt de TCP/IP-verbinding door de server verbroken.

   De voorbeelden zijn tot nu toe erg simple van vorm, maar zeer belangrijk voor het WWW. Het wordt iets ingewikkelder als we gebruik gaan maken van HTTP versie 1.1. Een gesprek dat er met HTTP/1.0 er zo uit ziet:

   GET / HTTP/1.0 <return>
   <return>
   HTTP/1.1 200 OK
   Date: Tue, 24 Aug 1999 22:25:11 GMT
   Server: Apache/1.3.3 (Unix)  (Red Hat/Linux)
   Last-Modified: Sun, 01 Aug 1999 11:50:52 GMT
   ETag: "4b005-1462-37a4349c"
   Accept-Ranges: bytes
   Content-Length: 5218
   Connection: close
   Content-Type: text/html
   
   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ....
   

   ziet er met HTTP/1.1 zo uit:

   GET / HTTP/1.1 <return>
   <return>
   HTTP/1.1 400 Bad Request
   Date: Tue, 24 Aug 1999 22:24:59 GMT
   Server: Apache/1.3.3 (Unix)  (Red Hat/Linux)
   Connection: close
   Transfer-Encoding: chunked
   Content-Type: text/html
   
   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
   <HTML><HEAD>
   <TITLE>400 Bad Request</TITLE>
   </HEADBODY>
   <H1>Bad Request</H1>
   Your browser sent a request that
   this server could not understand.<P>
   client sent HTTP/1.1 request without hostname (see RFC2068 section 9, and 14.23): </P>
   </BODY></HTML>
   

   Dezelfde vraag in versie 1.1 van het HTTP-protocol vereist dat er meer informatie met de vraag wordt meegezonden. De extra informatie die meegestuurd wordt, maakt de vraag specifieker en daarmee de inhoud van het gesprek nauwkeuriger en beter.
   Hieronder staat de correcte clientvraag in HTTP/1.1. De programmeurs van het Apache-project zijn zeer strict geweest in het naleven van de specificatie van dit protocol. Maar dit protocol maakt hoewel stricter ook meer mogelijk, zoals: authenticatie, virtuele websites (meerdere websites met hetzelfde IP-adres) en meer ...

   Een voorbeeld:

   GET / HTTP/1.1 <return>
   Host:www.linuxfocus.org<return>
   <return>
   [...]
   

   Zoals bij de meeste client-server systemen zal de server het volgende doen als hij een vraag ontvangt:

   • het start een apart process om het antwoord te gaan beantwoorden;
   • het "parent" process blijft luisteren naar nieuwe vragen terwijl de vorige vraag nog niet beantwoord is.
   • het aparte, "child" process beantwoord ondertussen de vraag en het process zal gestopt worden als de vraag beantwoord is.
    

   Functionaliteit

   Het algemen principe is dat een webserver maar één antwoord kan geven aan de client die de vraag stelde. De client stuurt een vraag en krijgt daarop het antwoord.

   De webserver is hiermee een interface tussen de webclient die het document opvraagt dat bij een URL hoor, en het besturingssysteem waarop Apache draait. Andere namen voor URL gebruikt worden zijn URI en URN die een iets andere betekenis hebben, maar op precies hetzelfde neerkomen: een unieke naam voor een webpagina.

   Sommige clientvragen kunnen niet direct door de server beantwoord worden. In dat geval kan de server een ander programma starten die de vraag probeert op te lossen. Dit is precies hoe CGI-scripten (Common Gateway Interface) werken.  

   Tot slot

   Om te leren begrijpen hoe webservers, zoals Apache, werken, kunt u het beste telnet gebruiken om ze te bestuderen. Op deze manier ziet u precies welke software een specifieke website gebruikt en hoe de informatie is opgebouwd die de server als antwoord geeft.  

   Talkback voor dit artikel

   Elk artikel heeft zijn eigen talkback pagina. Daar kan je commentaar geven of commentaar van anderen lezen:

   ga naar de talkback pagina

   ---

   Site onderhouden door het LinuxFocus editors team © Charles vidal LinuxFocus.org 2000 Klik hier om een fout te melden of commentaar te geven

   Translation information: fr -> -- fr -> en fr -> en en -> nl

   2000-05-08, generated by lfparser version 1.5