Apache
El protocol HTTP (HyperText Transfer Protocol) és un protocol de capa d'aplicació per a la comunicació fonamentalment de la World Wide Web. Encara que hui en dia el seu ús és més divers. S'ha convertit en un estàndard per a la comunicació entre el model i la vista en alguns projectes en moltes tecnologies actuals. El seus usos principals són:
- Pàgines web
- Publicació senzilla de fitxers per a descarregar.
- Comunicació entre client-servidor en aplicacions web, mòbils o altres. (XML, Json)
El protocol HTTP, si es combina amb una capa segura SSL, s'anomena HTTPS i permet una comunicació segura.
Un servidor http necessita:
- Connexió a Internet
- Espai en disc
- Suficient potència per servir simultàniament a molts usuaris en moments puntuals.
- Un servidor web/http generalment crea un procés nou per cada petició.
Conceptes
- URL: Uniform Resource Locator
HTTP
El protocol de transferència d’hipertext (HTTP, hyperText transfer pro-tocol) és el motor que dóna vida a Internet, ja que és la base per a la web (www,world wide web).
És en els inicis del protocol HTTP, a mitjans de l’any 1990, quan trobem la versió 0.9. Aquesta versió tenia com a única finalitat transferir dades per Internet en forma de pàgines web escrites en llenguatge de marcatge d’hipertext (HTML, Hyper Text Markup Language). A partir de la versió 1.0 del protocol va sorgir la possibilitat de transferir missatges amb encap- çalaments que descrivien el contingut dels missatges.
El protocol de transferència d’hipertext (HTTP) és un protocol client-ser- vidor força senzill que articula els intercanvis d’informació entre els clients web i els servidors HTTP. HTTP va ser desenvolupat pel consorci W3C i la IETF. Aquesta col·laboració va culminar l’any 1999 amb la publicació d’una sèrie de RFC, el més important dels quals va ser el RFC 2616, que especi- ficava la versió 1.1. Des del punt de vista de les comunicacions, està suportat en els serveis de connexió TCP/IP i funciona de la mateixa manera que la resta de serveis propis dels entorns UNIX.
Tècnicament, un procés servidor escolta en un port de comunicacions TCP (per defecte, el 80) i espera les sol·licituds de connexió dels clients web. Una vegada establerta la connexió, el protocol TCP s’encarrega de mantenir la comunicació i garantir un intercanvi de dades lliure d’errors.
El protocol de transferència d’hipertext es basa en operacions senzilles de sol·licitud/resposta. Quan un client estableix una connexió amb un servi- dor i envia un missatge amb les dades de la sol·licitud, el servidor respon amb un missatge similar, que conté l’estat de l’operació i el seu resultat possible. Totes les operacions poden adjuntar un objecte o recurs sobre el qual actuen; cada objecte web (document HTML, arxiu multimèdia o apli- cació CGI) és conegut pel seu localitzador uniforme de recursos (URL, uniform resource locator). Els recursos poden ser arxius, el resultat de l’execució d’un programa, una consulta a una base de dades, la traducció automàtica d’un document, etc.
HTTP és un protocol sense estat, és a dir, no guarda cap informació sobre connexions anteriors. El desenvolupament d’aplicacions web freqüent- ment necessita mantenir estat. Per això s’utilitzen les galetes ( cookies), és a dir, la informació que un servidor pot emmagatzemar en el sistema client. Això permet que les aplicacions web institueixin la noció de “ses- sió”, i, alhora, permet rastrejar usuaris, ja que les galetes es poden emma- gatzemar en el client durant un temps indeterminat
Versions
- 0.9: Transferir html
- 1.0: Transferir imatges i comunicació Client -> Servidor amb POST
- 1.1: Múltiples peticions per connexió i connexions persistents
- 2.0: (2015) Millores de rendiment i compresió. Sols funciona en https.
Etapes d'una comunicació en HTTP
- Un usuari accedeix a una adreça d’Internet (URL) seleccionant un enllaç d’un document HTML o introduint-la directament a la barra de navegació d’un navegador web des de la perspectiva del client web.
- El client web descodifica l’adreça d’Internet (URL) separant-ne les diferents parts. És així com s’identifiquen el protocol d’accés, l’adreça del servidor de noms de domini (DNS, Domain Name Server) o d’Internet (IP) del servidor, el possible port opcional (el valor per defecte és el 80) i l’objecte del servidor requerit.
- S’obre una connexió TCP/IP amb el servidor cridant el port TCP corresponent. Es fa la petició. En conseqüència, s’envien l’ordre necessària (GET, POST, HEAD, etc.), l’adreça de l’objecte requerit (el contingut de l’adreça d’Internet del servidor), la versió del protocol HTTP utilitzada (en la major part de les ocasions és HTTP/1.0) i un conjunt variable d’informació que inclou dades sobre les capacitats del navegador web, dades opcionals per al servidor, etc.
- El servidor retorna la resposta al client. Aquesta resposta consisteix en un codi d’estat i el tipus de dada amb extensions multipropòsit de correu d’Internet (MIME, Multipurpose Internet Mail Extension) de la informació de tornada, seguit de la mateixa informació.
- Es tanca la connexió TCP. Aquest procés es repeteix en cada accés que es faci al servidor HTTP. Per exemple, si es recull un document HTML que conté quatre imatges, el procés de transició mostrat amb anterioritat es repeteix cinc vegades, és a dir, una pel document HTML i quatre per les imatges.
Missatge de petició
El missatge de petició està format per:
- Línia de petició, com GET /images/logo.gif HTTP/1.1, que sol·licita un recurs anomenat /images/logo.gif al servidor
- Capçaleres, com ara Accept-Language: ca (En el cas de HTTP/1.1 cal dir el HOST)
- Una línia en blanc
- El cos del missatge (opcional)
Exemple:
GET / HTTP/1.1 host: web.simarro
La línia de petició i les capçaleres han d'acabar totes amb <CR><LF> (és a dir, Carriage Return (retorn de carro) seguit per un Line Feed). La línia en blanc només ha de ser <CR><LF>, sense cap espai. En el protocol HTTP/1.1 totes les capçaleres, excepte Host, són opcionals.
Una línia de petició que només contingui la ruta del fitxer és acceptada pels servidors per tal de mantenir la compatibilitat amb els clients HTTP anteriors a l'especificació HTTP/1.0 .
Missatge de resposta
El servidor retorna un missatge com aquest:
HTTP/1.1 200 OK Date: Wed, 28 Feb 2018 08:58:01 GMT Server: Apache/2.4.18 (Ubuntu) Last-Modified: Fri, 04 Nov 2016 06:56:32 GMT ETag: "2c39-540742c975b1d" Accept-Ranges: bytes Content-Length: 11321 Vary: Accept-Encoding Connection: close Content-Type: text/html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> ...
La primera línia indica que tot ha anat bé. Si va mal, podem trobar missatges d'error com el 404, 403, 500... Podem saber què siginifquem mirant l'estandard RFC 2616 sec 6 https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html
Mètodes de petició
Mètodes segons l'especificació RFC 2616 que correspon a HTTP/1.1 .
L'HTTP defineix vuit maneres (a vegades anomenats "verbs") d'indicar l'acció destijada que s'ha de dur a terme sobre el recurs. El que el recurs representa depèn de la implementació de cada servidor. Normalment però, aquest recurs és el contingut d'un fitxer, o la sortida d'un executable resident al servidor.
- HEAD
- Sol·licita una resposta, idèntica a la que es generaria amb una consulta GET, però sense el cos de la resposta. Aquesta comanda és útil per aconseguir les meta-dades incloses en la capçalera de la resposta, sense haver-se d'enviar tot el contingut.
- GET
- Sol·licita una representació del recurs especificat. Noti's que GET no s'ha d'usar per operacions que tinguin efectes col·laterals, com ara accions sobre aplicacions web. La raó és que el GET escriu les dades en la URI. Exemple: /index.php?page=main&lang=es
- POST
- Envia dades per a ser processades (p. ex, en un formulari HTML) a un recurs específic. Les dades s'inclouen en el cos de la petició. Això pot implicar la creació d'un nou recurs o l'actualització d'aquest si ja existeix (o ambdós).
- PUT
- Apuja una representació del recurs especificat. Els hostings compartits no solen tindre habilitat PUT. Però en teoría és millor que POST per a penjar alguna cosa, ja que es crea un socket en el servidor i la càrrega és més directa.
- DELETE
- Esborra el recurs especificat.
- TRACE
- Retorna la consulta rebuda, perquè el client pugui veure quines coses estan afegint o canviant els servidors intermitjos.
- OPTIONS
- Retorna els mètodes HTTP que el servidor suporta per a una URL determinada. Es pot fer servir per esbrinar la funcionalitat del servidor web enlloc d'un recurs específic.
- CONNECT
- Converteix la connexió de petició en un túnel TCP/IP transparent, normalment per facilitar comunicacions xifrades amb SSL (HTTPS) a través d'un proxy HTTP no xifrat.
Els servidors han d'implementar com a mínim els mètodes GET i HEAD HTTP 1.1 Section 5.1.1 i, quan sigui possible, també el mètode OPTIONS.
Apache
El servidor Apache és un dels més recomanats per a utilitzar en qualsevol projecte de web. És flexible, ràpid i eficient, amés:
- Multiplataforma
- Estàndard
- Modular: Sols cal activar el mòduls necessaris i disposa d'una API per programar els mòduls que necessitem.
- Obert i lliure.
- Extensible
Configuració
Nosaltres anem a centrar-nos en la versió 2.4 de Apache i la documentació és aquesta: [1]
Apache ha anat desplaçant coses del seu fitxer principal de configuració apache2.conf a altres fitxes i directoris. Aquests són els que anem a estudiar:
- apache2.conf : Fitxer principal, delega configuracions a altres fitxers.
- ports.conf: Fitxer per indicar els ports per els que escolta el servidor.
- magic: Contè la base de dades de tipus de fitxers que pot enviar.
- conf-avaliable: Directori amb fitxers de configuració que estan disponibles.
- conf-enabled: Directori amb enllaços a conf-available per activar configuracions.
- mods-available, mods-enabled: Mòduls disponibles i activats.
- sites-available, sites-enables: Llocs web disponibles i activats.
Apache pot ser configurat seguint estratègies diverses. Per tant, podem trobar solucions molt diferents a la mateixa necessitat. Per començar a entendre cóm funciona, anem a distingir entre varis tipus de configuracions:
Configuració Global
És la que afecta al servidor com a tal. Són moltes les opcions entre les que podem destacar:
- ServerRoot: Lloc on estan els fitxers de configuració
- TimeOut: Temps d’espera màxim en enviar o rebre informació del client.
- KeepAlive: on/off (http 1.0/1.1)
- Listen: Adreça i port on escoltar les peticions.
- User ${APACHE_RUN_USER}
- Group ${APACHE_RUN_GROUP}: Usuari i grup d’execució del servidor.
Configuració General
És la que afecta als llocs web que dona el servidor. Aquestes configuracions es poden aplicar en virtualhosts concrets o per a tots:
- ServerAdmin: Correu de l’administrador
- ServerName: Nom DNS i port del servidor http.
- ServerAlias: Noms alternatius
- DocumentRoot: Ruta dels arxius que publica el servidor.
- DirectoryIndex: Document que actua cóm a pàgina per defecte del directori on estan els arxius.
- Alias: Indica una ruta de la URL cap a un directori del servidor.
- AccessFileName .htaccess: Indica el nom del fitxer que controla la seguretat d’un directori.
- AllowOverride: Indica si un directori pot tindre opcions de seguretat que modifiquen les globals. Aquestes són les opcions:
- 'All: Permet sobreescriure totes les directives.
- None: No permet cap directiva
- AuthConfig: Permet especificar directives d'autenticació dels usuaris.
- FileInfo: Permet controlar els tipus de documents.
- Indexes: Permet especificar l'indexat dels directoris.
- Limit: Permet directives que controlen l'accés per la IP del client.
- Options: Permet sobreescriure directives que controlens opcions dels directoris.
Control d'accés per directori
Per a controlar l'accés a un directori, es pot utilitzar els fitxers .htaccess amb una sintaxi similar a:
AuthType Basic AuthName "Acces Restringit" AuthUserFile /var/www/users AuthGroupFile /var/www/groups Require group grup1 grup2
Per suposat, els fitxers anteriors han d'existir. Per donar contrasenya a un usuari podem utilitzar el comandament:
htpasswd -c /var/www/users pepe
Un altre exemple amb usuaris:
AuthType Basic AuthName "Acces Restringit" AuthUserFile /var/www/html/solar/secret/users/users Require user pepe
Per a que funcione, cal declarar que es pot sobreescriure els permisos per .htaccess:
<Directory /privat/> Options Indexes FollowSymLinks AllowOverride AuthConfig Require all granted </Directory>
.htaccess sols s'ha d'utilitzar quan no podem accedir a la configuració general del servidor. En qualsevol altre cas, és preferible controlar la seguretat des del fitxer de configuració del virtualhost o del servidor. Aquest sistema és ineficient i potencialment insegur. Per tant, tot el que pots posar en .htaccess pot ser que estiga millor dins d'un <directory>.
Servidors Virtuals
Apache permet oferir diferents webs en funció de cóm es demanen. Cada web diferent es diu un VirtualHost. Inclús el host real s’ha de fer com un host virtual. Si no hi ha coincidència va al lloc per defecte.
Es configuren bàsicament en 3 directives que detallarem més endavant:
- <VirtualHost>: Etiqueta per clavar dins totes les opcions pròpies del servidor virtual.
- ServerName: El nom del servidor per el que donarà resposta.
- ServerAlias: Cadascun dels noms DNS alternatius que dona el mateix servidor virtual.
De vegades és complicat saber quants servidors virtuals tenim i cóm se comporten sense llegir tots els fitxers de configuració. Però hi ha un comandament que ens mostra cóm es comportarà el nostre servidor:
apachectl -S
Servidors virtuals basats en la IP
Si volem que la mateixa màquina en el mateix Apache done pàgines web distintes, una de les opcions és donar més direccions IP a l'ordinador i configurar servidors virtuals en funció de la IP.
Això es pot fer augmentant les NIC, amb adreces virtuals o les NIC virtuals si estem dins d'una màquina virtual o contenidor. Després fem que el DNS apunte cada URL a una IP distinta i ja està.
Ací tenim un exemple d'un sol servidor Apache amb 2 IPs:
<VirtualHost 172.20.30.40:80> ServerAdmin webmaster@www1.example.com DocumentRoot "/www/vhosts/www1" ServerName www1.example.com ErrorLog "/www/logs/www1/error_log" CustomLog "/www/logs/www1/access_log" combined </VirtualHost> <VirtualHost 172.20.30.50:80> ServerAdmin webmaster@www2.example.org DocumentRoot "/www/vhosts/www2" ServerName www2.example.org ErrorLog "/www/logs/www2/error_log" CustomLog "/www/logs/www2/access_log" combined </VirtualHost>
Servidors virtuals basats en el nom
Si sols tenim una IP i volem donar diferents web, podem basar els servidors virtuals en els noms DNS.
<VirtualHost *:80> # El primer virtualhost és també el per defecte quan entren per *:80 ServerName www.example.com ServerAlias example.com *.example.com DocumentRoot "/www/domain" </VirtualHost> <VirtualHost *:80> ServerName other.example.com DocumentRoot "/www/otherdomain" </VirtualHost>
Amb açò es poden fer moltes combinacions, recomane llegir en deteniment els exemples oficials
<Directory>
- Permet configurar valors de seguretat i altres per a directoris en concret.
- Es necessita un per a cada directori diferent que publique el servidor. No és precís per als subdirectoris.
<Directory /usr/local/httpd/htdocs> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory>
En aquest cas, permet mostrar els fitxers del directori i utilitzar enllaços simbòlics del sistema d'arxius. No permet sobreescriure res en .htaccess i amb Require deixa entrar a tots.
Require té moltes possibilitat per controlar l'accés. Recomanem llegir el manual oficial per torbar la més adequada.
<Files>
De forma pareguda als directoris, es poden fer limitacions en els fitxers. Per exemple:
<Files admin.php> deny from all </Files> <Files ~ "\.(gif|jpe?g|png)$">
HTTPS en Apache
HTTPS no sols implica qüestions tècniques, sinó també administratives, ja que per a fer-ho ben fet, necessitem una entitat certificadora per a signar les nostres claus.
Per a fer-ho bé, necessitem:
- Contractar un certificat SSL
- Instal·lar el certificat en el servidor.
- Configurar el mòdul SSL d’Apache i activar-lo.
- Configurar el lloc que s’accedirà per SSL i activar-lo.
Com que el SSL no sempre està al nostre abast, Apache pot aprofitar un certificat auto-signat que fa durant la seua instal·lació. Per tant, si volem que funcione sense signar el certificat sols tenim que:
- Activar el mòdul: a2enmod ssl
- Activar el lloc ssl per defecte: a2ensite default-ssl
Una vegada fer això, editem el fitxer default-ssl.conf per a que funcione en els nostres noms, directoris o controls d'accessos i ja està.
Si volem que quan entren per http (al port 80) els redireccione al https, posem al virtualhost:
Redirect / https://www.client2.com
Directoris personals
Si volem que els usuaris del sistema puguen tindre una web personal, podem activar els userdir:
a2enmod userdir
Després, modificar el fitxer mods-enabled/userdir.conf per modificar la ruta del directori personal. [2]
Proves en curl
Per provar, de vegades és interessant i més ràpid utilitzar curl més que un navegador web. Així podem controlar tota la petició:
Curl sense passar per el DNS:
curl -H 'host:www.terra.solar.com' 10.1.3.200 curl -H 'host:<url>' <ip>
Curl per https ignorant el problema del certificat:
Per a https: curl -k https://<ip>
Per a permitir redireccions:
curl -L …
Per a indicar un usuari i contrasenya:
curl -u <usuari> <url>
Enllaços
- https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-debian-8
- http://acacha.org/mediawiki/HTTP#.WpQuUEsulp8