8. General Request and Response Handling (Gestione generale delle richieste e delle risposte)

8.1 Precedence in Error Handling (Precedenza nella gestione degli errori)

I server DEVONO restituire errori di autorizzazione in preferenza ad altri errori. Questo evita di divulgare informazioni sulle risorse protette (ad esempio, un client che scopre che una risorsa nascosta esiste vedendo una risposta 423 Locked a una richiesta anonima alla risorsa).

8.2 Use of XML (Uso di XML)

In HTTP/1.1, le informazioni sui parametri del metodo erano codificate esclusivamente nelle intestazioni HTTP. A differenza di HTTP/1.1, WebDAV codifica le informazioni sui parametri del metodo sia in un corpo entità di richiesta XML ([REC-XML]), sia in un'intestazione HTTP. L'uso di XML per codificare i parametri del metodo è stato motivato dalla capacità di aggiungere elementi XML extra alle strutture esistenti, fornendo estensibilità; e dalla capacità di XML di codificare informazioni in set di caratteri ISO 10646, fornendo supporto per l'internazionalizzazione.

Oltre a codificare i parametri del metodo, XML è usato in WebDAV per codificare le risposte dai metodi, fornendo i vantaggi di estensibilità e internazionalizzazione di XML per l'output del metodo, così come per l'input.

Quando XML è usato per un corpo di richiesta o risposta, il tipo Content-Type DOVREBBE essere application/xml. Le implementazioni DEVONO accettare sia text/xml che application/xml nei corpi di richiesta e risposta. L'uso di text/xml è deprecato.

Tutti i client e le risorse conformi a DAV DEVONO usare parser XML conformi a [REC-XML] e [REC-XML-NAMES]. Tutto l'XML usato nelle richieste o nelle risposte DEVE essere, come minimo, ben formato e usare correttamente i namespace. Se un server riceve XML che non è ben formato, allora il server DEVE rifiutare l'intera richiesta con un 400 (Bad Request). Se un client riceve XML che non è ben formato in una risposta, allora il client NON DEVE assumere nulla sul risultato del metodo eseguito e DOVREBBE trattare il server come malfunzionante.

Si noti che l'elaborazione di XML inviato da una fonte non affidabile può causare rischi connessi alla privacy, alla sicurezza e alla qualità del servizio (vedere Sezione 20). I server POSSONO rifiutare richieste discutibili (anche se consistono in XML ben formato), ad esempio, con un codice di stato 400 (Bad Request) e un corpo di risposta opzionale che spiega il problema.

8.3 URL Handling (Gestione degli URL)

Gli URL appaiono in molti punti nelle richieste e nelle risposte. L'esperienza di interoperabilità con [RFC2518] ha mostrato che molti client che analizzano risposte Multi-Status non hanno implementato completamente la Risoluzione di Riferimento completa definita nella Sezione 5 di [RFC3986]. Pertanto, i server in particolare devono essere attenti nella gestione degli URL nelle risposte, per garantire che i client abbiano abbastanza contesto per poter interpretare tutti gli URL. Le regole in questa sezione si applicano non solo agli URL di risorse nell'elemento 'href' nelle risposte Multi-Status, ma anche agli URL di risorse delle intestazioni Destination e If.

Il mittente ha una scelta tra due approcci: usare un riferimento relativo, che viene risolto rispetto al Request-URI, o un URI completo. Un server DEVE garantire che ogni valore 'href' all'interno di una risposta Multi-Status usi lo stesso formato.

WebDAV usa solo una forma di riferimento relativo nelle sue estensioni, il percorso assoluto.

Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )

Le produzioni absolute-URI, path-absolute e query sono definite nelle Sezioni 4.3, 3.3 e 3.4 di [RFC3986].

All'interno delle produzioni Simple-ref, i mittenti NON DEVONO:

usare segmenti punto ("." o ".."), o
avere prefissi che non corrispondono al Request-URI (usando le regole di confronto definite nella Sezione 3.2.3 di [RFC2616]).

Gli identificatori per le collezioni DOVREBBERO terminare con un carattere '/'.

8.3.1 Esempio - Gestione corretta degli URL

Consideriamo la collezione http://example.com/sample/ con l'URL membro interno http://example.com/sample/a%20test e la richiesta PROPFIND sottostante:

Richiesta:

PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1

In questo caso, il server dovrebbe restituire due elementi 'href' contenenti

http://example.com/sample/ e http://example.com/sample/a%20test, oppure
/sample/ e /sample/a%20test

Si noti che anche se il server può archiviare la risorsa membro internamente come 'a test', deve essere codificata in percentuale quando usata all'interno di un riferimento URI (vedere Sezione 2.1 di [RFC3986]). Si noti anche che un URI legale può ancora contenere caratteri che devono essere escaped all'interno dei dati di carattere XML, come il carattere ampersand.

8.4 Required Bodies in Requests (Corpi richiesti nelle richieste)

Alcuni di questi nuovi metodi non definiscono corpi. I server DEVONO esaminare tutte le richieste per un corpo, anche quando un corpo non era previsto. Nei casi in cui un corpo di richiesta è presente ma verrebbe ignorato da un server, il server DEVE rifiutare la richiesta con 415 (Unsupported Media Type). Questo informa il client (che potrebbe aver tentato di usare un'estensione) che il corpo non ha potuto essere elaborato come il client intendeva.

8.5 HTTP Headers for Use in WebDAV (Intestazioni HTTP da usare in WebDAV)

HTTP definisce molte intestazioni che possono essere usate nelle richieste e risposte WebDAV. Non tutte sono appropriate in tutte le situazioni e alcune interazioni possono essere indefinite. Si noti che HTTP 1.1 richiede l'intestazione Date in tutte le risposte se possibile (vedere Sezione 14.18, [RFC2616]).

Il server DEVE eseguire controlli di autorizzazione prima di controllare qualsiasi intestazione condizionale HTTP.

8.6 ETag

HTTP 1.1 raccomanda l'uso di ETag piuttosto che date di modifica, per il controllo della cache, e ci sono ragioni ancora più forti per preferire gli ETag per l'authoring. L'uso corretto degli ETag è ancora più importante in un ambiente di authoring distribuito, perché gli ETag sono necessari insieme ai lock per evitare il problema dell'aggiornamento perso. Un client potrebbe non riuscire a rinnovare un lock, ad esempio, quando il lock scade e il client è accidentalmente offline o nel mezzo di un lungo caricamento. Quando un client non riesce a rinnovare il lock, è abbastanza possibile che la risorsa possa ancora essere ribloccata e l'utente possa continuare a modificare, finché non sono state apportate modifiche nel frattempo. Gli ETag sono necessari perché il client possa distinguere questo caso. Altrimenti, il client è costretto a chiedere all'utente se sovrascrivere la risorsa sul server senza nemmeno poter dire all'utente se è cambiata. I timestamp non risolvono questo problema quasi altrettanto bene degli ETag.

Gli ETag forti sono molto più utili per i casi d'uso di authoring rispetto agli ETag deboli (vedere Sezione 13.3.3 di [RFC2616]). L'equivalenza semantica può essere un concetto utile ma ciò dipende dal tipo di documento e dal tipo di applicazione, e l'interoperabilità potrebbe richiedere un accordo o uno standard al di fuori dell'ambito di questa specifica e HTTP. Si noti anche che gli ETag deboli hanno certe restrizioni in HTTP, ad esempio, questi non possono essere usati nelle intestazioni If-Match.

Si noti che il significato di un ETag in una risposta PUT non è chiaramente definito né in questo documento né in RFC 2616 (cioè, se l'ETag significa che la risorsa è equivalente byte per byte al corpo della richiesta PUT, o se il server avrebbe potuto apportare modifiche minori nella formattazione o nel contenuto del documento durante l'archiviazione). Questo è un problema HTTP, non puramente un problema WebDAV.

Poiché i client potrebbero essere costretti a chiedere agli utenti o a scartare contenuto modificato se l'ETag cambia, un server WebDAV NON DOVREBBE cambiare l'ETag (o il tempo Last-Modified) per una risorsa che ha un corpo e una posizione invariati. L'ETag rappresenta lo stato del corpo o dei contenuti della risorsa. Non c'è un modo simile per dire se le proprietà sono cambiate.

8.7 Including Error Response Bodies (Inclusione di corpi di risposta di errore)

HTTP e WebDAV non usavano i corpi della maggior parte delle risposte di errore per informazioni analizzabili dalla macchina fino a quando la specifica per le Estensioni di Versionamento a WebDAV ha introdotto un meccanismo per includere informazioni più specifiche nel corpo di una risposta di errore (Sezione 1.6 di [RFC3253]). Il meccanismo del corpo di errore è appropriato da usare con qualsiasi risposta di errore che può prendere un corpo ma non ha già un corpo definito. Il meccanismo è particolarmente appropriato quando un codice di stato può significare molte cose (ad esempio, 400 Bad Request può significare che mancano intestazioni richieste, le intestazioni sono formattate in modo errato, e molto altro). Questo meccanismo del corpo di errore è coperto nella Sezione 16.

8.8 Impact of Namespace Operations on Cache Validators (Impatto delle operazioni di namespace sui validatori di cache)

Si noti che le intestazioni di risposta HTTP "Etag" e "Last-Modified" (vedere [RFC2616], Sezioni 14.19 e 14.29) sono definite per URL (non per risorsa), e sono usate dai client per il caching. Pertanto i server devono garantire che l'esecuzione di qualsiasi operazione che influisce sul namespace URL (come COPY, MOVE, DELETE, PUT o MKCOL) preservi la loro semantica, in particolare:

Per qualsiasi URL dato, il valore "Last-Modified" DEVE incrementare ogni volta che la rappresentazione restituita su GET cambia (entro i limiti della risoluzione del timestamp).
Per qualsiasi URL dato, un valore "ETag" NON DEVE essere riutilizzato per rappresentazioni diverse restituite da GET.

In pratica questo significa che i server

potrebbero dover incrementare i timestamp "Last-Modified" per ogni risorsa all'interno del namespace di destinazione di un'operazione di namespace a meno che non possano farlo in modo più selettivo, e
analogamente, potrebbero dover riassegnare i valori "ETag" per queste risorse (a meno che il server non allochi tag di entità in modo tale che siano univoci nell'intero namespace URL gestito dal server).

Si noti che queste considerazioni si applicano anche a casi d'uso specifici, come l'uso di PUT per creare una nuova risorsa a un URL che è stato mappato prima, ma è stato cancellato da allora.