Passa al contenuto principale

RFC 4918 - Estensioni HTTP: Creazione e Gestione Versioni Distribuite sul Web (WebDAV)

  • Stato: Proposed Standard
  • Pubblicato: June 2007
  • Stream: IETF
  • Sostituisce: RFC2518
  • Errata: Nessun errata

Sommario (Abstract)​

Web Distributed Authoring and Versioning (WebDAV) è composto da un insieme di metodi, intestazioni e tipi di contenuto accessori a HTTP/1.1 per la gestione delle proprietà delle risorse (Resource Properties), la creazione e gestione di raccolte di risorse (Resource Collections), la manipolazione dello spazio dei nomi degli URL (URL Namespace Manipulation) e il blocco delle risorse (Resource Locking, per evitare conflitti).

RFC 2518 è stato pubblicato nel febbraio 1999. Questa specifica rende obsoleto RFC 2518 con revisioni minori basate sull'esperienza di interoperabilità.

Stato di questo Memorandum (Status of This Memo)​

Questo documento specifica un protocollo Standards Track per la comunità Internet e richiede discussioni e suggerimenti per miglioramenti. Si prega di fare riferimento all'edizione corrente degli "Internet Official Protocol Standards" (STD 1) per lo stato di standardizzazione e lo status di questo protocollo. La distribuzione di questo memorandum è illimitata.

Copyright (C) The IETF Trust (2007).

Indice (Contents)​

Sezioni Principali​

Appendici (Appendices)​

Concetti Fondamentali di WebDAV​

Funzionalità Principali​

WebDAV estende il protocollo HTTP/1.1 con le seguenti capacità fondamentali:

  1. Proprietà (Properties): Aggiungere, modificare e interrogare i metadati delle risorse Web
  2. Raccolte (Collections): Creare e gestire strutture gerarchiche di risorse
  3. Blocco (Locking): Prevenire conflitti di modifica concorrente, supportando blocchi esclusivi e condivisi
  4. Operazioni di Spazio dei Nomi (Namespace Operations): Copiare e spostare risorse Web

Nuovi Metodi HTTP​

  • PROPFIND: Recuperare le proprietà di una risorsa
  • PROPPATCH: Modificare le proprietà di una risorsa
  • MKCOL: Creare una raccolta (simile alla creazione di una directory)
  • COPY: Copiare una risorsa o una raccolta
  • MOVE: Spostare o rinominare una risorsa o una raccolta
  • LOCK: Bloccare una risorsa per prevenire conflitti
  • UNLOCK: Sbloccare una risorsa

Nuovi Codici di Stato HTTP​

  • 207 Multi-Status: Risposta multi-stato per operazioni batch
  • 422 Unprocessable Entity: La richiesta era ben formata ma conteneva errori semantici
  • 423 Locked: La risorsa è bloccata
  • 424 Failed Dependency: La richiesta è fallita a causa del fallimento di una richiesta precedente
  • 507 Insufficient Storage: Spazio di archiviazione insufficiente per completare la richiesta

Casi d'Uso​

  • Modifica Collaborativa: Più utenti modificano simultaneamente contenuti Web
  • Sistemi di Gestione dei Contenuti (CMS): Gestione remota dei contenuti di siti Web
  • Condivisione File: Caricamento e download di file tramite protocollo HTTP
  • Archiviazione Cloud: Implementazione di servizi di archiviazione file basati su HTTP

1. Introduzione (Introduction)​

Questo documento descrive un'estensione del protocollo HTTP/1.1 che consente ai client di eseguire operazioni di authoring di contenuti Web remoti. Questa estensione fornisce un insieme coerente di metodi, intestazioni, formati del corpo dell'entità di richiesta e formati del corpo dell'entità di risposta che forniscono operazioni per:

Proprietà (Properties): La capacità di creare, rimuovere e interrogare informazioni sulle pagine Web, come i loro autori, date di creazione, ecc.

Raccolte (Collections): La capacità di creare insiemi di documenti e di recuperare un elenco di appartenenza gerarchico (come un elenco di directory in un file system).

Blocco (Locking): La capacità di impedire a più persone di lavorare contemporaneamente su un documento. Questo previene il "problema dell'aggiornamento perso (Lost Update Problem)", in cui le modifiche vengono perse quando prima un autore, poi un altro, scrive modifiche senza fondere le modifiche dell'altro autore.

Operazioni di spazio dei nomi (Namespace Operations): La capacità di istruire il server a copiare e spostare risorse Web, operazioni che modificano la mappatura dagli URL alle risorse.

I requisiti e la motivazione per queste operazioni sono descritti in un documento complementare, "Requisiti per un protocollo di authoring e versionamento distribuito per il World Wide Web (Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web)" [RFC2291].

Questo documento non specifica le operazioni di versionamento suggerite da [RFC2291]. Quel lavoro è stato fatto in un documento separato, "Estensioni di versionamento per WebDAV (Versioning Extensions to WebDAV)" [RFC3253].

Le sezioni seguenti forniscono un'introduzione dettagliata alle varie astrazioni di WebDAV: proprietà delle risorse (Resource Properties, Sezione 4), raccolte di risorse (Collections of Resources, Sezione 5), blocchi (Locks, Sezione 6) in generale, e blocchi di scrittura (Write Locks, Sezione 7) in particolare.

Queste astrazioni sono manipolate dai metodi HTTP specifici di WebDAV (Sezione 9) e dalle intestazioni HTTP aggiuntive (Sezione 10) utilizzate con i metodi WebDAV. Le considerazioni generali per la gestione delle richieste e risposte HTTP in WebDAV si trovano nella Sezione 8.

Sebbene i codici di stato forniti da HTTP/1.1 siano sufficienti per descrivere la maggior parte delle condizioni di errore incontrate dai metodi WebDAV, ci sono alcuni errori che non rientrano perfettamente nelle categorie esistenti. Questa specifica definisce codici di stato aggiuntivi sviluppati per i metodi WebDAV (Sezione 11) e descrive i codici di stato HTTP esistenti (Sezione 12) come utilizzati in WebDAV. Poiché alcuni metodi WebDAV possono operare su molte risorse, la risposta multi-stato (Multi-Status Response, Sezione 13) è stata introdotta per restituire informazioni di stato per più risorse. Infine, questa versione di WebDAV introduce elementi XML di precondizione e postcondizione (Precondition/Postcondition, Sezione 16) nei corpi di risposta di errore.

WebDAV utilizza XML ([REC-XML]) per i nomi delle proprietà e alcuni valori, e utilizza anche XML per effettuare il marshalling di richieste e risposte complesse. Questa specifica contiene definizioni DTD e testuali di tutte le proprietà (Sezione 15) e di tutti gli altri elementi XML (Sezione 14) utilizzati nel marshalling. WebDAV include alcune regole speciali sull'estensione del marshalling XML di WebDAV in modi retrocompatibili (Sezione 17).

A completamento della specifica ci sono sezioni su cosa significa per una risorsa essere conforme a questa specifica (Sezione 18), sul supporto dell'internazionalizzazione (Sezione 19) e sulla sicurezza (Sezione 20).

2. Notational Conventions (Convenzioni di Notazione)​

Poiché questo documento descrive un insieme di estensioni del protocollo HTTP/1.1, il BNF aumentato (Augmented BNF) utilizzato qui per descrivere gli elementi del protocollo è esattamente lo stesso descritto nella Sezione 2.1 di [RFC2616], incluse le regole sugli spazi bianchi lineari impliciti (Implied Linear Whitespace). Poiché questo BNF aumentato utilizza le regole di produzione di base fornite nella Sezione 2.2 di [RFC2616], queste regole si applicano anche a questo documento. Si noti che questa non è la sintassi BNF standard utilizzata in altri RFC.

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].

Corrispondenza italiana:

  • MUST (deve): requisito assoluto
  • MUST NOT (non deve): divieto assoluto
  • REQUIRED (richiesto): requisito assoluto
  • SHALL (deve): requisito obbligatorio
  • SHALL NOT (non deve): divieto obbligatorio
  • SHOULD (dovrebbe): fortemente raccomandato ma non obbligatorio
  • SHOULD NOT (non dovrebbe): fortemente sconsigliato ma non vietato
  • RECOMMENDED (raccomandato): pratica raccomandata
  • MAY (può): consentito ma opzionale
  • OPTIONAL (opzionale): completamente opzionale

Si noti che nel linguaggio naturale, una proprietà come la proprietà "creationdate" nello spazio dei nomi XML "DAV:" è talvolta chiamata "DAV:creationdate" per brevità.

3. Terminology (Terminologia)​

Questa sezione definisce i termini chiave utilizzati nella specifica WebDAV.

URI/URL​

URI (Uniform Resource Identifier, Identificatore Uniforme di Risorsa) e URL (Uniform Resource Locator, Localizzatore Uniforme di Risorsa), rispettivamente. Questi termini (e la distinzione tra essi) sono definiti in [RFC3986].

URI/URL Mapping (Mappatura URI/URL)​

Una relazione tra un URI assoluto e una risorsa. Poiché una risorsa può rappresentare elementi che non sono recuperabili tramite rete, così come quelli che lo sono, è possibile che una risorsa abbia zero, una o molte mappature URI. La mappatura di una risorsa a un URI di schema «http» rende possibile inviare richieste di protocollo HTTP alla risorsa utilizzando l'URI.

Path Segment (Segmento di percorso)​

Informalmente, i caratteri trovati tra le barre («/») in un URI. Formalmente, come definito nella Sezione 3.3 di [RFC3986].

Collection (Raccolta)​

Informalmente, una risorsa che funge anche da contenitore di riferimenti a risorse figlie. Formalmente, una risorsa che contiene un insieme di mappature tra segmenti di percorso e risorse e soddisfa i requisiti definiti nella Sezione 5.

Internal Member (of a Collection) (Membro interno di una raccolta)​

Informalmente, una risorsa figlia di una raccolta. Formalmente, una risorsa referenziata da una mappatura di segmento di percorso contenuta nella raccolta.

Internal Member URL (of a Collection) (URL di membro interno di una raccolta)​

Un URL di un membro interno, composto dall'URL della raccolta (inclusa la barra finale) più il segmento di percorso che identifica il membro interno.

Member (of a Collection) (Membro di una raccolta)​

Informalmente, un «discendente» di una raccolta. Formalmente, un membro interno della raccolta, o, ricorsivamente, un membro di un membro interno.

Member URL (of a Collection) (URL di membro di una raccolta)​

Un URL che è o un URL di membro interno della raccolta stessa, o è un URL di membro interno di un membro di quella raccolta.

Property (Proprietà)​

Una coppia nome/valore che contiene informazioni descrittive su una risorsa.

Live Property (Proprietà live)​

Una proprietà la cui semantica e sintassi sono imposte dal server. Ad esempio, la proprietà live DAV:getcontentlength ha il suo valore, la lunghezza dell'entità restituita da una richiesta GET, calcolato automaticamente dal server.

Dead Property (Proprietà dead)​

Una proprietà la cui semantica e sintassi non sono imposte dal server. Il server registra solo il valore di una proprietà dead; il client è responsabile del mantenimento della coerenza della sintassi e della semantica di una proprietà dead.

Principal (Principale)​

Un attore umano o computazionale distinto che avvia l'accesso alle risorse di rete.

State Token (Token di stato)​

Un URI che rappresenta uno stato di una risorsa. I token di blocco (Lock Tokens) sono gli unici token di stato definiti in questa specifica.

4. Data Model for Resource Properties (Modello di dati per le proprietà delle risorse)​

4.1 The Resource Property Model (Il modello di proprietà delle risorse)​

Le proprietà sono pezzi di dati che descrivono lo stato di una risorsa. Le proprietà sono dati sui dati.

Le proprietà sono utilizzate negli ambienti di authoring distribuito per fornire una scoperta e gestione efficiente delle risorse. Ad esempio, una proprietà 'subject' potrebbe consentire l'indicizzazione di tutte le risorse per argomento, e una proprietà 'author' potrebbe consentire di scoprire quali autori hanno scritto quali documenti.

Il modello di proprietà DAV consiste in coppie nome/valore. Il nome di una proprietà identifica la sintassi e la semantica della proprietà e fornisce un indirizzo mediante il quale fare riferimento alla sua sintassi e semantica.

Esistono due categorie di proprietà: "live" e "dead". Una proprietà live ha la sua sintassi e semantica imposte dal server. Le proprietà live includono i casi in cui a) il valore di una proprietà è protetto e mantenuto dal server, e b) il valore della proprietà è mantenuto dal client, ma il server esegue il controllo della sintassi sui valori inviati. Tutte le istanze di una data proprietà live DEVONO conformarsi alla definizione associata a quel nome di proprietà. Una proprietà dead ha la sua sintassi e semantica imposte dal client; il server registra semplicemente il valore della proprietà testualmente.

4.2 Properties and HTTP Headers (Proprietà e intestazioni HTTP)​

Le proprietà esistono già, in senso limitato, nelle intestazioni dei messaggi HTTP. Tuttavia, negli ambienti di authoring distribuito, è necessario un numero relativamente grande di proprietà per descrivere lo stato di una risorsa, e impostarle/restituirle tutte tramite intestazioni HTTP è inefficiente. Pertanto, è necessario un meccanismo che consenta a un principal di identificare un insieme di proprietà a cui è interessato e di impostare o recuperare solo quelle proprietà.

4.3 Property Values (Valori delle proprietà)​

Il valore di una proprietà è sempre un frammento XML ben formato.

XML è stato scelto perché è un formato di dati strutturato flessibile e auto-descrittivo che supporta ricche definizioni di schema e per il suo supporto per più set di caratteri. La natura auto-descrittiva di XML consente di estendere il valore di qualsiasi proprietà aggiungendo elementi. I client non si interromperanno quando incontrano estensioni perché avranno ancora i dati specificati nello schema originale e DEVONO ignorare gli elementi che non comprendono.

Il supporto di XML per più set di caratteri consente a qualsiasi proprietà leggibile dall'uomo di essere codificata e letta in un set di caratteri familiare all'utente. Il supporto di XML per più lingue umane, utilizzando l'attributo "xml:lang", gestisce i casi in cui lo stesso set di caratteri è impiegato da più lingue umane. Si noti che l'ambito xml:lang è ricorsivo, quindi un attributo xml:lang su qualsiasi elemento contenente un elemento nome di proprietà si applica al valore della proprietà a meno che non sia stato sovrascritto da un attributo con ambito più locale. Si noti che una proprietà ha solo un valore, in una lingua (o la lingua PUÒ essere lasciata non definita); una proprietà non ha più valori in lingue diverse o un singolo valore in più lingue.

Una proprietà è sempre rappresentata con un elemento XML costituito dal nome della proprietà, chiamato "property name element". L'esempio più semplice è una proprietà vuota, che è diversa da una proprietà che non esiste:

<R:title xmlns:R="http://www.example.com/ns/"><R:title>

Il valore della proprietà appare all'interno dell'elemento nome di proprietà. Il valore può essere qualsiasi tipo di contenuto XML ben formato, incluso contenuto solo testo e contenuto misto. I server DEVONO preservare i seguenti XML Information Items (utilizzando la terminologia da [REC-XML-INFOSET]) nell'archiviazione e trasmissione delle proprietà dead:

Per l'Element Information Item del nome di proprietà stesso:

  • [namespace name]
  • [local name]
  • [attributes] denominati "xml:lang" o qualsiasi tale attributo nell'ambito
  • [children] di tipo element o character

Su tutti gli Element Information Items nel valore della proprietà:

  • [namespace name]
  • [local name]
  • [attributes]
  • [children] di tipo element o character

Sugli Attribute Information Items nel valore della proprietà:

  • [namespace name]
  • [local name]
  • [normalized value]

Sui Character Information Items nel valore della proprietà:

  • [character code]

Poiché i prefissi sono utilizzati in alcuni vocabolari XML (XPath e XML Schema, ad esempio), i server DOVREBBERO preservare, per qualsiasi Information Item nel valore:

  • [prefix]

Gli attributi XML Infoset non elencati sopra POSSONO essere preservati dal server, ma i client NON DEVONO fare affidamento sulla loro preservazione. Le regole sopra si applicherebbero anche per impostazione predefinita alle proprietà live, salvo diversa definizione.

I server DEVONO ignorare l'attributo XML xml:space se presente e non utilizzarlo mai per modificare la gestione degli spazi bianchi. Gli spazi bianchi nei valori delle proprietà sono significativi.

4.3.1 Esempio - Proprietà con contenuto misto​

Consideriamo una proprietà dead 'author' creata dal client come segue:

<D:prop xml:lang="en" xmlns:D="DAV:">
  <x:author xmlns:x='http://example.com/ns'>
    <x:name>Jane Doe<x:name>
    <!-- Jane's contact info -->
    &lt;x:uri type='email'
           added='2005-11-26'>mailto:[email protected]&lt;x:uri>
    &lt;x:uri type='web'
           added='2005-11-27'>http://www.example.com&lt;x:uri>
    &lt;x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of <![CDATA[&lt;RFC2518>]]>.
    &lt;x:notes>
  &lt;x:author>
&lt;D:prop>

Quando questa proprietà viene richiesta, un server potrebbe restituire:

&lt;D:prop xmlns:D='DAV:'>&lt;author
        xml:lang='en'
        xmlns:x='http://example.com/ns'
        xmlns='http://example.com/ns'
        xmlns:h='http://www.w3.org/1999/xhtml'>
    &lt;x:name>Jane Doe&lt;x:name>
    &lt;x:uri   added="2005-11-26" type="email"
      >mailto:[email protected]&lt;x:uri>
    &lt;x:uri   added="2005-11-27" type="web"
      >http://www.example.com&lt;x:uri>
    &lt;x:notes>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of &lt;RFC2518&gt;.
    &lt;x:notes>
  &lt;/author>
&lt;D:prop>

Notare in questo esempio:

  • Il [prefix] per il nome della proprietà stessa non è stato preservato, essendo non significativo, mentre tutti gli altri valori [prefix] sono stati preservati,
  • i valori degli attributi sono stati riscritti con virgolette doppie invece di virgolette singole (lo stile delle virgolette non è significativo), e l'ordine degli attributi non è stato preservato,
  • l'attributo xml:lang è stato restituito sull'elemento nome di proprietà stesso (era nell'ambito quando la proprietà è stata impostata, ma la posizione esatta nella risposta non è considerata significativa finché è nell'ambito),
  • gli spazi bianchi tra i tag sono stati preservati ovunque (non così gli spazi bianchi tra gli attributi),
  • l'incapsulamento CDATA è stato sostituito con l'escaping dei caratteri (anche il contrario sarebbe legale),
  • l'elemento commento è stato rimosso (così come sarebbe stato un elemento di istruzione di elaborazione).

Nota di implementazione: ci sono casi come scenari di modifica in cui i client potrebbero richiedere che il contenuto XML sia preservato carattere per carattere (come l'ordine degli attributi o lo stile delle virgolette). In questo caso, i client dovrebbero considerare l'utilizzo di un valore di proprietà solo testo eseguendo l'escape di tutti i caratteri che hanno un significato speciale nell'analisi XML.

4.4 Property Names (Nomi delle proprietà)​

Un nome di proprietà è un identificatore universalmente unico che è associato a uno schema che fornisce informazioni sulla sintassi e la semantica della proprietà.

Poiché il nome di una proprietà è universalmente unico, i client possono dipendere da un comportamento coerente per una particolare proprietà su più risorse, sullo stesso server e su server diversi, a condizione che quella proprietà sia "live" sulle risorse in questione e che l'implementazione della proprietà live sia fedele alla sua definizione.

Il meccanismo dello spazio dei nomi XML, che si basa sugli URI ([RFC3986]), viene utilizzato per nominare le proprietà perché previene collisioni dello spazio dei nomi e fornisce vari gradi di controllo amministrativo.

Lo spazio dei nomi delle proprietà è piatto; cioè, nessuna gerarchia di proprietà è esplicitamente riconosciuta. Pertanto, se una proprietà A e una proprietà A/B esistono su una risorsa, non c'è riconoscimento di alcuna relazione tra le due proprietà. Ci si aspetta che venga eventualmente prodotta una specifica separata che affronterà questioni relative alle proprietà gerarchiche.

Infine, non è possibile definire la stessa proprietà due volte su una singola risorsa, poiché ciò causerebbe una collisione nello spazio dei nomi delle proprietà della risorsa.

4.5 Source Resources and Output Resources (Risorse sorgente e risorse di output)​

Alcune risorse HTTP sono generate dinamicamente dal server. Per queste risorse, presumibilmente esiste da qualche parte un codice sorgente che regola come quella risorsa viene generata. La relazione tra i file sorgente e le risorse HTTP di output può essere uno a uno, uno a molti, molti a uno o molti a molti. Non esiste alcun meccanismo in HTTP per determinare se una risorsa è persino dinamica, tantomeno dove esistono i suoi file sorgente o come crearli. Sebbene questo problema sarebbe utilmente risolto, implementazioni WebDAV interoperabili sono state ampiamente distribuite senza risolvere effettivamente questo problema, occupandosi solo di risorse statiche. Pertanto, il problema sorgente vs. output non è risolto in questa specifica ed è stato rinviato a un documento separato.

5. Collections of Web Resources (Collezioni di risorse Web)​

Questa sezione fornisce una descrizione di un tipo di risorsa Web, la collezione, e discute le sue interazioni con lo spazio dei nomi URL HTTP e con i metodi HTTP. Lo scopo di una risorsa collezione è modellare oggetti simili a collezioni (ad esempio, directory del file system) all'interno dello spazio dei nomi di un server.

Tutte le risorse conformi a DAV DEVONO supportare il modello di spazio dei nomi URL HTTP specificato qui.

5.1 HTTP URL Namespace Model (Modello di spazio dei nomi URL HTTP)​

Lo spazio dei nomi URL HTTP è uno spazio dei nomi gerarchico dove la gerarchia è delimitata dal carattere "/".

Uno spazio dei nomi URL HTTP è detto essere coerente se soddisfa le seguenti condizioni: per ogni URL nella gerarchia HTTP esiste una collezione che contiene quell'URL come URL membro interno. La radice, o collezione di livello superiore dello spazio dei nomi in considerazione, è esente dalla regola precedente. La collezione di livello superiore dello spazio dei nomi in considerazione non è necessariamente la collezione identificata dal percorso assoluto '/' -- può essere identificata da uno o più segmenti di percorso (ad esempio, /servlets/webdav/...)

Né HTTP/1.1 né WebDAV richiedono che l'intero spazio dei nomi URL HTTP sia coerente -- una risorsa compatibile con WebDAV potrebbe non avere una collezione genitore. Tuttavia, alcuni metodi WebDAV sono proibiti dal produrre risultati che causano incoerenze nello spazio dei nomi.

Come è implicito in [RFC2616] e [RFC3986], qualsiasi risorsa, incluse le risorse collezione, PUÒ essere identificata da più di un URI. Ad esempio, una risorsa potrebbe essere identificata da più URL HTTP.

5.2 Collection Resources (Risorse collezione)​

Le risorse collezione differiscono dalle altre risorse in quanto agiscono anche come contenitori. Alcuni metodi HTTP si applicano solo a una collezione, ma alcuni si applicano ad alcune o a tutte le risorse all'interno del contenitore definito dalla collezione. Quando l'ambito di un metodo non è chiaro, il client può specificare quale profondità applicare. La profondità può essere zero livelli (solo la collezione), un livello (la collezione e le risorse direttamente contenute), o livelli infiniti (la collezione e tutte le risorse contenute ricorsivamente).

Lo stato di una collezione consiste almeno in un insieme di mappature tra segmenti di percorso e risorse, e un insieme di proprietà sulla collezione stessa. In questo documento, una risorsa B sarà detta essere contenuta nella risorsa collezione A se esiste una mappatura di segmento di percorso che mappa a B e che è contenuta in A. Una collezione DEVE contenere al massimo una mappatura per un dato segmento di percorso, cioè, è illegale avere lo stesso segmento di percorso mappato a più di una risorsa.

Le proprietà definite sulle collezioni si comportano esattamente come le proprietà sulle risorse non-collezione. Una collezione PUÒ avere uno stato aggiuntivo come i corpi entità restituiti da GET.

Per tutte le risorse conformi a WebDAV A e B, identificate rispettivamente dagli URL "U" e "V", tali che "V" è uguale a "U/SEGMENT", A DEVE essere una collezione che contiene una mappatura da "SEGMENT" a B. Quindi, se la risorsa B con URL http://example.com/bar/blah è conforme a WebDAV e se la risorsa A con URL http://example.com/bar/ è conforme a WebDAV, allora la risorsa A deve essere una collezione e deve contenere esattamente una mappatura da "blah" a B.

Sebbene comunemente una mappatura consista in un singolo segmento e una risorsa, in generale, una mappatura consiste in un insieme di segmenti e una risorsa. Questo permette a un server di trattare un insieme di segmenti come equivalenti (cioè, o tutti i segmenti sono mappati alla stessa risorsa, o nessuno dei segmenti è mappato a una risorsa). Ad esempio, un server che esegue il folding delle maiuscole/minuscole sui segmenti tratterà i segmenti "ab", "Ab", "aB" e "AB" come equivalenti. Un client può quindi usare qualsiasi di questi segmenti per identificare la risorsa. Si noti che un risultato PROPFIND selezionerà uno di questi segmenti equivalenti per identificare la mappatura, quindi ci sarà un elemento di risposta PROPFIND per mappatura, non uno per segmento nella mappatura.

Le risorse collezione POSSONO avere mappature a risorse non conformi a WebDAV nella gerarchia dello spazio dei nomi URL HTTP ma non sono obbligate a farlo. Ad esempio, se la risorsa X con URL http://example.com/bar/blah non è conforme a WebDAV e la risorsa A con URL http://example.com/bar/ identifica una collezione WebDAV, allora A può o meno avere una mappatura da "blah" a X.

Se una risorsa conforme a WebDAV non ha membri interni conformi a WebDAV nella gerarchia dello spazio dei nomi URL HTTP, allora la risorsa conforme a WebDAV non è tenuta ad essere una collezione.

Esiste una convenzione consolidata secondo cui quando una collezione è riferita con il suo nome senza barra finale, il server PUÒ gestire la richiesta come se la barra finale fosse presente. In questo caso, DOVREBBE restituire un'intestazione Content-Location nella risposta, puntando all'URL che termina con "/". Ad esempio, se un client invoca un metodo su http://example.com/blah (senza barra finale), il server può rispondere come se l'operazione fosse invocata su http://example.com/blah/ (con barra finale), e dovrebbe restituire un'intestazione Content-Location con il valore http://example.com/blah/. Ovunque un server produca un URL che fa riferimento a una collezione, il server DOVREBBE includere la barra finale. In generale, i client DOVREBBERO usare la forma con barra finale dei nomi di collezione. Se i client non usano la forma con barra finale, il client deve essere preparato a vedere una risposta di reindirizzamento. I client troveranno la proprietà DAV:resourcetype più affidabile dell'URL per scoprire se una risorsa è una collezione.

I client DEVONO essere in grado di supportare il caso in cui le risorse WebDAV sono contenute all'interno di risorse non-WebDAV. Ad esempio, se una risposta OPTIONS da http://example.com/servlet/dav/collection indica il supporto WebDAV, il client non può assumere che http://example.com/servlet/dav/ o il suo genitore siano necessariamente collezioni WebDAV.

Uno scenario tipico in cui gli URL mappati non appaiono come membri della loro collezione genitore è il caso in cui un server consente link o reindirizzamenti a risorse non-WebDAV. Ad esempio, "/col/link" potrebbe non apparire come membro di "/col/", sebbene il server risponderebbe con uno stato 302 a una richiesta GET a "/col/link"; quindi, l'URL "/col/link" sarebbe effettivamente mappato. Analogamente, una pagina generata dinamicamente potrebbe avere una mappatura URL da "/col/index.html", quindi questa risorsa potrebbe rispondere con 200 OK a una richiesta GET ma non apparire come membro di "/col/".

Alcune mappature a risorse persino conformi a WebDAV potrebbero non apparire nella collezione genitore. Un esempio per questo caso sono i server che supportano più URL alias per ogni risorsa conforme a WebDAV. Un server può implementare URL case-insensitive, quindi "/col/a" e "/col/A" identificano la stessa risorsa, ma solo "a" o "A" viene riportato quando si elencano i membri di "/col". Nei casi in cui un server tratta un insieme di segmenti come equivalenti, il server DEVE esporre solo un segmento preferito per mappatura, scelto in modo coerente, nelle risposte PROPFIND.

6. Locking (Blocco)​

La capacità di bloccare una risorsa fornisce un meccanismo per serializzare l'accesso a quella risorsa. Utilizzando un blocco, un client di authoring può fornire una garanzia ragionevole che un altro principale non modificherà una risorsa mentre viene modificata. In questo modo, un client può prevenire il problema dell'«aggiornamento perso (Lost Update)».

Questa specifica permette ai blocchi di variare su due parametri specificati dal client: il numero di principali coinvolti (blocchi esclusivi vs. blocchi condivisi) e il tipo di accesso da concedere. Questo documento definisce il blocco solo per un tipo di accesso: scrittura (Write). Tuttavia, la sintassi è estensibile e consente l'eventuale specifica del blocco per altri tipi di accesso.

6.1 Lock Model (Modello di blocco)​

Questa sezione fornisce una descrizione non normativa del blocco WebDAV.

Un blocco è identificato da un token di blocco (Lock Token). I token di blocco sono URL e possono essere trasmessi tramite HTTP. Un token di blocco è associato a un solo blocco.

I blocchi possono essere esclusivi o condivisi. Il tipo di blocco determina come il server gestisce le richieste sulla risorsa bloccata:

Blocco esclusivo (Exclusive Lock):

  • Solo il principale che ha creato il blocco può modificare la risorsa
  • Impedisce a qualsiasi altro principale di ottenere un blocco conflittuale

Blocco condiviso (Shared Lock):

  • Più principali possono detenere blocchi condivisi
  • Tutti i principali che detengono blocchi condivisi possono modificare la risorsa
  • Impedisce ai principali che non detengono blocchi di modificare la risorsa

I blocchi possono avere ambiti diversi:

  • Blocco diretto (Direct Lock): Il blocco si applica direttamente alla risorsa
  • Blocco di profondità (Depth Lock): Il blocco si applica alla risorsa e a tutti i suoi membri

Per le raccolte, la profondità può essere specificata:

  • Depth: 0: Blocca solo la raccolta stessa
  • Depth: infinity: Blocca la raccolta e tutti i suoi membri (ricorsivamente)

6.2 Exclusive vs. Shared Locks (Blocchi esclusivi vs. blocchi condivisi)​

Il tipo di blocco più comune è il blocco esclusivo (Exclusive Lock). Lo scopo di un blocco esclusivo è imporre una politica di modifica di un particolare principale. Un uso comune di un blocco esclusivo è impedire a diversi principali di modificare una risorsa durante una lunga sessione di authoring.

I blocchi condivisi (Shared Locks) sono progettati per supportare l'authoring collaborativo, dove un gruppo di principali deve modificare una risorsa simultaneamente. La caratteristica chiave dei blocchi condivisi è che più principali possono detenere blocchi condivisi, ma i blocchi esclusivi escludono tutti gli altri blocchi.

Tabella di compatibilità dei blocchi:

Stato attualeRichiesta di blocco condivisoRichiesta di blocco esclusivo
Nessuno✅ Vero✅ Vero
Blocco condiviso✅ Vero❌ Falso
Blocco esclusivo❌ Falso❌ Falso

6.3 Required Support (Supporto richiesto)​

Un server deve (MUST) supportare i blocchi di scrittura esclusivi (Exclusive Write Locks).

Un server può (MAY) supportare i blocchi di scrittura condivisi (Shared Write Locks). Se un server non supporta i blocchi di scrittura condivisi, il server deve (MUST) restituire un errore quando un client richiede un blocco di scrittura condiviso.

6.4 Lock Creator and Privileges (Creatore del blocco e privilegi)​

Un blocco è associato al principale che ha creato il blocco. Solo i principali con il token di blocco appropriato possono sbloccare una risorsa. Questo garantisce che il creatore del blocco abbia il controllo sul ciclo di vita del blocco.

Il principale che crea un blocco deve avere i privilegi per creare blocchi sulla risorsa. I requisiti di privilegio specifici sono determinati dalla politica di controllo degli accessi del server.

6.5 Lock Tokens (Token di blocco)​

Un token di blocco (Lock Token) è un URL che identifica univocamente un blocco. I token di blocco utilizzano tipicamente lo schema URI opaquelocktoken: (vedi Appendice C).

Caratteristiche dei token di blocco:

  • Unicità globale: Ogni token di blocco è globalmente unico
  • Imprevedibilità: I token di blocco dovrebbero essere imprevedibili per prevenire accessi non autorizzati
  • Formato URL: I token di blocco sono URL validi

Esempio di token di blocco:

opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

I client inviano token di blocco tramite:

  • Inclusione del token di blocco nell'header If
  • Inclusione del token di blocco nell'header Lock-Token (solo per il metodo UNLOCK)

6.6 Lock Timeout (Timeout del blocco)​

I blocchi hanno una durata di vita limitata. Il server assegna un valore di timeout a ogni blocco, dopo il quale il blocco scade automaticamente.

Caratteristiche del timeout:

  • I client possono suggerire un valore di timeout nell'header di richiesta Timeout
  • I server possono ignorare il suggerimento del client e assegnare il proprio valore di timeout
  • I server devono (MUST) restituire il valore di timeout effettivo nella risposta di blocco
  • I client possono estendere la durata di vita del blocco aggiornando il blocco

Formato del timeout:

Timeout: Second-4100
Timeout: Infinite

Migliori pratiche:

  • I server dovrebbero (SHOULD) consentire ai client di aggiornare i blocchi
  • I client dovrebbero (SHOULD) aggiornare periodicamente i blocchi a lungo termine
  • I client dovrebbero (SHOULD) sbloccare le risorse una volta completata la modifica

6.7 Lock Capability Discovery (Scoperta delle capacità di blocco)​

Prima di tentare di bloccare una risorsa, i client possono scoprire le capacità di blocco del server utilizzando il metodo OPTIONS. L'header DAV nella risposta indica la classe di conformità WebDAV del server, che include il supporto del blocco.

6.8 Active Lock Discovery (Scoperta dei blocchi attivi)​

I client possono scoprire i blocchi attivi su una risorsa utilizzando il metodo PROPFIND per recuperare la proprietà DAV:lockdiscovery. Questa proprietà contiene informazioni su tutti i blocchi attivi sulla risorsa, inclusi tipo di blocco, ambito, profondità, proprietario, timeout e token di blocco.

7. Write Lock (Blocco di Scrittura)​

Questa sezione descrive il blocco di scrittura (Write Lock), l'unico tipo di blocco definito in questa specifica. Un blocco di scrittura è un blocco che concede al proprietario del blocco il diritto di modificare la risorsa. Il proprietario del blocco è il principale che ha creato il blocco.

7.1 Write Locks and Properties (Blocchi di scrittura e proprietà)​

Sebbene coloro che non hanno un blocco di scrittura non possano modificare il contenuto di una risorsa, possono (MAY) modificare le proprietà dead della risorsa. Ciò consente, ad esempio, a un principale di aggiungere commenti a una risorsa bloccata senza necessitare di accesso in scrittura.

Le proprietà live hanno tipicamente una semantica imposta dal server. Il server ha quindi discrezionalità su se e come consentire modifiche alle proprietà live quando una risorsa è bloccata. Ad esempio, un server può (MAY) consentire la modifica delle proprietà live anche quando una risorsa è bloccata.

7.2 Avoiding Lost Updates (Evitare aggiornamenti persi)​

Lo scopo dei blocchi di scrittura è prevenire gli aggiornamenti persi. Un aggiornamento perso si verifica quando più principali tentano di modificare una risorsa senza coordinamento, risultando in una o più modifiche dei principali sovrascritte da aggiornamenti successivi.

I blocchi di scrittura forniscono un meccanismo di serializzazione: solo il detentore del blocco può modificare la risorsa bloccata. Ciò previene il problema dell'aggiornamento perso garantendo che le modifiche avvengano sequenzialmente piuttosto che contemporaneamente.

Esempio di scenario di aggiornamento perso (senza blocco):

  1. L'utente A recupera la versione 1 della risorsa
  2. L'utente B recupera la versione 1 della risorsa
  3. L'utente A modifica e salva → crea la versione 2
  4. L'utente B modifica (basandosi sulla versione 1) e salva → crea la versione 3, sovrascrivendo le modifiche di A

Con blocco di scrittura:

  1. L'utente A blocca la risorsa
  2. L'utente B tenta di modificare → riceve un errore 423 Locked
  3. L'utente A modifica e sblocca
  4. L'utente B può ora bloccare e modificare

7.3 Write Locks and Unmapped URLs (Blocchi di scrittura e URL non mappati)​

Una richiesta LOCK riuscita su un URL non mappato crea una risorsa vuota che è bloccata. Questo meccanismo consente ai client di riservare un URL prima che il contenuto della risorsa venga creato.

Quando viene creata una risorsa vuota bloccata:

  • La risorsa non ha contenuto (entità di lunghezza zero)
  • La risorsa è bloccata con il blocco specificato
  • Un successivo PUT o MKCOL può aggiungere contenuto alla risorsa
  • Il token di blocco deve essere inviato con la richiesta PUT o MKCOL

Questo meccanismo di "risorsa lock-null" è descritto in dettaglio nell'Appendice D.

7.4 Write Locks and Collections (Blocchi di scrittura e raccolte)​

Un blocco di scrittura su una raccolta blocca la risorsa raccolta stessa, impedendo modifiche all'appartenenza della raccolta (aggiunta o rimozione di membri interni).

Quando un blocco di profondità infinita viene applicato a una raccolta:

  • La raccolta stessa è bloccata
  • Tutti i membri interni sono bloccati
  • Tutte le risorse discendenti sono bloccate ricorsivamente
  • I nuovi membri aggiunti alla raccolta sono automaticamente bloccati

Ereditarietà del blocco: Quando una nuova risorsa viene aggiunta a una raccolta bloccata (con profondità infinita), la nuova risorsa eredita il blocco dalla raccolta genitore.

7.5 Write Locks and the If Request Header (Blocchi di scrittura e l'header di richiesta If)​

I client inviano token di blocco utilizzando l'header di richiesta If. Questo header consente l'esecuzione condizionale di metodi basata sulla presenza di token di blocco.

La sintassi dell'header If supporta:

  • Token di blocco singoli
  • Token di blocco multipli (per blocchi multipli)
  • Liste taggate (associando token a URL specifici)
  • Condizioni NOT (richiedendo l'assenza di blocchi)

7.5.1 Example - Write Lock and COPY (Esempio - Blocco di scrittura e COPY)​

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/destination
If: `http://example.com/destination` (&lt;opaquelocktoken:token123>)

Questa richiesta copia /source in /destination, ma solo se il client detiene il token di blocco per /destination.

7.5.2 Example - Deleting a Member of a Locked Collection (Esempio - Eliminazione di un membro di una raccolta bloccata)​

DELETE /folder/file.txt HTTP/1.1
Host: example.com
If: `http://example.com/folder/` (&lt;opaquelocktoken:folder-token>)

Per eliminare un membro di una raccolta bloccata, il client deve inviare il token di blocco per la raccolta.

7.6 Write Locks and COPY/MOVE (Blocchi di scrittura e COPY/MOVE)​

Il metodo COPY crea una nuova risorsa alla destinazione. La nuova risorsa NON è automaticamente bloccata, anche se la sorgente era bloccata. I blocchi non sono copiati.

Il metodo MOVE è semanticamente equivalente a COPY seguito da DELETE. Il blocco sulla sorgente viene rimosso quando la risorsa viene spostata. La destinazione non è automaticamente bloccata.

Se la destinazione di un COPY o MOVE è bloccata, il client deve inviare il token di blocco appropriato per sovrascrivere la destinazione.

7.7 Refreshing Write Locks (Aggiornamento dei blocchi di scrittura)​

I blocchi hanno durate di vita finite. Per prevenire la scadenza prematura del blocco, i client possono aggiornare i blocchi inviando una richiesta LOCK con:

  • Lo stesso token di blocco nell'header If
  • Nessun corpo della richiesta (o un elemento lockinfo vuoto)

Il server risponde con il nuovo valore di timeout. L'aggiornamento del blocco consente sessioni di modifica a lungo termine senza scadenza del blocco.

Esempio di aggiornamento del blocco:

LOCK /resource HTTP/1.1
Host: example.com
If: (&lt;opaquelocktoken:token123>)
Timeout: Second-3600

Il server estende il timeout del blocco e restituisce il nuovo tempo di scadenza.

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.

9. HTTP Methods for Distributed Authoring (Metodi HTTP per l'authoring distribuito)​

Questo capitolo descrive i metodi HTTP definiti da WebDAV e le estensioni ai metodi HTTP esistenti.

Panoramica dei metodi WebDAV​

MetodoScopoDestinazione
PROPFINDRecuperare proprietàRisorsa o raccolta
PROPPATCHModificare proprietàRisorsa
MKCOLCreare una raccoltaURL non mappato
COPYCopiare una risorsaSorgente e destinazione
MOVESpostare/rinominareSorgente e destinazione
LOCKBloccare una risorsaRisorsa o raccolta
UNLOCKSbloccare una risorsaRisorsa bloccata

9.1 Metodo PROPFIND​

PROPFIND recupera le proprietà definite sulla risorsa identificata dal Request-URI.

Tipi di richiesta: propname, allprop, prop, allprop + include

9.2 Metodo PROPPATCH​

PROPPATCH modifica le proprietà di una risorsa.

Operazioni: set (creare/aggiornare), remove (eliminare)

Atomicità: Tutte le operazioni devono (MUST) avere successo o fallire insieme.

9.3 Metodo MKCOL​

MKCOL crea una nuova risorsa raccolta al Request-URI.

9.4 GET, HEAD per le raccolte​

GET e HEAD applicati a una raccolta possono (MAY) restituire un elenco di directory HTML.

9.5 POST per le raccolte​

POST aggiunge membri a una raccolta. Il server determina l'URL del nuovo membro.

9.6 Metodo DELETE​

DELETE rimuove la risorsa identificata dal Request-URI.

Per le raccolte: Elimina la raccolta e tutti i membri ricorsivamente.

9.7 Metodo PUT​

PUT crea o aggiorna una risorsa.

9.8 Metodo COPY​

COPY crea un duplicato della risorsa sorgente alla destinazione.

Header: Destination (richiesto), Depth, Overwrite

Comportamento: I blocchi NON vengono copiati.

9.9 Metodo MOVE​

MOVE è logicamente equivalente a COPY + DELETE.

Atomicità: Le operazioni MOVE devono (MUST) essere atomiche.

9.10 Metodo LOCK​

LOCK ottiene un blocco su una risorsa.

Tipi di blocco: Blocco di scrittura esclusivo, Blocco di scrittura condiviso

9.11 Metodo UNLOCK​

UNLOCK rimuove il blocco identificato dal token di blocco.

Per le specifiche complete dei metodi, consultare RFC 4918 Sezioni 9.1-9.11.

10. HTTP Headers for Distributed Authoring (Intestazioni HTTP per la creazione distribuita)​

WebDAV definisce diverse intestazioni HTTP nuove per supportare le funzionalità di creazione distribuita.

10.1 DAV Header (Intestazione DAV)​

L'intestazione DAV indica i livelli di funzionalità WebDAV supportati dal server.

Sintassi​

DAV: 1, 2, 3, access-control, calendar-access

Livelli di conformità​

  • 1: supporto WebDAV di base (PROPFIND, PROPPATCH, MKCOL, estensioni GET/HEAD, estensioni PUT, estensioni DELETE, OPTIONS, COPY, MOVE)
  • 2: livello 1 più supporto LOCK e UNLOCK
  • 3: livello 2 più supporto per collezioni ordinate (facoltativo)

Scenari d'uso​

Risposta OPTIONS:

OPTIONS /resource HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
DAV: 1, 2
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK

10.2 Depth Header (Intestazione Depth)​

L'intestazione Depth specifica la profondità della gerarchia di risorse a cui deve essere applicata l'operazione.

Sintassi​

Depth: 0 | 1 | infinity

Significato dei valori​

  • 0: applicata solo alla risorsa di destinazione
  • 1: applicata alla risorsa e ai suoi membri diretti
  • infinity: applicata ricorsivamente alla risorsa e a tutti i discendenti

Metodi applicabili​

MetodoSupporto DepthValore predefinito
PROPFIND0, 1, infinityinfinity
COPY0, infinityinfinity
MOVEinfinity (gli altri valori sono ignorati)infinity
LOCK0, infinityinfinity
DELETEignorato (sempre ricorsivo)N/A

Esempi​

<!-- Interroga solo le proprietà della collezione stessa -->
PROPFIND /collection/ HTTP/1.1
Host: example.com
Depth: 0

<!-- Interroga la collezione e i suoi membri diretti -->
PROPFIND /collection/ HTTP/1.1
Host: example.com
Depth: 1

10.3 Destination Header (Intestazione Destination)​

L'intestazione Destination specifica l'URL di destinazione per le operazioni COPY o MOVE.

Sintassi​

Destination: absoluteURI

Requisiti​

  • Obbligatoria: i metodi COPY e MOVE devono includere questa intestazione
  • URI assoluto: deve essere un URI assoluto completo
  • Stesso server: in genere sorgente e destinazione devono trovarsi sullo stesso server

Esempi​

COPY /source/file.txt HTTP/1.1
Host: example.com
Destination: http://example.com/destination/file.txt
Overwrite: T

MOVE /old-name.doc HTTP/1.1
Host: example.com
Destination: http://example.com/new-name.doc

10.4 If Header (Intestazione If)​

L'intestazione If fornisce un meccanismo per eseguire condizionalmente metodi WebDAV, inviando token di blocco ed ETag.

Sintassi​

L'intestazione If ha due forme:

Forma no-tag-list:

If: (<locktoken>) ([etag])

Forma tagged-list:

If: <resource-url> (<locktoken>)

Usi​

  1. Invio di token di blocco: prova che il client possiede il blocco
  2. Richieste condizionali: esecuzione condizionale basata su ETag
  3. Combinazione logica: supporto della logica AND e OR

Esempi​

Invio di token di blocco:

PUT /locked-resource HTTP/1.1
Host: example.com
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
Content-Type: text/plain

Updated content

Condizioni multiple:

DELETE /resource HTTP/1.1
Host: example.com
If: <http://example.com/resource>
    (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
    (["e0-b2-1a2"])

Condizione NOT:

If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)

Regole di corrispondenza dell'intestazione If​

  1. Corrispondenza del token di blocco: controlla che il token inviato corrisponda al blocco della risorsa
  2. Corrispondenza ETag: controlla che l'etichetta di entità corrisponda
  3. Valutazione logica: valuta da sinistra a destra, con supporto di short-circuit

Scenari d'uso​

Scenario 1: modifica di una risorsa bloccata

PUT /locked-doc HTTP/1.1
If: (<urn:uuid:lock-token-here>)

Scenario 2: COPY verso una destinazione bloccata

COPY /source HTTP/1.1
Destination: http://example.com/locked-dest
If: <http://example.com/locked-dest>
    (<urn:uuid:dest-lock-token>)

Scenario 3: aggiornamento condizionale

PUT /resource HTTP/1.1
If: (["etag-value"])

10.5 Lock-Token Header (Intestazione Lock-Token)​

L'intestazione Lock-Token è usata nel metodo UNLOCK per specificare il blocco da rimuovere.

Sintassi​

Lock-Token: <uri>

Uso​

Solo per UNLOCK:

UNLOCK /resource HTTP/1.1
Host: example.com
Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>

HTTP/1.1 204 No Content

Differenza rispetto all'intestazione If​

  • Lock-Token: usata solo per UNLOCK, specifica il blocco da eliminare
  • If: usata da altri metodi, invia token di blocco per dimostrare l'autorizzazione

10.6 Overwrite Header (Intestazione Overwrite)​

L'intestazione Overwrite specifica se un'operazione COPY o MOVE deve sovrascrivere la risorsa di destinazione.

Sintassi​

Overwrite: T | F

Valori​

  • T (True): sovrascrive la risorsa di destinazione (valore predefinito)
  • F (False): non sovrascrive; se la destinazione esiste, l'operazione fallisce

Comportamento​

Overwrite: T:

  • Se la destinazione esiste, viene prima eliminata
  • Poi viene creata la nuova risorsa
  • Viene restituito 204 No Content

Overwrite: F:

  • Se la destinazione esiste, l'operazione fallisce
  • Viene restituito 412 Precondition Failed
  • Nessuna risorsa viene modificata

Esempio​

<!-- Non sovrascrive un file esistente -->
COPY /source.txt HTTP/1.1
Host: example.com
Destination: http://example.com/dest.txt
Overwrite: F

<!-- Se dest.txt esiste -->
HTTP/1.1 412 Precondition Failed

<!-- Se dest.txt non esiste -->
HTTP/1.1 201 Created

10.7 Timeout Request Header (Intestazione di richiesta Timeout)​

L'intestazione Timeout è usata nelle richieste LOCK per suggerire la durata del blocco.

Sintassi​

Timeout: Second-<seconds> | Infinite

Esempi​

LOCK /resource HTTP/1.1
Host: example.com
Timeout: Second-3600

<!-- Oppure richiede un timeout infinito -->
Timeout: Infinite

<!-- Più valori di timeout, in ordine di preferenza -->
Timeout: Infinite, Second-604800, Second-86400

Comportamento del server​

  • Può rifiutare: il server può ignorare il suggerimento del client
  • Restituisce il valore effettivo: la risposta deve includere il timeout scelto dal server
  • Limiti di sicurezza: il server può imporre una durata massima del timeout

Timeout nella risposta​

<D:activelock>
  <D:timeout>Second-3600</D:timeout>
  ...
</D:activelock>

Riferimento rapido alle intestazioni HTTP​

IntestazioneMetodiObbligatoria/facoltativaDescrizione
DAVOPTIONSrispostaLivelli di funzionalità supportati dal server
DepthPROPFIND, COPY, LOCKfacoltativaProfondità dell'operazione
DestinationCOPY, MOVEobbligatoriaURL di destinazione
Iftutti i metodifacoltativaEsecuzione condizionale e invio di token di blocco
Lock-TokenUNLOCKobbligatoriaToken del blocco da eliminare
OverwriteCOPY, MOVEfacoltativaIndica se sovrascrivere la destinazione
TimeoutLOCKfacoltativaTimeout suggerito per il blocco

Sintesi del capitolo: il Capitolo 10 definisce sette intestazioni HTTP specifiche di WebDAV. Queste intestazioni estendono le capacità di HTTP/1.1 e supportano operazioni in profondità (Depth), operazioni sulle risorse (Destination, Overwrite), gestione dei blocchi (Lock-Token, Timeout) ed esecuzione condizionale (If). Il loro uso corretto è essenziale per implementare client e server WebDAV affidabili.

12. Use of HTTP Status Codes (Uso dei codici di stato HTTP)​

Questi codici HTTP non sono ridefiniti, ma il loro uso è in qualche modo esteso dai metodi e dai requisiti WebDAV. In generale, molti codici di stato HTTP possono essere utilizzati in risposta a qualsiasi richiesta, non solo nei casi descritti in questo documento. Si noti inoltre che i server WebDAV sono noti per utilizzare risposte di reindirizzamento di livello 300 (e i primi test di interoperabilità hanno rilevato che i client non erano preparati a vedere queste risposte). Una risposta di livello 300 NON DEVE essere utilizzata quando il server ha creato una nuova risorsa in risposta alla richiesta.

12.1. 412 Precondition Failed (412 Precondizione fallita)​

Qualsiasi richiesta può contenere un'intestazione condizionale definita in HTTP (If-Match, If-Modified-Since, ecc.) o le intestazioni condizionali "If" o "Overwrite" definite in questa specifica. Se il server valuta un'intestazione condizionale e tale condizione non è soddisfatta, allora questo codice di errore DEVE essere restituito. D'altra parte, se il client non ha incluso un'intestazione condizionale nella richiesta, allora il server NON DEVE utilizzare questo codice di stato.

12.2. 414 Request-URI Too Long (414 URI di richiesta troppo lungo)​

Questo codice di stato viene utilizzato in HTTP 1.1 solo per i Request-URI, non per gli URI in altre posizioni.

13. Multi-Status Response (Risposta multi-stato)​

Una risposta Multi-Status trasmette informazioni su più risorse in situazioni in cui potrebbero essere appropriati più codici di stato. Il corpo della risposta Multi-Status predefinito è un'entità HTTP text/xml o application/xml con un elemento radice 'multistatus'. Ulteriori elementi contengono codici di stato delle serie 200, 300, 400 e 500 generati durante l'invocazione del metodo. I codici di stato della serie 100 NON DOVREBBERO essere registrati in un elemento XML 'response'.

Sebbene '207' sia utilizzato come codice di stato di risposta complessivo, il destinatario deve consultare il contenuto del corpo della risposta multistatus per ulteriori informazioni sul successo o fallimento dell'esecuzione del metodo. La risposta PUÒ essere utilizzata in situazioni di successo, successo parziale e anche di fallimento.

L'elemento radice 'multistatus' contiene zero o più elementi 'response' in qualsiasi ordine, ciascuno con informazioni su una singola risorsa. Ogni elemento 'response' DEVE avere un elemento 'href' per identificare la risorsa.

Una risposta Multi-Status utilizza uno dei due formati distinti per rappresentare lo stato:

  1. Un elemento 'status' come figlio dell'elemento 'response' indica lo stato dell'esecuzione del messaggio per la risorsa identificata nel suo complesso (ad esempio, vedere la sezione 9.6.2). Alcune definizioni di metodi forniscono informazioni su codici di stato specifici che i client dovrebbero essere preparati a vedere in una risposta. Tuttavia, i client DEVONO essere in grado di gestire altri codici di stato, utilizzando le regole generiche definite nella sezione 10 di [RFC2616].

  2. Per PROPFIND e PROPPATCH, il formato è stato esteso utilizzando l'elemento 'propstat' invece di 'status', fornendo informazioni sulle singole proprietà di una risorsa. Questo formato è specifico per PROPFIND e PROPPATCH ed è descritto in dettaglio nelle sezioni 9.1 e 9.2.

13.1. Response Headers (Intestazioni di risposta)​

HTTP definisce l'intestazione Location per indicare un URL preferito per la risorsa che è stata indirizzata nel Request-URI (ad esempio, in risposta a richieste PUT riuscite o in risposte di reindirizzamento). Tuttavia, l'uso di questa intestazione crea ambiguità quando ci sono URL nel corpo della risposta, come con Multi-Status. Pertanto, l'uso dell'intestazione Location con la risposta Multi-Status è intenzionalmente indefinito.

13.2. Handling Redirected Child Resources (Gestione delle risorse figlie reindirizzate)​

Le risposte di reindirizzamento (300-303, 305 e 307) definite in HTTP 1.1 normalmente richiedono un'intestazione Location per indicare il nuovo URI per la singola risorsa reindirizzata dal Request-URI. Le risposte Multi-Status contengono molti indirizzi di risorse, ma la definizione originale in [RFC2518] non aveva alcun posto per il server per fornire il nuovo URI per le risorse reindirizzate. Questa specifica definisce un elemento 'location' per queste informazioni (vedere la sezione 14.9). I server DEVONO utilizzare questo nuovo elemento con le risposte di reindirizzamento in Multi-Status.

I client che incontrano risorse reindirizzate in Multi-Status NON DEVONO fare affidamento sulla presenza dell'elemento 'location' con un nuovo URI. Se l'elemento non è presente, il client PUÒ riemettere la richiesta alla singola risorsa reindirizzata, perché la risposta a quella richiesta può essere reindirizzata con un'intestazione Location contenente il nuovo URI.

13.3. Internal Status Codes (Codici di stato interni)​

Le sezioni 9.2.1, 9.1.2, 9.6.1, 9.8.3 e 9.9.2 definiscono vari codici di stato utilizzati nelle risposte Multi-Status. Questa specifica non definisce il significato di altri codici di stato che potrebbero apparire in queste risposte.

16. Precondition/Postcondition XML Elements (Elementi XML di precondizione/postcondizione)​

Come introdotto nella Sezione 8.7, informazioni aggiuntive sulle condizioni di errore possono essere incluse nel corpo di molte risposte di stato. Questa sezione formula requisiti sull'uso del meccanismo del corpo di errore e introduce un numero di codici di precondizione e postcondizione.

Una "precondizione" di un metodo descrive lo stato del server che deve essere vero affinché quel metodo possa essere eseguito. Una "postcondizione" di un metodo descrive lo stato del server che deve essere vero dopo che quel metodo è stato completato.

Ogni precondizione e postcondizione ha un elemento XML unico associato ad essa. In una risposta 207 Multi-Status, l'elemento XML DEVE apparire all'interno di un elemento 'error' nell'elemento 'propstat o 'response' appropriato a seconda che la condizione si applichi a una o più proprietà o alla risorsa nel suo complesso. In tutte le altre risposte di errore in cui viene utilizzato il corpo 'error' di questa specifica, l'elemento XML di precondizione/postcondizione DEVE essere restituito come figlio di un elemento 'error' di livello superiore nel corpo della risposta, salvo diversa negoziazione da parte della richiesta, insieme a uno stato di risposta appropriato. I codici di stato di risposta più comuni sono 403 (Forbidden) se la richiesta non deve essere ripetuta perché fallirà sempre, e 409 (Conflict) se si prevede che l'utente possa essere in grado di risolvere il conflitto e ripresentare la richiesta. L'elemento 'error' PUÒ contenere elementi figlio con informazioni di errore specifiche e PUÒ essere esteso con qualsiasi elemento figlio personalizzato.

Questo meccanismo non sostituisce l'uso di un codice di stato numerico corretto come definito qui o in HTTP, perché il client deve sempre essere in grado di intraprendere una linea d'azione ragionevole basata solo sul codice numerico. Tuttavia, elimina la necessità di definire nuovi codici numerici. I nuovi codici leggibili dalla macchina utilizzati per questo scopo sono elementi XML classificati come precondizioni e postcondizioni, quindi naturalmente qualsiasi gruppo che definisce un nuovo codice di condizione può utilizzare il proprio namespace. Come sempre, il namespace "DAV:" è riservato all'uso da parte dei gruppi di lavoro WebDAV autorizzati dall'IETF.

Un server che supporta questa specifica DOVREBBE utilizzare l'errore XML ogni volta che viene violata una precondizione o postcondizione definita in questo documento. Per condizioni di errore non specificate in questo documento, il server PUÒ semplicemente scegliere uno stato numerico appropriato e lasciare vuoto il corpo della risposta. Tuttavia, un server PUÒ invece utilizzare un codice di condizione personalizzato e altro testo di supporto, perché anche quando i client non riconoscono automaticamente i codici di condizione, possono essere molto utili nei test di interoperabilità e nel debug.

Esempio - Risposta con codice di precondizione:

HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:error xmlns:D="DAV:">
  &lt;D:lock-token-submitted>
    &lt;D:href>/workspace/webdav/&lt;D:href>
  &lt;D:lock-token-submitted>
&lt;D:error>

In questo esempio, un client inconsapevole di un blocco di profondità infinita sulla collezione padre "/workspace/webdav/" ha tentato di modificare il membro della collezione "/workspace/webdav/proposal.doc".

Altre precondizioni e postcondizioni utili sono state definite in altre specifiche che estendono WebDAV, come [RFC3744] (vedere in particolare la Sezione 7.1.1), [RFC3253] e [RFC3648].

Tutti questi elementi sono nello spazio dei nomi "DAV:". Se non specificato diversamente, il contenuto dell'elemento XML di ciascuna condizione è definito come vuoto.

lock-token-matches-request-uri​

Nome (Name): lock-token-matches-request-uri

Utilizzare con (Use with): 409 Conflict

Scopo (Purpose): (precondizione) -- Una richiesta può includere un'intestazione Lock-Token per identificare un blocco per il metodo UNLOCK. Tuttavia, se il Request-URI non rientra nell'ambito del blocco identificato dal token, il server DOVREBBE utilizzare questo errore. Il blocco può avere un ambito che non include il Request-URI, o il blocco potrebbe essere scomparso, o il token potrebbe essere non valido.

lock-token-submitted​

Nome (Name): lock-token-submitted (precondizione)

Utilizzare con (Use with): 423 Locked

Scopo (Purpose): La richiesta non ha potuto avere successo perché avrebbe dovuto essere inviato un token di blocco. Questo elemento, se presente, DEVE contenere almeno un URL di una risorsa bloccata che ha impedito la richiesta. Nei casi di MOVE, COPY e DELETE in cui sono coinvolti blocchi di collezione, può essere difficile per il client scoprire quale risorsa bloccata ha fatto fallire la richiesta -- ma il server è responsabile solo di restituire una tale risorsa bloccata. Il server PUÒ restituire ogni risorsa bloccata che ha impedito il successo della richiesta se le conosce tutte.

&lt;!ELEMENT lock-token-submitted (href+) >

no-conflicting-lock​

Nome (Name): no-conflicting-lock (precondizione)

Utilizzare con (Use with): Tipicamente 423 Locked

Scopo (Purpose): Una richiesta LOCK è fallita a causa della presenza di un blocco conflittuale già esistente. Si noti che un blocco può essere in conflitto anche se la risorsa a cui è stata diretta la richiesta è solo indirettamente bloccata. In questo caso, il codice di precondizione può essere utilizzato per informare il client sulla risorsa che è la radice del blocco conflittuale, evitando una ricerca separata della proprietà "lockdiscovery".

&lt;!ELEMENT no-conflicting-lock (href)* >

no-external-entities​

Nome (Name): no-external-entities

Utilizzare con (Use with): 403 Forbidden

Scopo (Purpose): (precondizione) -- Se il server rifiuta una richiesta del client perché il corpo della richiesta contiene un'entità esterna, il server DOVREBBE utilizzare questo errore.

preserved-live-properties​

Nome (Name): preserved-live-properties

Utilizzare con (Use with): 409 Conflict

Scopo (Purpose): (postcondizione) -- Il server ha ricevuto una richiesta MOVE o COPY altrimenti valida, ma non può mantenere le proprietà live con lo stesso comportamento alla destinazione. Potrebbe essere che il server supporti solo alcune proprietà live in alcune parti del repository, o semplicemente abbia un errore interno.

propfind-finite-depth​

Nome (Name): propfind-finite-depth

Utilizzare con (Use with): 403 Forbidden

Scopo (Purpose): (precondizione) -- Questo server non consente richieste PROPFIND di profondità infinita sulle collezioni.

cannot-modify-protected-property​

Nome (Name): cannot-modify-protected-property

Utilizzare con (Use with): 403 Forbidden

Scopo (Purpose): (precondizione) -- Il client ha tentato di impostare una proprietà protetta in un PROPPATCH (come DAV:getetag). Vedere anche [RFC3253], Sezione 3.12.

17. XML Extensibility in DAV (Estensibilità XML in DAV)​

L'estensione dello spazio dei nomi XML ([REC-XML-NAMES]) viene utilizzata in questa specifica per consentire l'aggiunta di nuovi elementi XML senza timore di collisioni con altri nomi di elementi. Sebbene i corpi delle richieste e delle risposte WebDAV possano essere estesi da elementi XML arbitrari, che possono essere ignorati dal destinatario del messaggio, un elemento XML nello spazio dei nomi "DAV:" NON DOVREBBE essere utilizzato nel corpo della richiesta o della risposta a meno che tale elemento XML non sia esplicitamente definito in un RFC IETF rivisto da un gruppo di lavoro WebDAV.

Affinché WebDAV sia sia estensibile che retrocompatibile, sia i client che i server devono sapere come comportarsi quando vengono ricevute estensioni di comando inattese o non riconosciute. Per l'elaborazione XML, ciò significa che i client e i server DEVONO elaborare i documenti XML ricevuti come se elementi e attributi inattesi (e tutti i figli di elementi non riconosciuti) non fossero presenti. Un elemento o attributo inatteso include uno che può essere utilizzato in un altro contesto ma non è previsto qui. Ignorare tali elementi ai fini dell'elaborazione può naturalmente essere coerente con la registrazione di tutte le informazioni o la presentazione per il debug.

Questa restrizione si applica anche all'elaborazione, da parte dei client, dei valori delle proprietà DAV dove gli elementi XML inattesi DOVREBBERO essere ignorati a meno che lo schema della proprietà non dichiari altrimenti.

Questa restrizione non si applica all'impostazione di proprietà DAV morte sul server dove il server DEVE registrare tutti gli elementi XML.

Inoltre, questa restrizione non si applica all'uso di XML dove XML capita di essere il tipo di contenuto del corpo dell'entità, ad esempio, quando viene utilizzato come corpo di un PUT.

Le istruzioni di elaborazione in XML DOVREBBERO essere ignorate dai destinatari. Pertanto, le specifiche che estendono WebDAV NON DOVREBBERO utilizzare istruzioni di elaborazione per definire un comportamento normativo.

I frammenti DTD XML sono inclusi per tutti gli elementi XML definiti in questa specifica. Tuttavia, l'XML corretto non sarà valido secondo alcuna DTD a causa dell'uso dello spazio dei nomi e delle regole di estensione. In particolare:

  • Gli elementi (di questa specifica) sono nello spazio dei nomi "DAV:",
  • L'ordine degli elementi è irrilevante salvo diversa indicazione,
  • Gli attributi di estensione POSSONO essere aggiunti,
  • Per le definizioni di tipo di elemento "ANY", la definizione di testo normativo per quell'elemento definisce cosa può esserci dentro e cosa significa.
  • Per le definizioni di tipo di elemento "#PCDATA", gli elementi di estensione NON DEVONO essere aggiunti.
  • Per altre definizioni di tipo di elemento, incluso "EMPTY", gli elementi di estensione POSSONO essere aggiunti.

Si noti che ciò significa che gli elementi contenenti elementi non possono essere estesi per contenere testo, e viceversa.

Con la convalida DTD rilassata dalle regole sopra, i vincoli descritti dai frammenti DTD sono normativi (vedere ad esempio l'Appendice A). Un destinatario di un messaggio WebDAV con un corpo XML NON DEVE convalidare il documento XML secondo alcuna DTD codificata o dichiarata dinamicamente.

Si noti che questa sezione descrive regole di estensibilità retrocompatibili. Potrebbero esserci anche momenti in cui un'estensione è progettata per non essere retrocompatibile, ad esempio, definendo un'estensione che riutilizza un elemento XML definito in questo documento ma omette uno degli elementi figlio richiesti dalle DTD in questa specifica.

18. DAV Compliance Classes (Classi di conformità DAV)​

Una risorsa conforme a DAV può pubblicizzare diverse classi di conformità. Un client può scoprire le classi di conformità di una risorsa eseguendo OPTIONS sulla risorsa ed esaminando l'intestazione "DAV" che viene restituita. Si noti in particolare che sono le risorse, piuttosto che i server, di cui si parla come conformi. Questo perché teoricamente alcune risorse su un server potrebbero supportare diversi set di funzionalità. Ad esempio, un server potrebbe avere un sub-repository dove è supportata una funzionalità avanzata come il versioning, anche se tale funzionalità non è supportata su tutti i sub-repository.

Poiché questo documento descrive estensioni al protocollo HTTP/1.1, minimamente tutte le risorse, i client e i proxy conformi a DAV DEVONO essere conformi a [RFC2616].

Una risorsa conforme alla classe 2 o alla classe 3 deve essere anche conforme alla classe 1.

18.1. Class 1 (Classe 1)​

Una risorsa conforme alla classe 1 DEVE soddisfare tutti i requisiti "DEVE" in tutte le sezioni di questo documento.

Le risorse conformi alla classe 1 DEVONO restituire, come minimo, il valore "1" nell'intestazione DAV su tutte le risposte al metodo OPTIONS.

18.2. Class 2 (Classe 2)​

Una risorsa conforme alla classe 2 DEVE soddisfare tutti i requisiti della classe 1 e supportare il metodo LOCK, la proprietà DAV:supportedlock, la proprietà DAV:lockdiscovery, l'intestazione di risposta Time-Out e l'intestazione di richiesta Lock-Token. Una risorsa conforme alla classe 2 DOVREBBE anche supportare l'intestazione di richiesta Timeout e l'elemento XML 'owner'.

Le risorse conformi alla classe 2 DEVONO restituire, come minimo, i valori "1" e "2" nell'intestazione DAV su tutte le risposte al metodo OPTIONS.

18.3. Class 3 (Classe 3)​

Una risorsa può esplicitamente pubblicizzare il suo supporto per le revisioni a [RFC2518] effettuate in questo documento. La classe 1 DEVE essere supportata anche. La classe 2 PUÒ essere supportata. Pubblicizzare il supporto della classe 3 in aggiunta alle classi 1 e 2 significa che il server supporta tutti i requisiti in questa specifica. Pubblicizzare il supporto della classe 3 e della classe 1, ma non della classe 2, significa che il server supporta tutti i requisiti in questa specifica tranne possibilmente quelli che coinvolgono il supporto del blocco.

Esempio:

DAV: 1, 3

19. Internationalization Considerations (Considerazioni sull'internazionalizzazione)​

Nell'ambito dell'internazionalizzazione, questa specifica è conforme alla politica del set di caratteri IETF [RFC2277]. In questa specifica, i campi leggibili dall'uomo possono essere trovati nel valore di una proprietà o in un messaggio di errore restituito nel corpo dell'entità di risposta. In entrambi i casi, il contenuto leggibile dall'uomo è codificato utilizzando XML, che ha disposizioni esplicite per la codifica e il tagging del set di caratteri e richiede che i processori XML leggano elementi XML codificati, come minimo, utilizzando le codifiche UTF-8 [RFC3629] e UTF-16 [RFC2781] del piano multilingue ISO 10646. Gli esempi XML in questa specifica dimostrano l'uso del parametro charset dell'intestazione Content-Type (definito in [RFC3023]), così come le dichiarazioni di charset XML.

XML fornisce anche una capacità di tagging della lingua per specificare la lingua del contenuto di un particolare elemento XML. L'attributo "xml:lang" appare su un elemento XML per identificare la lingua del suo contenuto e dei suoi attributi. Vedere [REC-XML] per le definizioni dei valori e dell'ambito.

Le applicazioni WebDAV DEVONO supportare il tagging del set di caratteri, la codifica del set di caratteri e la funzionalità di tagging della lingua della specifica XML. Gli implementatori di applicazioni WebDAV sono fortemente incoraggiati a leggere "XML Media Types" [RFC3023] per istruzioni su quale tipo di media MIME utilizzare per il trasporto XML e sull'uso del parametro charset dell'intestazione Content-Type.

I nomi utilizzati all'interno di questa specifica rientrano in quattro categorie: nomi di elementi di protocollo come metodi e intestazioni, nomi di elementi XML, nomi di proprietà e nomi di condizioni. La denominazione degli elementi di protocollo segue il precedente di HTTP, utilizzando nomi inglesi codificati in US-ASCII per metodi e intestazioni. Poiché questi elementi di protocollo non sono visibili agli utenti e sono semplicemente lunghi identificatori di token, non hanno bisogno di supportare più lingue. Allo stesso modo, i nomi degli elementi XML utilizzati in questa specifica non sono visibili all'utente e quindi non hanno bisogno di supportare più lingue.

I nomi delle proprietà WebDAV sono nomi XML qualificati (coppie di nome dello spazio dei nomi XML e nome locale). Sebbene alcune applicazioni (ad esempio, un visualizzatore di proprietà generico) visualizzino i nomi delle proprietà direttamente ai loro utenti, ci si aspetta che l'applicazione tipica utilizzi un insieme fisso di proprietà e fornisca una mappatura dal nome della proprietà e dallo spazio dei nomi a un campo leggibile dall'uomo quando visualizza il nome della proprietà a un utente. È solo nel caso in cui l'insieme delle proprietà non sia noto in anticipo che un'applicazione deve visualizzare un nome di proprietà a un utente. Raccomandiamo che le applicazioni forniscano nomi di proprietà leggibili dall'uomo ovunque sia possibile.

Per la segnalazione degli errori, seguiamo la convenzione dei codici di stato HTTP/1.1, includendo con ogni codice di stato una breve descrizione in inglese del codice (ad esempio, 423 (Locked)). Sebbene esista la possibilità che un user agent mal progettato visualizzi questo messaggio a un utente, le applicazioni internazionalizzate ignoreranno questo messaggio e visualizzeranno un messaggio appropriato nella lingua e nel set di caratteri dell'utente.

Poiché l'interoperazione di client e server non richiede informazioni sulle impostazioni locali, questa specifica non specifica alcun meccanismo per la trasmissione di queste informazioni.

20. Security Considerations (Considerazioni sulla sicurezza)​

Questa sezione è fornita per dettagliare le questioni riguardanti le implicazioni sulla sicurezza di cui le applicazioni WebDAV devono essere consapevoli.

Tutte le considerazioni sulla sicurezza di HTTP/1.1 (discusse in [RFC2616]) e XML (discusse in [RFC3023]) si applicano anche a WebDAV. Inoltre, i rischi per la sicurezza inerenti all'authoring remoto richiedono una tecnologia di autenticazione più forte, introducono diverse nuove preoccupazioni sulla privacy e possono aumentare i pericoli derivanti da un design del server inadeguato. Questi problemi sono dettagliati di seguito.

20.1. Authentication of Clients (Autenticazione dei client)​

A causa della loro enfasi sull'authoring, i server WebDAV devono utilizzare la tecnologia di autenticazione per proteggere non solo l'accesso a una risorsa di rete, ma anche l'integrità della risorsa. Inoltre, l'introduzione della funzionalità di blocco richiede il supporto per l'autenticazione.

Una password inviata in chiaro su un canale non sicuro è un mezzo inadeguato per proteggere l'accessibilità e l'integrità di una risorsa poiché la password può essere intercettata. Poiché l'autenticazione di base per HTTP/1.1 esegue essenzialmente la trasmissione in testo chiaro di una password, l'autenticazione di base NON DEVE essere utilizzata per autenticare un client WebDAV su un server a meno che la connessione non sia sicura. Inoltre, un server WebDAV NON DEVE inviare una sfida di autenticazione di base in un'intestazione WWW-Authenticate a meno che la connessione non sia sicura. Un esempio di connessione sicura sarebbe una connessione Transport Layer Security (TLS) che impiega una suite di cifratura forte e l'autenticazione del server.

Le applicazioni WebDAV DEVONO supportare lo schema di autenticazione Digest [RFC2617]. Poiché l'autenticazione Digest verifica che entrambe le parti di una comunicazione conoscano un segreto condiviso, una password, senza dover inviare quel segreto in chiaro, l'autenticazione Digest evita i problemi di sicurezza inerenti all'autenticazione di base fornendo al contempo un livello di autenticazione utile in un'ampia gamma di scenari.

20.2. Denial of Service (Negazione del servizio)​

Gli attacchi denial-of-service sono di particolare preoccupazione per i server WebDAV. WebDAV più HTTP consente attacchi denial-of-service su ogni parte delle risorse di un sistema.

  • Lo storage sottostante può essere attaccato effettuando PUT di file estremamente grandi.
  • Richiedere operazioni ricorsive su grandi collezioni può attaccare il tempo di elaborazione.
  • Effettuare più richieste pipeline su più connessioni può attaccare le connessioni di rete.

I server WebDAV devono essere consapevoli della possibilità di un attacco denial-of-service a tutti i livelli. La risposta appropriata a un tale attacco PUÒ essere semplicemente interrompere la connessione. Oppure, se il server è in grado di fornire una risposta, il server PUÒ utilizzare una richiesta di stato di livello 400 come 400 (Bad Request) e indicare perché la richiesta è stata rifiutata (una risposta di stato di livello 500 indicherebbe che il problema è con il server, mentre gli attacchi DoS involontari sono qualcosa che il client è in grado di rimediare).

20.3. Security through Obscurity (Sicurezza attraverso l'oscurità)​

WebDAV fornisce, attraverso il metodo PROPFIND, un meccanismo per elencare le risorse membro di una collezione. Questo riduce notevolmente l'efficacia delle tecniche di sicurezza o privacy che si basano solo sulla difficoltà di scoprire i nomi delle risorse di rete. Gli utenti dei server WebDAV sono incoraggiati a utilizzare tecniche di controllo degli accessi per prevenire l'accesso indesiderato alle risorse, piuttosto che dipendere dalla relativa oscurità dei loro nomi di risorsa.

20.4. Privacy Issues Connected to Locks (Problemi di privacy connessi ai blocchi)​

Quando si invia una richiesta di blocco, un user agent può anche inviare un campo XML 'owner' fornendo informazioni di contatto per la persona che acquisisce il blocco (per quei casi in cui una persona, piuttosto che un robot, sta acquisendo il blocco). Queste informazioni di contatto sono memorizzate in una proprietà DAV:lockdiscovery sulla risorsa e possono essere utilizzate da altri collaboratori per iniziare la negoziazione sull'accesso alla risorsa. Tuttavia, in molti casi, queste informazioni di contatto possono essere molto private e non dovrebbero essere ampiamente diffuse. I server DOVREBBERO limitare l'accesso in lettura alla proprietà DAV:lockdiscovery in modo appropriato. Inoltre, gli user agent DOVREBBERO fornire il controllo su se le informazioni di contatto vengano inviate o meno, e se le informazioni di contatto vengono inviate, il controllo su esattamente quali informazioni vengono inviate.

20.5. Privacy Issues Connected to Properties (Problemi di privacy connessi alle proprietà)​

Poiché i valori delle proprietà vengono tipicamente utilizzati per contenere informazioni come l'autore di un documento, esiste la possibilità che possano sorgere preoccupazioni sulla privacy derivanti dall'accesso diffuso ai dati delle proprietà di una risorsa. Per ridurre il rischio di divulgazione involontaria di informazioni private tramite le proprietà, i server sono incoraggiati a sviluppare meccanismi di controllo degli accessi che separino l'accesso in lettura al corpo della risorsa e l'accesso in lettura alle proprietà della risorsa. Questo consente a un utente di controllare la diffusione dei propri dati delle proprietà senza limitare eccessivamente l'accesso ai contenuti della risorsa.

20.6. Implications of XML Entities (Implicazioni delle entità XML)​

XML supporta una funzionalità nota come "entità esterne", definita nella Sezione 4.2.2 di [REC-XML], che istruisce un processore XML a recuperare e includere XML aggiuntivo. Un'entità XML esterna può essere utilizzata per aggiungere o modificare la dichiarazione del tipo di documento (DTD) associata a un documento XML. Un'entità XML esterna può anche essere utilizzata per includere XML all'interno del contenuto di un documento XML. Per XML non validante, come l'XML utilizzato in questa specifica, includere un'entità XML esterna non è richiesto da XML. Tuttavia, XML afferma che un processore XML può, a sua discrezione, includere l'entità XML esterna.

Le entità XML esterne non hanno alcuna affidabilità intrinseca e sono soggette a tutti gli attacchi endemici a qualsiasi richiesta HTTP GET. Inoltre, è possibile per un'entità XML esterna modificare la DTD e quindi influenzare la forma finale di un documento XML, nel peggiore dei casi, modificando significativamente la sua semantica o esponendo il processore XML ai rischi di sicurezza discussi in [RFC3023]. Pertanto, gli implementatori devono essere consapevoli che le entità XML esterne dovrebbero essere trattate come non affidabili. Se un server sceglie di non gestire le entità XML esterne, DOVREBBE rispondere alle richieste contenenti entità esterne con il codice di condizione 'no-external-entities'.

Esiste anche il rischio di scalabilità che accompagnerebbe un'applicazione ampiamente distribuita che facesse uso di entità XML esterne. In questa situazione, è possibile che ci siano numeri significativi di richieste per un'entità XML esterna, potenzialmente sovraccaricando qualsiasi server che gestisce richieste per la risorsa contenente l'entità XML esterna.

Inoltre, esiste anche un rischio basato sulla valutazione delle "entità interne" come definito nella Sezione 4.2.2 di [REC-XML]. Una piccola richiesta accuratamente elaborata utilizzando entità interne annidate può richiedere enormi quantità di memoria e/o tempo di elaborazione per essere elaborata. Gli implementatori di server dovrebbero essere consapevoli di questo rischio e configurare i loro parser XML in modo che richieste come queste possano essere rilevate e rifiutate il prima possibile.

20.7. Risks Connected with Lock Tokens (Rischi connessi ai token di blocco)​

Questa specifica incoraggia l'uso di "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) per i token di blocco (Sezione 6.5), al fine di garantire la loro unicità nello spazio e nel tempo. Gli UUID versione 1 (definiti nella Sezione 4) POSSONO contenere un campo "node" che "consiste di un indirizzo MAC IEEE 802, solitamente l'indirizzo dell'host. Per i sistemi con più indirizzi IEEE, può essere utilizzato qualsiasi indirizzo disponibile". Poiché un server WebDAV emetterà molti blocchi durante la sua vita, l'implicazione è che potrebbe anche esporre pubblicamente il suo indirizzo IEEE 802.

Esistono diversi rischi associati all'esposizione degli indirizzi IEEE 802. Utilizzando l'indirizzo IEEE 802:

  • È possibile tracciare il movimento dell'hardware da una subnet all'altra.
  • Potrebbe essere possibile identificare il produttore dell'hardware che esegue un server WebDAV.
  • Potrebbe essere possibile determinare il numero di ogni tipo di computer che esegue WebDAV.

Questo rischio si applica solo alle versioni UUID basate sull'indirizzo dell'host. La Sezione 4 di [RFC4122] descrive diversi altri meccanismi per generare UUID che non coinvolgono l'indirizzo dell'host e quindi non soffrono di questo rischio.

20.8. Hosting Malicious Content (Hosting di contenuti dannosi)​

HTTP ha la capacità di ospitare programmi che vengono eseguiti su macchine client. Questi programmi possono assumere molte forme tra cui script Web, eseguibili, moduli plug-in e macro nei documenti. WebDAV non cambia nessuna delle preoccupazioni sulla sicurezza relative a questi programmi, tuttavia WebDAV è spesso utilizzato in contesti in cui un'ampia gamma di utenti può pubblicare documenti su un server. Il server potrebbe non avere una stretta relazione di fiducia con l'autore che sta pubblicando il documento. I server che consentono ai client di pubblicare contenuti arbitrari possono utilmente implementare precauzioni per verificare che i contenuti pubblicati sul server non siano dannosi per altri client. I server potrebbero farlo con tecniche come la limitazione dei tipi di contenuto che possono essere pubblicati e l'esecuzione di software di rilevamento di virus e malware sui contenuti pubblicati. I server possono anche mitigare il rischio avendo appropriate restrizioni di accesso e autenticazione degli utenti che sono autorizzati a pubblicare contenuti sul server.

21. IANA Considerations (Considerazioni IANA)​

21.1. New URI Schemes (Nuovi schemi URI)​

Questa specifica definisce due schemi URI:

  1. lo schema "opaquelocktoken" definito nell'Appendice C, e

  2. lo schema URI "DAV", che storicamente è stato utilizzato in [RFC2518] per disambiguare i nomi delle proprietà WebDAV e i nomi degli elementi XML e che continua ad essere utilizzato per tale scopo in questa specifica e in altre che estendono WebDAV. La creazione di identificatori nello spazio dei nomi "DAV:" è controllata dall'IETF.

Si noti che la definizione di nuovi schemi URI per gli spazi dei nomi XML è ora sconsigliata. "DAV:" è stato definito prima che emergessero le migliori pratiche standard.

21.2. XML Namespaces (Spazi dei nomi XML)​

Gli spazi dei nomi XML disambiguano i nomi delle proprietà WebDAV e gli elementi XML. Qualsiasi utente o applicazione WebDAV può definire un nuovo spazio dei nomi per creare proprietà personalizzate o estendere la sintassi XML di WebDAV. IANA non ha bisogno di gestire tali spazi dei nomi, nomi di proprietà o nomi di elementi.

21.3. Message Header Fields (Campi dell'intestazione del messaggio)​

I campi dell'intestazione del messaggio seguenti dovrebbero essere aggiunti al registro permanente (vedere [RFC3864]).

21.3.1. DAV​

Header field name (Nome del campo dell'intestazione): DAV

Applicable protocol (Protocollo applicabile): http

Status (Stato): standard

Author/Change controller (Autore/Controllore delle modifiche): IETF

Specification document (Documento di specifica): this specification (Section 10.1)

21.3.2. Depth​

Header field name (Nome del campo dell'intestazione): Depth

Applicable protocol (Protocollo applicabile): http

Status (Stato): standard

Author/Change controller (Autore/Controllore delle modifiche): IETF

Specification document (Documento di specifica): this specification (Section 10.2)

21.3.3. Destination​

Header field name (Nome del campo dell'intestazione): Destination

Applicable protocol (Protocollo applicabile): http

Status (Stato): standard

Author/Change controller (Autore/Controllore delle modifiche): IETF

Specification document (Documento di specifica): this specification (Section 10.3)

21.3.4. If​

Header field name (Nome del campo dell'intestazione): If

Applicable protocol (Protocollo applicabile): http

Status (Stato): standard

Author/Change controller (Autore/Controllore delle modifiche): IETF

Specification document (Documento di specifica): this specification (Section 10.4)

21.3.5. Lock-Token​

Header field name (Nome del campo dell'intestazione): Lock-Token

Applicable protocol (Protocollo applicabile): http

Status (Stato): standard

Author/Change controller (Autore/Controllore delle modifiche): IETF

Specification document (Documento di specifica): this specification (Section 10.5)

21.3.6. Overwrite​

Header field name (Nome del campo dell'intestazione): Overwrite

Applicable protocol (Protocollo applicabile): http

Status (Stato): standard

Author/Change controller (Autore/Controllore delle modifiche): IETF

Specification document (Documento di specifica): this specification (Section 10.6)

21.3.7. Timeout​

Header field name (Nome del campo dell'intestazione): Timeout

Applicable protocol (Protocollo applicabile): http

Status (Stato): standard

Author/Change controller (Autore/Controllore delle modifiche): IETF

Specification document (Documento di specifica): this specification (Section 10.7)

21.4. HTTP Status Codes (Codici di stato HTTP)​

Questa specifica definisce i codici di stato HTTP

  • 207 Multi-Status (Section 11.1)
  • 422 Unprocessable Entity (Section 11.2),
  • 423 Locked (Section 11.3),
  • 424 Failed Dependency (Section 11.4) e
  • 507 Insufficient Storage (Section 11.5),

da aggiornare nel registro su http://www.iana.org/assignments/http-status-codes.

Nota: il codice di stato HTTP 102 (Processing) è stato rimosso in questa specifica; la sua registrazione IANA dovrebbe continuare a fare riferimento a RFC 2518.

22. Acknowledgements (Ringraziamenti)​

Una specifica come questa prospera grazie a una revisione critica penetrante e appassisce a causa di una negligenza apatica. Gli autori riconoscono con gratitudine i contributi delle seguenti persone, le cui intuizioni sono state così preziose in ogni fase del nostro lavoro.

Contributori a RFC 2518​

Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse e Lauren Wood.

Due di questo elenco meritano una menzione speciale. I contributi di Larry Masinter sono stati inestimabili; ha sia aiutato la formazione del gruppo di lavoro sia pazientemente guidato gli autori lungo il percorso. In tanti modi ha stabilito alti standard che abbiamo lavorato duramente per raggiungere. Anche i contributi di Judith Slein sono stati inestimabili; chiarendo i requisiti e rivedendo pazientemente versione dopo versione, ha sia migliorato questa specifica sia ampliato le nostre menti sulla gestione dei documenti.

Vorremmo anche ringraziare John Turner per aver sviluppato la DTD XML.

Gli autori di RFC 2518 erano Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter e D. Jensen. Sebbene i loro nomi abbiano dovuto essere rimossi a causa delle restrizioni sul conteggio degli autori dell'IETF, possono prendersi il merito per la maggior parte del design di WebDAV.

Ringraziamenti aggiuntivi per questa specifica​

I contributori significativi di testo per questa specifica sono elencati come contributori nella sezione seguente. Dobbiamo anche riconoscere con gratitudine Geoff Clemm, Joel Soderberg e Dan Brotsky per aver elaborato testo specifico sulla lista o nelle riunioni. Joe Hildebrand e Cullen Jennings hanno aiutato a risolvere molti problemi. Barry Lind ha descritto una considerazione di sicurezza aggiuntiva e Cullen Jennings ha fornito il testo per quella considerazione. Jason Crawford ha monitorato lo stato dei problemi per questo documento per un periodo di anni, seguito da Elias Sinderson.

Appendice A. Notes on Processing XML Elements (Note sull'elaborazione degli elementi XML)​

A.1. Notes on Empty XML Elements (Note sugli elementi XML vuoti)​

XML supporta due meccanismi per indicare che un elemento XML non ha alcun contenuto. Il primo è dichiarare un elemento XML della forma &lt;A>&lt;/A>. Il secondo è dichiarare un elemento XML della forma &lt;A/>. I due elementi XML sono semanticamente identici.

A.2. Notes on Illegal XML Processing (Note sull'elaborazione XML illegale)​

XML è un formato di dati flessibile che rende facile inviare dati che appaiono legali ma in realtà non lo sono. La filosofia "Sii flessibile in ciò che accetti e rigoroso in ciò che invii" si applica ancora, ma non deve essere applicata in modo inappropriato. XML è estremamente flessibile nel gestire questioni di spazi bianchi, ordinamento degli elementi, inserimento di nuovi elementi, ecc. Questa flessibilità non richiede estensioni, soprattutto non nell'area del significato degli elementi.

Non c'è gentilezza nell'accettare combinazioni illegali di elementi XML. Nel migliore dei casi, causerà un risultato indesiderato e nel peggiore dei casi può causare danni reali.

A.3. Example - XML Syntax Error (Esempio - Errore di sintassi XML)​

Il seguente corpo della richiesta per un metodo PROPFIND è illegale.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:">
 &lt;D:allprop/>
 &lt;D:propname/>
&lt;D:propfind>

La definizione dell'elemento propfind consente solo l'elemento allprop o l'elemento propname, non entrambi. Pertanto, quanto sopra è un errore e deve ricevere una risposta 400 (Bad Request).

Immagina, tuttavia, che un server volesse essere "gentile" e decidesse di scegliere l'elemento allprop come elemento vero e rispondere ad esso. Un client in esecuzione su una linea con larghezza di banda limitata che intendeva eseguire un propname sarebbe molto sorpreso se il server trattasse il comando come un allprop.

Inoltre, se un server fosse indulgente e decidesse di rispondere a questa richiesta, i risultati varierebbero casualmente da server a server, con alcuni server che eseguono la direttiva allprop e altri che eseguono la direttiva propname. Questo riduce l'interoperabilità piuttosto che aumentarla.

A.4. Example - Unexpected XML Element (Esempio - Elemento XML inaspettato)​

L'esempio precedente era illegale perché conteneva due elementi che erano esplicitamente vietati dall'apparire insieme nell'elemento propfind. Tuttavia, XML è un linguaggio estensibile, quindi si possono immaginare nuovi elementi definiti per l'uso con propfind. Di seguito è riportato il corpo della richiesta di un PROPFIND e, come l'esempio precedente, deve essere rifiutato con un 400 (Bad Request) da un server che non comprende l'elemento expired-props.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
 &lt;E:expired-props/>
&lt;D:propfind>

Per capire perché viene restituito un 400 (Bad Request), esaminiamo il corpo della richiesta come lo vede il server non familiare con expired-props.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
&lt;D:propfind>

Poiché il server non comprende l'elemento 'expired-props', secondo le regole di elaborazione XML specifiche di WebDAV specificate nella Sezione 17, deve elaborare la richiesta come se l'elemento non fosse presente. Quindi, il server vede un propfind vuoto, che secondo la definizione dell'elemento propfind è illegale.

Si noti che se l'estensione fosse stata additiva, non avrebbe necessariamente portato a un 400 (Bad Request). Ad esempio, immagina il seguente corpo della richiesta per un PROPFIND:

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
 &lt;D:propname/>
 &lt;E:leave-out>*boss*&lt;E:leave-out>
&lt;D:propfind>

L'esempio precedente contiene l'elemento fittizio leave-out. Il suo scopo è impedire la restituzione di qualsiasi proprietà il cui nome corrisponda al pattern inviato. Se l'esempio precedente fosse inviato a un server non familiare con 'leave-out', l'unico risultato sarebbe che l'elemento 'leave-out' verrebbe ignorato e verrebbe eseguito un propname.

Appendice B. Notes on HTTP Client Compatibility (Note sulla compatibilità dei client HTTP)​

WebDAV è stato progettato per essere, ed è risultato essere, retrocompatibile con HTTP 1.1. I metodi PUT e DELETE sono definiti in HTTP e quindi possono essere utilizzati da client HTTP così come da client consapevoli di WebDAV, ma le risposte a PUT e DELETE sono state estese in questa specifica in modi per cui solo un client WebDAV sarebbe completamente preparato. Sono state sollevate alcune preoccupazioni teoriche sul fatto che tali risposte causino problemi di interoperabilità con client solo HTTP, e questa sezione affronta tali preoccupazioni.

Poiché qualsiasi client HTTP dovrebbe gestire i codici di stato di livello 400 e 500 non riconosciuti come errori, i seguenti nuovi codici di stato non dovrebbero presentare problemi: 422, 423 e 507 (424 è anche un nuovo codice di stato ma appare solo nel corpo di una risposta Multistatus.) Quindi, ad esempio, se un client HTTP tentasse di eseguire PUT o DELETE su una risorsa bloccata, la risposta 423 Locked dovrebbe risultare in un errore generico presentato all'utente.

La risposta 207 Multistatus è interessante perché un client HTTP che emette una richiesta DELETE a una collezione potrebbe interpretare una risposta 207 come un successo, anche se non si rende conto che la risorsa è una collezione e non può capire che l'operazione DELETE potrebbe essere stata un fallimento completo o parziale. Quell'interpretazione non è del tutto giustificata, perché una risposta di livello 200 indica che il server "ha ricevuto, compreso e accettato" la richiesta, non che la richiesta ha portato a un successo completo.

Un'opzione è che un server potrebbe trattare un DELETE di una collezione come un'operazione atomica e utilizzare 204 No Content in caso di successo, o qualche risposta di errore appropriata (livello 400 o 500) per un errore. Questo approccio massimizzerebbe infatti la retrocompatibilità. Tuttavia, poiché i test di interoperabilità e le discussioni del gruppo di lavoro non hanno rilevato alcuna istanza di client HTTP che emettono una richiesta DELETE contro una collezione WebDAV, questa preoccupazione è più teorica che pratica. Pertanto, i server probabilmente avranno completamente successo nell'interoperare con i client HTTP anche se trattano qualsiasi richiesta DELETE di collezione come una richiesta WebDAV e inviano una risposta 207 Multi-Status.

In generale, le implementazioni dei server sono incoraggiate a utilizzare le risposte dettagliate e altri meccanismi definiti in questo documento piuttosto che apportare modifiche per preoccupazioni di interoperabilità teoriche.

Appendice C. The 'opaquelocktoken' Scheme and URIs (Lo schema 'opaquelocktoken' e gli URI)​

Lo schema URI 'opaquelocktoken' è stato definito in [RFC2518] (e registrato da IANA) al fine di creare URI sintatticamente corretti e facili da generare da UUID, destinati ad essere utilizzati come token di blocco e ad essere unici tra tutte le risorse per tutti i tempi.

Un URI opaquelocktoken viene costruito concatenando lo schema 'opaquelocktoken' con un UUID, insieme a un'estensione opzionale. I server possono creare nuovi UUID per ogni nuovo token di blocco. Se un server desidera riutilizzare gli UUID, il server DEVE aggiungere un'estensione e l'algoritmo che genera l'estensione DEVE garantire che la stessa estensione non verrà mai utilizzata due volte con l'UUID associato.

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
  ; UUID è definito nella Sezione 3 di [RFC4122]. Si noti che LWS
  ; non è consentito tra gli elementi di
  ; questa produzione.

Extension = path
  ; path è definito nella Sezione 3.3 di [RFC3986]

Appendice D. Lock-null Resources (Risorse lock-null)​

Il modello WebDAV originale per il blocco di URL non mappati creava "risorse lock-null". Questo modello era troppo complicato e sono stati scoperti alcuni problemi di interoperabilità e implementazione. Il nuovo modello WebDAV per il blocco di URL non mappati (vedere Sezione 7.3) crea "risorse vuote bloccate". Le risorse lock-null sono deprecate. Questa sezione discute brevemente il modello originale perché i client DEVONO essere in grado di gestire entrambi i modelli.

Nel modello originale "risorsa lock-null", che non è più raccomandato per l'implementazione:

  • Una risorsa lock-null a volte appariva come "Not Found". Il server risponde con un 404 o 405 a qualsiasi metodo tranne PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.

  • Una risorsa lock-null tuttavia appare come membro della sua collezione genitore.

  • Il server rimuove completamente la risorsa lock-null (il suo URI diventa non mappato) se il suo blocco scompare prima che venga convertita in una risorsa regolare. Ricorda che i blocchi scompaiono non solo quando scadono o vengono sbloccati, ma vengono anche rimossi se una risorsa viene rinominata o spostata, o se qualsiasi collezione genitore viene rinominata o spostata.

  • Il server converte la risorsa lock-null in una risorsa regolare se una richiesta PUT all'URL ha successo.

  • Il server converte la risorsa lock-null in una collezione se una richiesta MKCOL all'URL ha successo (sebbene l'esperienza di interoperabilità abbia mostrato che non tutti i server hanno seguito questo requisito).

  • I valori delle proprietà erano definiti per le proprietà DAV:lockdiscovery e DAV:supportedlock ma non necessariamente per altre proprietà come DAV:getcontenttype.

I client possono facilmente interoperare sia con i server che supportano il vecchio modello "risorse lock-null" che con il modello raccomandato di "risorse vuote bloccate" tentando solo PUT dopo un LOCK a un URL non mappato, non MKCOL o GET.

D.1. Guidance for Clients Using LOCK to Create Resources (Guida per i client che utilizzano LOCK per creare risorse)​

Un client WebDAV implementato secondo questa specifica potrebbe trovare server che creano risorse lock-null (implementati prima di questa specifica utilizzando [RFC2518]) così come server che creano risorse vuote bloccate. La risposta alla richiesta LOCK non indicherà che tipo di risorsa è stata creata. Ci sono alcune tecniche che aiutano il client a gestire entrambi i tipi.

  • Se il client desidera evitare di creare accidentalmente risorse lock-null o vuote bloccate, un'intestazione "If-Match: *" può essere inclusa con le richieste LOCK per impedire al server di creare una nuova risorsa.

  • Se una richiesta LOCK crea una risorsa e il client successivamente vuole sovrascrivere quella risorsa utilizzando una richiesta COPY o MOVE, il client dovrebbe includere un'intestazione "Overwrite: T".

  • Se una richiesta LOCK crea una risorsa e il client decide quindi di liberarsi di quella risorsa, una richiesta DELETE dovrebbe fallire su una risorsa lock-null e dovrebbe essere utilizzato UNLOCK invece. Ma con una risorsa vuota bloccata, UNLOCK non fa scomparire la risorsa. Pertanto, il client potrebbe dover provare entrambe le richieste e ignorare un errore in una delle due richieste.

Appendice F. Summary of Changes from RFC 2518 (Riepilogo delle modifiche da RFC 2518)​

Questa appendice fornisce un riepilogo delle modifiche da RFC 2518.

F.1. Changes for Both Client and Server Implementations (Modifiche per le implementazioni client e server)​

Chiarimenti:

  • Aggiunto chiarimento su quali funzionalità HTTP devono essere supportate.
  • Aggiunto chiarimento su quando gli ETag devono essere restituiti.
  • Chiarito che la collezione radice non può mai essere eliminata.
  • Chiarito che i client devono essere in grado di gestire la risposta PROPFIND contenente proprietà in qualsiasi ordine.
  • Chiariti i requisiti per le richieste PROPFIND Depth infinity.
  • Aggiunto chiarimento sull'uso dell'intestazione di richiesta Timeout.
  • Aggiunto chiarimento sulla gestione dei valori temporali.

Chiarimenti di elaborazione:

  • Chiarito quando le intestazioni If di HTTP possono essere utilizzate al posto dell'intestazione If di WebDAV.
  • Chiarito che i client WebDAV devono essere in grado di gestire le risposte 401 quando interagiscono con un server WebDAV.

Guida migliorata:

  • Aggiunta guida sull'uso dell'intestazione DAV.
  • Aggiunta guida per la gestione delle intestazioni condizionali HTTP.
  • Aggiunta guida per la gestione della richiesta PROPFIND su collezioni con numero eccessivo di risorse.
  • Aggiunto esempio di risposta PROPFIND e chiariti i requisiti di formato.
  • Aggiunto esempio di richiesta COPY e chiarita la gestione dell'intestazione Overwrite.

Nuova funzionalità:

  • Il codice di stato 102 (Processing) è stato rimosso da questa specifica. Non è stato ampiamente implementato ed è stato spostato su RFC 2518.

F.2. Changes for Client Implementations (Modifiche per le implementazioni client)​

Nuova guida:

  • Aggiunta appendice sull'estensibilità XML.
  • Aggiunta appendice sull'autenticazione dei client.
  • Aggiunte considerazioni sulla sicurezza sulle implicazioni delle entità XML.

Modifiche di elaborazione:

  • I client non devono più fallire quando ricevono ordinamento non valido di elementi in una risposta.

F.3. Changes for Server Implementations (Modifiche per le implementazioni server)​

Risorse lock-null:

  • Le risorse lock-null supportate dal server sono state deprecate a favore delle risorse vuote bloccate.
  • I server possono ancora supportare le risorse lock-null per la compatibilità all'indietro.

Modifiche alle proprietà:

  • Modificate diverse definizioni di proprietà per renderle più coerenti e chiare.
  • Resa obbligatoria la proprietà DAV:getetag dove è richiesta DAV:getlastmodified.
  • Rimosso il requisito DAV:getcontenttype sulle collezioni.

Segnalazione errori:

  • Aggiunti elementi XML di precondizione/postcondizione per una migliore segnalazione degli errori nel corpo della risposta.
  • Aggiunta guida sull'uso delle precondizioni e postcondizioni.

Comportamento COPY/MOVE:

  • Chiarito il comportamento COPY/MOVE rispetto alle proprietà.
  • Chiarito il comportamento COPY/MOVE con i blocchi.
  • Chiarito il comportamento COPY/MOVE rispetto all'intestazione Depth.

Gestione dei blocchi:

  • Chiarito che il campo proprietario del blocco in una richiesta LOCK non è autenticato.
  • Chiarito quando i blocchi devono scadere e quando possono essere estesi.
  • Aggiunto chiarimento dell'elemento LockInfo.
  • Corretto lo schema DAV:supportedlock.

Altre modifiche server:

  • Chiarito quando i server devono utilizzare le risposte 404 vs 405.
  • Chiarito il comportamento DELETE della collezione e la segnalazione degli errori.
  • Chiariti i requisiti di transazione PROPPATCH.
  • Il metodo OPTIONS deve includere l'intestazione "DAV" nelle risposte.

F.4. Clarifications to XML Processing (Chiarimenti sull'elaborazione XML)​

Validazione:

  • Chiariti i livelli di requisito per l'elaborazione e la validazione XML.
  • Chiarito che le regole di elaborazione XML si applicano solo agli elementi definiti da WebDAV.
  • Aggiunta guida sulla gestione degli elementi XML sconosciuti.

Gestione namespace:

  • Chiarito l'uso del namespace nelle proprietà e negli elementi XML.
  • Chiarito che i nomi delle proprietà sono sempre qualificati.

Modifiche DTD:

  • Il DTD è stato rimosso dalla specifica. Non è mai stato normativo ed era talvolta errato o incompleto.

F.5. Clarifications to Protocol Details (Chiarimenti sui dettagli del protocollo)​

Chiarimenti sui codici di stato:

  • Chiarito quando ciascun codice di stato WebDAV deve o dovrebbe essere utilizzato.
  • Chiarita l'interazione dei codici di stato WebDAV con i codici di stato HTTP.

Chiarimenti sulle intestazioni:

  • Chiarito l'uso dell'intestazione Depth con vari metodi.
  • Chiarita la sintassi e l'elaborazione dell'intestazione If.
  • Chiarito l'uso dell'intestazione Overwrite.

Formato risposta:

  • Resi più chiari i requisiti per la formattazione della risposta Multi-Status.
  • Resa coerente la gestione di href in tutti gli usi.

Gestione errori:

  • Migliorata la gestione degli errori in tutta la specifica utilizzando elementi di precondizione/postcondizione.
  • Aggiunta guida specifica per la gestione dei fallimenti di autorizzazione.