WebDAV

WebDAV (Web-based Distributed Authoring and Versioning) je množina rozšíření HTTP protokolu, který poskytuje možnost kooperace a vzdálené správy souborů uložených na webovém serveru. WebDAV je definován pomocí RFC 4918, které vytvořila pracovní skupina Internet Engineering Task Force (IETF). Protokol WebDAV z webu vytváří zapisovatelné paměťové médium. Poskytuje prostředí, v němž mohou uživatelé tvořit, měnit a přesouvat dokumenty na serveru (většinou na webovém serveru). V tomto prostředí se data uživateli jeví jako standardní stromově organizovaný adresářový systém. Díky rozšíření, které zahrnuje sadu metod, hlaviček, formátů dotazů a odpovědí, jsou klienti schopni provádět následující operace:

Vytvářet, upravovat a odstraňovat soubory a dotazovat se na jejich vlastnosti (metadata), např. autor dokumentu, datum vytvoření, atd.
Odstraňovat, vytvářet a procházet sadou souborů, tzv. kolekcí (pod tímto názvem je možno si představit běžný adresář v souborovém systému).
Zamykat soubory, tzn. povolovat úpravy dokumentů v určitý okamžik pouze určeným uživatelům.
Kopírovat a přesouvat soubory v rámci jmenného prostoru serveru - namespace management.
HistorieČlánky
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.

Komunikace mezi klientem a serveremČlánky
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>
<propstat>
<prop xmlns:R=" http://ns.example.com/ns/">
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
Vlastnosti zdrojůČlánky
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'>
<x:name>Jane Doe</x:name>
<x:uri type='email'
added='2005-11-26'>mailto:jane.doe@example.com</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'>
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“, 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Články
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).

ZamykáníČlánky
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 typu 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</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</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</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Články
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 defaultní.
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.

Rozšíření stavových kódůČlánky
Stavový kód je tvořeno 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í.
ImplementaceČlánky
LinuxČlánky
V Linuxu lze využít implementací davfs2 popř. fusedav, které dokáží připojit patřičné url jako coda nebo FUSE systémy souborů. V případě grafického prostředí KDE lze využít součásti kio_http, které má podporu pro WebDAV integrovánu. Toto kupříkladu umožňuje prohlížeči Konqueror (resp. kterékoliv KDE aplikaci) pracovat s WebDAVem přímo. Podporu na podobné úrovni poskytuje i např. prohlížeč Nautilus pro GNOME. Existuje také utilita pro příkazovou řádku jménem cadaver, která poskytuje podobné funkce, jako standardní FTP klient

Mac OS XČlánky
Mac OS X od své první verze (10.0) poskytuje podporu protokolu WebDAV nativně a umožňuje jednotlivé přípojné body připojovat jako uzly souborového systému. Lze se připojovat jak zcela standardní cestou jako v ostatních BSD systémech, ale existuje k tomu i GUI (dialog programu Finder – "Connect to Server"). Od verze 10.1.1 je poskytována podpora pro HTTP Digest Access authentication (tj. šifrovaná Basic access authentication). Od verze 10.4 (Tiger) byla přidána např. možnost komunikace prostřednictvím HTTPS a podpora prostředí klienta za proxy serverem. Finder zobrazuje WebDAV přípojný bod jako externí disk a umožňuje s ním pracovat stejně jako s jakoukoliv částí souborového systému. Služba iDisk (součást služeb MobileMe) využívá WebDAV jako souborový systém (resp. komunikační protokol).

Microsoft WindowsČlánky
Debut WebDAVu v Microsoft Windows se udál v roce 1998 s vydáním verze Windows 98 (Web Folders). Klient sestával z OLE objektu, který mohl být využíván zcela standardně ostatními aplikacemi. Tento klient byl rozšířením Windows Exploreru a později byl integrován i do Windows 2000. Pro Windows XP byl připraven novější klient (WebDAV mini-redirector), který byl rovněž preferovanou cestou pro přístup k WebDAVu. Na rozdíl od své předchozí implementace pracuje tato verze jako služba pracující přímo nad filesystémem, což dovoluje jednotlivé WebDAV přípojné body prezentovat jako síťové disky s písmenným označením jednotky. Tento klient také převádí standardní URI na síťové adresy systému Windows pro zachování kompatibility s Windows API (příklad: http://example.com/dav je převedeno na \\example.com\dav). V historii se objevilo několik problémů tohoto klienta především ohledně autentizace (neboť z bezpečnostních důvodů byla vypnuta podpora pro Basic Auth). WebDAV prostřednictvím zabezpečeného HTTPS byl přidán až s patchem KB892211 (který byl později nahrazen KB907306). Windows Vista a Windows 7 zahrnují pouze nového klienta (tj. WebDAV redirector), nicméně existují i způsoby, jak na 32bitový systém nasadit starý klient (Web folders).

Rozšíření a odvozené protokolyČlánky
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).