Pillole protocols: WebDAV

Spread the love

Il web come lo conosciamo oggi è un mezzo per lo più in sola lettura.

È vero che con il Web 2.0 anche gli utenti contribuiscono ai contenuti web, ma ciò avviene in modo molto diverso e molto più sofisticato rispetto a quanto immaginato inizialmente da Tim Berners-Lee.

Il suo browser WWW infatti agiva sui server web in lettura e scrittura: si poteva leggere una pagina web ma si poteva anche modificarla.

Come si “scrive” sul web ai tempi del Web 2.0

Quello che accade attualmente con il Web 2.0, ad esempio quando aggiungiamo un commento ad un articolo di un blog WordPress, è qualcosa di più complicato, ossia la scrittura in un database e non nel filesystem del server che eroga le pagine Web.

Tecnicamente quando invochiamo la funzionalità di aggiunta di un commento, invochiamo un comando di lettura di una risorsa web (comando HTTP POST) che si chiama wp-comments-post.php passando dei parametri:

POST /wp-comments-post.php HTTP/1.1 
Host: www.betaingegneria.it 
Connection: keep-alive 
Content-Length: 184 
...

comment=questo %22 il mio commento&author=My+Name&email=my.mail%40gmail.com&url=&submit=Submit+Comment&comment_post_ID=2734&comment_parent=0&akismet_comment_nonce=afb00fa731&ak_js=1535630177692

Qui, disgraziatamente, la parola post è utilizzata con due significati diversi:

  • POST come comando HTTP (nel senso di INVIA)
  • POST come articolo del blog

In questa operazione di scrittura del commento, il browser chiede (in lettura!) al server di caricare il programma wp-comments-post.php. Questa richiesta è inviata al server quando nella pagina del post clicchiamo sul link “Submit Comment” (o “Invia Commento” o qualcos’altro), assieme alla mail e il valore corrispondente alla scelta I’m not a ROBOT. Con il comando POST i parametri vengono inviati dopo il termine dell’intestazione HTTP e un doppio a capo (come illustrato sopra). Se utilizzassimo il comando di HTTP GET i parametri sarebbero contenuti nell’URL, separando il nome della risorsa dai parametri con un “?”:

GET /wp-comments-post.php?comment=questo %22 il mio commento&author=My+Name&email=my.mail%40gmail.com&url=&submit=Submit+Comment&comment_post_ID=2734&comment_parent=0&akismet_comment_nonce=afb00fa731&ak_js=1535630177692 HTTP/1.1 

Al di là di questa differenza tra GET e POST è importante capire bene qui che la risorsa (nome tecnico della “pagina” PHP)  wp-comments-post.php, non viene alterata, viene soltanto letta!

Quello che succede a questo punto è che il server web Apache non serve direttamente la pagina PHP al browser, anzi passa il controllo all’application server (il PHP nel caso di WordPress) il quale legge ed esegue il programma PHP wp-comments-post.php. All’interno di questo programma ci sono le istruzioni che salvano il nostro commento (“questo è il mio commento”) in un database. Il tutto è illustrato nella figura 1.

Successivamente, se tutto va bene, (in modo automatico) il server risponderà al browser inoltrandogli una sola intestazione (quindi non una pagina web) contenente soltanto un comando di redirect, ovvero una ingiunzione al browser di effettuare un’altra richiesta al web server perché gli serva il post che ora conterrà anche il nostro commento (vedi fig. 2).

Qui ci si soffermi a capire bene: è sempre il browser che inizia la richiesta di un contenuto. Egli agisce sempre come un cliente.

Tutto questo giro è perché la pagina HTML (il post contenente il commento) che viene consegnata dal web server al browser in realtà è il frutto di elaborazione del server applicativo PHP che legge il contenuto dell’articolo (anch’esso contenuto nel database) e gli eventuali commenti e compila un’unica pagina HTML che consegnerà ad Apache il quale la spedirà al nostro browser.

Possiamo immaginare il web server Apache, in questa architettura, semplicemente come un passa-mano:

  • in andata (REQUEST) riceve i parametri dal browser e li passa al server PHP
  • al ritorno (RESPONSE) riceve dal programma PHP il flusso HTML e la passa al nostro browser

Quindi sostanzialmente stiamo sempre facendo operazioni di lettura nel file system; le scritture vengono fatte su un DBMS.

Leggere e scrivere fisicamente sul Web

Ciò che aveva in mente Tim Berners-Lee, e che realizzò con il suo browser WWW, era una cosa profondamente diversa: le stesse risorse web dovevano essere modificabili. Quindi gli stessi file HTML contenuti nel web server! Ma questo ha un senso per un web statico in cui le pagine vengono servite al browser così come esistono nel web server. Nel cosiddetto “web dinamico” che esiste fin dalla comparsa degli script cgi-bin (quindi primi anni ’90, quando il web andava all’asilo) ciò non è più vero: non esistono pagine da servire così come sono, esistono solo programmi che producono pagine al volo sulla base dei dati di ingresso.

Quindi non ha nemmeno tanto senso il pensare di modificare le pagine, anzi: è da evitare nel modo più assoluto.

Questo approccio ha un senso quando si vuole utilizzare una infrastruttura web per pubblicare documenti statici che, tuttavia, hanno un loro ciclo di vita, possono cioè cambiare nel tempo ma in seguito ad azione di editing, di modifica da parte di uno o più utenti che sono quindi editori, gestori del contenuto di quella pagina. In quest’ottica si colloca il protocollo WebDAV che è una estensione di HTTP per questo tipo di attività.

Dunque il protocollo WebDAV realizza quanto aveva in mente Tim Berners-Lee. Ma generalmente si utilizza nelle intranet e spesso non si fa nemmeno utilizzo del browser per accedere ai contenuti, ma si impiega piuttosto un programma del tipo Finder o Esplora Risorse. La gestione dei documenti va oltre ai soli documenti HTML ma può trattarsi anche di file di testo elettronico come Word (MS Office) o Writer (LibreOffice) o PDF. La loro modifica è operata Offline, ossia modifico il documento in locale e poi lo deposito nel server andando ad alimentare la storia del documento con una nuova versione.

Il protocollo WebDAV è descritto nella RFC 4918 “HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)” ed è, al pari di tutti gli altri protocolli, essenzialmente un insieme di comandi. Con questi comandi possiamo non solo trasferire i file  da client a server, ma anche

  • creare directory (MKCOL)
  • copiare e spostare file (COPY / MOVE)
  • aggiungere, modificare e rimuovere proprietà (metadati) del file (PROPFIND, PROPPATCH)
  • bloccare e sbloccare (LOCK/UNLOCK) una risorsa quando si deve operare una modifica (condizione per una gestione transazionale della vita del documento – in altre parole evitiamo che più utenti mettano mano simultaneamente al documento)
  • cercare file (SEARCH)

Per allestire un server WebDAV occorre installare nel file server, prima di tutto, un server Web, ad esempio Apache. Poi occorre aggiungere il modulo DAV (mod_dav). Poiché i metodi di acesso DAV consentono ai client remoti di manipolare i file sul server, è necessario avere particolare cura per assicurare che il vostro server sia sicuro, prima di abiltare mod_dav.

Ogni cartella del server dove DAV è abilitato deve essere protetta da autenticazione. L’uso della HTTP Basic Authentication non è consigliata. Occorre usare almeno la HTTP Digest Authentication, che è fornita dal modulo di Apache mod_auth_digest. Quasi tutti i client WebDAV supportano questo metodo di autenticazione.

Una alternativa è la Basic Authentication sopra una connessione SSL/TLS.

Per consentire al modulo mod_dav la gestione dei file, lo User e il Group proprietari del processo UNIX che esegue Apache (nel sistema operativo Ubuntu è l’utente www-data) devono essere abilitati alla scrittura delle directory e file al disotto di queste.  I nuovi file creati apparterranno all’utente User:Group. Per tale ragione è importante controllare l’accesso di questo account. Il repository DAV è considerato privato di Apache. Pertanto, la modifica di file al di fuori di Apache (ad esempio tramite FTP o comandi del sistema operativo) non dovrebbe essere permessa.

Lascia un commento

Your email address will not be published.

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.