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.