WebDAV

Technologie WebDAV se začala vyvíjet již v roce 1996, kdy Jim Whitehead spolupracoval s W3C na pořádání dvou setkání, jejichž cílem bylo rozebrání problematiky spolupráce při vytváření dokumentů prostřednictvím technologií World Wide Web.

Původní vize webu – tak, jak ji navrhl Tim Berners-Lee – totiž počítala s koncepcí platformy jak pro čtení tak i pro zápis. Časem se s rozvojem webu stala pro většinu uživatelů platforma spíše konzumní nežli tvůrčí a právě to chtěl Whitehead a jiní lidé, kteří smýšleli podobně, změnit. Dali tak základ myšlence standardizovaného vstupně-výstupního rozhraní webu. W3C rozhodlo, že nejlepší cestou, jak provést požadované změny, je zformování pracovní skupiny IETF, neboť myšlenky vedoucí k úpravám a rozšířením HTTP by měly být vedeny stejně, jako standardizace HTTP, která probíhala v rámci IETF.

Po započetí prací na rozšířeních HTTP se ovšem zjistilo, že řešení spolupráce při vytváření a úpravách obsahu a verzování bylo příliš náročné. Pracovní skupina WebDAV se tak soustředila pouze na první část problému a v roce 1999 vydala již standard RFC 2518 a až následně v roce 2002 rozšíření pro verzování s názvem Delta-V RFC 3253. Poslední verzí protokolu je RFC 4918 vydané v roce 2007.

Dotaz klienta s požadavkem na server je tvořen HTTP příkazem. Na stejném řádku je zdroj a použitá verze protokolu. Následují HTTP hlavičky Host, Content-Type a Content-Length, dále mohou být obsaženy také hlavičky rozšiřující specifikace WebDAV (např. Depth). K dotazu se v některých případech ještě přidává XML dokument, který pomáhá blíže specifikovat požadovanou akci. XML dokument se skládá z XML deklarace a stanovení kódování. V kořenovém elementu musí být definován jmenný prostor WebDAVu. Pokud jsou v dokumentu použity elementy specifikované v jiném jmenném prostoru, musí být tento prostor také definován. WebDAV server ovšem nekontroluje existenci speciálně definovaného DTD dokumentu, ani validitu elementů. Za kořenovým elementem následují ostatní elementy podle použitého HTTP příkazu. Následuje ukázka dotazu klienta na vlastnosti souboru:

PROPFIND /file HTTP/1.1
Host: www.example.com
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
  <propname/>
</D:propfind>

Odpověď WebDAV serveru je podobná standardní odpovědi HTTP. Skládá se z verze protokolu, stavového čísla, stavového hlášení a z typických hlaviček. XML dokument je většinou součástí odpovědi, obsahuje specifikaci XML dokumentu a kódování. Kořenový element obsahuje definici jmenného prostoru WebDAVu. Další elementy již záleží na dotazu a určité odpovědi. Dále je uveden příklad odpovědi na výše uvedený dotaz:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
  <response>
    <href> http://www.example.com/file%5B%5D>
    <propstat>
      <prop xmlns:R=" http://ns.example.com/ns/%5B%5D">
        <R:author/>
        <creationdate/>
        <displayname/>
        <resourcetype/>
        <supportedlock/>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>

Vlastnosti jsou data, která nám blíže popisují atributy zdrojů, poskytují efektivní správu a také filtrování (např.: při hledání všech souborů, které vytvořil určitý autor). Vlastnosti se skládají z jednoho či více párů, které jsou tvořeny názvem a hodnotou. Název určuje sémantiku vlastnosti a také odkazuje na příslušnou hodnotu, proto musí být unikátní. Standard WebDAV rozděluje vlastnosti do dvou typů:

• Live vlastnosti (např. velikost souboru), které mají danou sémantiku a syntaxi serverem. Jsou to vlastnosti chráněné a upravované na serveru nebo upravované klientem a serverem pouze kontrolované.
• Dead vlastnosti mají danou sémantiku i syntaxi klientem. Server pouze tuto vlastnost uchovává.

Na příkladu kódu lze vidět vlastnost, která představuje část XML struktury:

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

Vlastnost je zde určena jménem „author“ a jmenným prostorem definovaným pomocí dokumentu DTD „http://example.com/ns“%5B%5D, ve kterém jsou definované speciální elementy. Element zde představuje již zmíněný pár, který tvoří vlastnost.

Příklady standardně používaných vlastností:

• creationdate – Datum a čas, kdy byl zdroj vytvořen
• displayname – Jméno zdroje
• getcontentlanguage – Specifikace jazyka
• getcontentlength – Velikost zdroje v bytech
• getcontenttype – MIME typ zdroje
• getlastmodified – Datum a čas poslední úpravy
• lockdiscovery – Popis aktivních zámků
• resourcetype – Specifikace o jaký typ zdroje jde (např. kolekce)
• supportedlock – Výpis podporovaných zámků

Kolekce můžeme přirovnat k adresářům, které tvoří stromovou hierarchii. Působí jako kontejnery, které mohou obsahovat jiné kolekce, soubory, nebo vlastnosti. Hlavní rozdíl mezi kolekcemi a adresáři je, že se kolekce specifikují podle URI. To znamená, že prvky, které jsou v ní obsaženy, mohou být uloženy na různých místech souborového systému nebo na jiném fyzickém serveru.

Některé HTTP metody se vztahují pouze ke kolekcím a jiné ke všem zdrojům uvnitř kolekce. Abychom mohli definovat rozsah akce, používá se hlavička Depth. Hloubka může nabývat hodnoty 0 (akce je aplikována pouze na určitý zdroj), 1 (akce zahrnuje zdroj a všechny jeho přímé potomky) a nekonečno (akce je provedena nad zdrojem a všemi jeho potomky).

Zámky jsou důležitou vlastností při společné úpravě souborů. Poskytují mechanismus pro serializaci přístupu ke zdrojům. Použití zámku poskytuje klientovi záruku, že zdroj nebude během úprav někým pozměněn. Tím se předchází kolizím aktualizací.

Všechny WebDAV servery nemusí mít podporu zámku implementovanou. Existují dva typy serverů s implementací úplnou (s podporou zámků) nebo jednoduchou (bez podpory zámků). Pro zjištění podpory zámků slouží vlastnost DAV:supportedlock.

Specifikace WebDAV definuje dva typy zámků: individuální (Exclusive) a sdílený (Shared Lock). Individuální zámek uzamkne zdroj pro všechny klienty až na jednoho, který může přistupovat ke zdroji bez omezení. Sdílený zámek poskytuje přístup ke zdroji více klientům, každému bude vygenerovaný unikátní zámek. Spolu se zámkem se předpokládá dohoda mezi klienty, že bude každý pracovat na jiné části dokumentu. Pro uzamknutí zdroje (souboru nebo kolekce) existuje příkaz LOCK, po jeho odeslání je navrácen unikátní identifikátor zámku tzv. LockToken vygenerovaný serverem. Pokud bude chtít klient přistoupit k zamčenému souboru, musí se prokázat tímto klíčem. Ovšem LockToken nezaručuje, že bude mít k souboru přístup pouze oprávněný uživatel, protože je tento identifikátor možné zjistit pouhým odesláním dotazu s příkazem PROPFIND na element locktoken. Proto by měla být bezpečnost řešena například pomocí hlavičky Authorization v protokolu HTTP nebo pomocí jiných mechanismů. Příklad použití příkazu LOCK:

LOCK /webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
  <D:lockscope><D:exclusive/></D:lockscope>
  <D:locktype><D:write/></D:locktype>
  <D:owner><D:href>http://example.org/~ejw/contact.html%5B%5D</D:href>
  </D:owner>
</D:lockinfo>

V dotazu s příkazem LOCK je hlavička Timeout, která specifikuje serveru, za jak dlouho zámek expiruje (je možné uvést více hodnot, ale musí být seřazeny podle priorit). Pokud bychom zamykali kolekci, můžeme nastavit způsob uzamčení hlavičkou Depth.

XML dokument, který je k příkazu připojen, obsahuje kořenový element lockinfo a elementy lockscope (určuje jeden z typů zámku exclusive, shared), locktype (specifikuje typ zámku) a owner (definuje majitele zámku). Příklad odpovědi na výše uvedený příkaz LOCK:

HTTP/1.1 200 OK
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c9>
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
  <D:lockdiscovery>
    <D:activelock>
      <D:locktype><D:write/></D:locktype>
      <D:lockscope><D:exclusive/></D:lockscope>
      <D:depth>infinity</D:depth>
      <D:owner>
        <D:href>http://example.org/~ejw/contact.html%5B%5D</D:href>
      </D:owner>
      <D:timeout>Second-604800</D:timeout>
      <D:locktoken>
        <D:href>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c9</D:href>
      </D:locktoken>
      <D:lockroot>
        <D:href>http://example.com/webdav/proposal.doc%5B%5D</D:href>
      </D:lockroot>
    </D:activelock>
  </D:lockdiscovery>
</D:prop>

Odpověď obsahuje vlastnosti, lockdiscovery, popisující atributy zámku (přístupový typ, rozsah působnosti, majitele, čas vypršení platnosti zámku a hodnotu klíče) v příslušných elementech. Pro odemknutí zdroje ještě před expirací doby jeho zamčení se musí použít příkaz UNLOCK, který bude obsahovat hlavičku Lock-Token s příslušnou hodnotou. Příklad příkazu UNLOCK:

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

Standard WebDAV definuje pouze jediný typ zámku a to je write-lock, který zabraňuje vykonání příkazů PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY, DELETE, MKCOL. Pokud je tedy zdroj tímto zámkem zamčený, jiní uživatelé ho i přesto mohou číst.

Metody (nebo také příkazy) se používají v dotazech, které klient zasílá na server. Metody přesně specifikují, jakou akci klient od serveru vyžaduje.

Standard WebDAV je rozšíření HTTP protokolu. Proto se při zasílání dotazů používají i metody HTTP protokolu. Některé metody jsou však aplikovány v mírně pozměněném významu. K těmto metodám standard WebDAV definuje dalších 9 metod pro práci s vlastnostmi, soubory a kolekcemi.

• GET – Význam metody GET je nezměněn. Metoda vznáší požadavek na zdroj definovaný pomocí URI.
• HEAD – Stejný význam jako GET má i HEAD s tím rozdílem, že vrací odpověď bez těla zprávy.
• POST – Sémantika metody je nezměněna. Metoda má stejný význam jako GET, ale v hlavičce požadavku lze odeslat data.
• PUT – Metoda slouží pro nahrání souborů na server, nelze ji aplikovat na kolekce.
• DELETE – Používá se k mazání souborů či kolekce. U kolekcí je zadaná „hloubka“ vymazání vždy nekonečná.
• PROPFIND – Metoda se používá k získání vlastností zvoleného zdroje. K dotazu se přidává XML dokument, který blíže specifikuje příkaz. Kořenovým elementem v XML dokumentu je propfind a ten může obsahovat jeden ze tří elementů:
  • allprop – navrací názvy a hodnoty všech vlastností
  • propname – navrací pouze názvy vlastností
  • prop – element obsahuje vybrané vlastnosti, které server navrátí
• PROPPATCH – Metoda slouží pro odebírání, přidávání a změnu vlastností zdrojů. K bližšímu specifikování příkazu je použit XML dokument, ve kterém je kořenový element propertyupdate. Kořenový element může obsahovat (i současně) další elementy, a to set (pro úpravu a vytváření vlastností) a remove (pro odstranění vlastností). Oba elementy následně obsahují elementy prop s určením, na kterou vlastnost se akce uplatňuje.
• MKCOL – Metoda pro vytvoření nové kolekce. Kolekce bude vytvořena pouze v případě kdy kolekce, ve které se vytváří, existuje.
• COPY – Metoda se používá pro kopírování souborů a kolekcí i s připojenými vlastnostmi. Dotaz musí obsahovat hlavičku Destination, určující [URI] cíle, kam se zdroj kopíruje. Dále mohou být použity nepovinné hlavičky, a to Depth pro určení „hloubky“ kopírování, dovoleny jsou hodnoty 0 nebo nekonečno. Při nezadání hlavičky se pracuje s hodnotou nekonečno. Další nepovinná hlavička je Overwrite, která určuje, zda se má zadaný cíl, pokud existuje, přepsat. Může obsahovat hodnoty F (ponechá cíl) nebo T (přepíše cíl), která je výchozí.
• MOVE – Operace MOVE je logickým ekvivalentem COPY s tím rozdílem, že po zkopírování zdroje do daného cíle je tento zdroj vymazán.
• LOCK – Metoda uzamyká soubor nebo kolekci. Po uzamčení klient obdrží v odpovědi informace o zámku, které jsou zmíněny v podkapitole 3.4 o zamykání. Zámky se mohou také před expirací doby zámku obnovovat, anebo nastavovat „hloubku“ uzamčení pomocí hlavičky Depth.
• UNLOCK – Metoda odstraní zámek souboru nebo kolekce. Při odstraňování musí být v dotazu přítomna hlavička Lock-Token s hodnotou klíče.

Metody OPTIONS, TRACE a CONNECT, které využívá protokol HTTP, nejsou v RFC pro WebDAV popsány.

Stavový kód je tvořen stavovým číslem a hlášením. Je obsažen v odpovědi serveru na dotaz klienta a sděluje, zda se podařilo požadavek definovaný pomocí metody splnit. WebDAV zavadí některé nové stavové kódy, které jsou níže vypsány:

• 207 Multi-Status – Odpověď serveru obsahuje více statusů. Tento status je využíván, pokud klient zašle v dotazu požadavek na více operací.
• 422 Unprocessable Entity – Server rozumí obsahu žádosti, ale není schopen ji vykonat, například kvůli špatnému XML dokumentu, kdy jeho struktura je syntakticky správná, ale sémanticky nekorektní.
• 423 Locked – Soubor nebo kolekce obsahují zámek.
• 424 Failed Dependency – Metoda nemůže být provedena kvůli závislosti na jiné akci, která se nezdařila.
• 507 Insufficient Storage – Server nemůže provést akci, protože není dostatek prostoru pro její provedení.

• verzování řeší protokol Delta-V, který je definován v rámci RFC 3253
• služby sdílení kalendáře řeší protokol CalDAV, kde jsou události v kalendáři prezentovány jako zdroje (soubory) ve formátu iCalendar a jednotlivé kalendáře jako kolekce (složky/adresáře)
• pro účely groupware slouží protokol GroupDAV, který umožňuje uchovávat a sdílet data jako události kalendáře či kontakty
• pro spolupráci s MS Exchange – WebDAV umožňuje práci s emailovou schránkou a byl zachováván až do verze 2007. Ve verzi 2010 prosadil Microsoft svůj protokol založený na principu webových služeb (SOAP/XML).