Author: ts
Date: Wed Oct 17 15:15:46 2007
New Revision: 6494
Log:
- Added missing files.
Added:
trunk/Webdav/src/transports/property_handlers/nautilus.php (with props)
trunk/Webdav/tests/data/put_test.html
trunk/Webdav/tests/data/put_test.xml
trunk/Webdav/tests/data/put_test.zip (with props)
Added: trunk/Webdav/src/transports/property_handlers/nautilus.php
==============================================================================
--- trunk/Webdav/src/transports/property_handlers/nautilus.php (added)
+++ trunk/Webdav/src/transports/property_handlers/nautilus.php [iso-8859-1] Wed
Oct 17 15:15:46 2007
@@ -1,0 +1,66 @@
+<?php
+/**
+ * File containing the ezcWebdavPropertyHandler class.
+ *
+ * @package Webdav
+ * @version //autogen//
+ * @copyright Copyright (C) 2005-2007 eZ systems as. All rights reserved.
+ * @license http://ez.no/licenses/new_bsd New BSD License
+ */
+/**
+ * Description missing
+ *
+ * @package Webdav
+ * @version //autogen//
+ */
+class ezcWebdavNautilusPropertyHandler extends ezcWebdavPropertyHandler
+{
+ /**
+ * Returns the XML representation of a live property.
+ * Returns a DOMElement, representing the content of the given $property.
+ * The newly created element is also appended as a child to the given
+ * $parentElement.
+ *
+ * @param ezcWebdavLiveProperty $property
+ * @param DOMElement $parentElement
+ * @return DOMElement
+ */
+ protected function serializeLiveProperty( ezcWebdavLiveProperty $property,
DOMElement $parentElement )
+ {
+ switch ( get_class( $property ) )
+ {
+ case 'ezcWebdavGetContentTypeProperty':
+ $elementName = 'getcontenttype';
+ $elementValue = ( $property->mime !== null ? $property->mime :
null );
+ break;
+ default:
+ return parent::serializeLiveProperty( $property,
$parentElement );
+ }
+
+ $propertyElement = $parentElement->appendChild(
+ $this->xml->createDomElement( $parentElement->ownerDocument,
$elementName, $property->namespace )
+ );
+
+ if ( $elementValue instanceof DOMDocument )
+ {
+ $propertyElement->appendChild(
+ $dom->importNode( $elementValue->documentElement, true )
+ );
+ }
+ else if ( is_array( $elementValue ) )
+ {
+ foreach( $elementValue as $subValue )
+ {
+ $propertyElement->appendChild( $subValue );
+ }
+ }
+ else if ( is_scalar( $elementValue ) )
+ {
+ $propertyElement->nodeValue = $elementValue;
+ }
+
+ return $propertyElement;
+ }
+}
+
+?>
Propchange: trunk/Webdav/src/transports/property_handlers/nautilus.php
------------------------------------------------------------------------------
svn:eol-style = native
Added: trunk/Webdav/tests/data/put_test.html
==============================================================================
--- trunk/Webdav/tests/data/put_test.html (added)
+++ trunk/Webdav/tests/data/put_test.html [iso-8859-1] Wed Oct 17 15:15:46 2007
@@ -1,0 +1,530 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
+<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<meta name="generator" content="Docutils 0.4:
http://docutils.sourceforge.net/"; />
+<title>eZ component: Webdav, Design, 1.0</title>
+<meta name="author" content="Kore Nordmann, Tobias Schlitt" />
+<meta name="date" content="$Date$" />
+<style type="text/css">
+
+/*
+:Author: David Goodger
+:Contact: [EMAIL PROTECTED]
+:Date: $Date: 2005-12-18 01:56:14 +0100 (Sun, 18 Dec 2005) $
+:Revision: $Revision: 4224 $
+:Copyright: This stylesheet has been placed in the public domain.
+
+Default cascading style sheet for the HTML output of Docutils.
+
+See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
+customize this style sheet.
+*/
+
+/* used to remove borders from tables and images */
+.borderless, table.borderless td, table.borderless th {
+ border: 0 }
+
+table.borderless td, table.borderless th {
+ /* Override padding for "table.docutils td" with "! important".
+ The right padding separates the table cells. */
+ padding: 0 0.5em 0 0 ! important }
+
+.first {
+ /* Override more specific margin styles with "! important". */
+ margin-top: 0 ! important }
+
+.last, .with-subtitle {
+ margin-bottom: 0 ! important }
+
+.hidden {
+ display: none }
+
+a.toc-backref {
+ text-decoration: none ;
+ color: black }
+
+blockquote.epigraph {
+ margin: 2em 5em ; }
+
+dl.docutils dd {
+ margin-bottom: 0.5em }
+
+/* Uncomment (and remove this text!) to get bold-faced definition list terms
+dl.docutils dt {
+ font-weight: bold }
+*/
+
+div.abstract {
+ margin: 2em 5em }
+
+div.abstract p.topic-title {
+ font-weight: bold ;
+ text-align: center }
+
+div.admonition, div.attention, div.caution, div.danger, div.error,
+div.hint, div.important, div.note, div.tip, div.warning {
+ margin: 2em ;
+ border: medium outset ;
+ padding: 1em }
+
+div.admonition p.admonition-title, div.hint p.admonition-title,
+div.important p.admonition-title, div.note p.admonition-title,
+div.tip p.admonition-title {
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title {
+ color: red ;
+ font-weight: bold ;
+ font-family: sans-serif }
+
+/* Uncomment (and remove this text!) to get reduced vertical space in
+ compound paragraphs.
+div.compound .compound-first, div.compound .compound-middle {
+ margin-bottom: 0.5em }
+
+div.compound .compound-last, div.compound .compound-middle {
+ margin-top: 0.5em }
+*/
+
+div.dedication {
+ margin: 2em 5em ;
+ text-align: center ;
+ font-style: italic }
+
+div.dedication p.topic-title {
+ font-weight: bold ;
+ font-style: normal }
+
+div.figure {
+ margin-left: 2em ;
+ margin-right: 2em }
+
+div.footer, div.header {
+ clear: both;
+ font-size: smaller }
+
+div.line-block {
+ display: block ;
+ margin-top: 1em ;
+ margin-bottom: 1em }
+
+div.line-block div.line-block {
+ margin-top: 0 ;
+ margin-bottom: 0 ;
+ margin-left: 1.5em }
+
+div.sidebar {
+ margin-left: 1em ;
+ border: medium outset ;
+ padding: 1em ;
+ background-color: #ffffee ;
+ width: 40% ;
+ float: right ;
+ clear: right }
+
+div.sidebar p.rubric {
+ font-family: sans-serif ;
+ font-size: medium }
+
+div.system-messages {
+ margin: 5em }
+
+div.system-messages h1 {
+ color: red }
+
+div.system-message {
+ border: medium outset ;
+ padding: 1em }
+
+div.system-message p.system-message-title {
+ color: red ;
+ font-weight: bold }
+
+div.topic {
+ margin: 2em }
+
+h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
+h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
+ margin-top: 0.4em }
+
+h1.title {
+ text-align: center }
+
+h2.subtitle {
+ text-align: center }
+
+hr.docutils {
+ width: 75% }
+
+img.align-left {
+ clear: left }
+
+img.align-right {
+ clear: right }
+
+ol.simple, ul.simple {
+ margin-bottom: 1em }
+
+ol.arabic {
+ list-style: decimal }
+
+ol.loweralpha {
+ list-style: lower-alpha }
+
+ol.upperalpha {
+ list-style: upper-alpha }
+
+ol.lowerroman {
+ list-style: lower-roman }
+
+ol.upperroman {
+ list-style: upper-roman }
+
+p.attribution {
+ text-align: right ;
+ margin-left: 50% }
+
+p.caption {
+ font-style: italic }
+
+p.credits {
+ font-style: italic ;
+ font-size: smaller }
+
+p.label {
+ white-space: nowrap }
+
+p.rubric {
+ font-weight: bold ;
+ font-size: larger ;
+ color: maroon ;
+ text-align: center }
+
+p.sidebar-title {
+ font-family: sans-serif ;
+ font-weight: bold ;
+ font-size: larger }
+
+p.sidebar-subtitle {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+p.topic-title {
+ font-weight: bold }
+
+pre.address {
+ margin-bottom: 0 ;
+ margin-top: 0 ;
+ font-family: serif ;
+ font-size: 100% }
+
+pre.literal-block, pre.doctest-block {
+ margin-left: 2em ;
+ margin-right: 2em ;
+ background-color: #eeeeee }
+
+span.classifier {
+ font-family: sans-serif ;
+ font-style: oblique }
+
+span.classifier-delimiter {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+span.interpreted {
+ font-family: sans-serif }
+
+span.option {
+ white-space: nowrap }
+
+span.pre {
+ white-space: pre }
+
+span.problematic {
+ color: red }
+
+span.section-subtitle {
+ /* font-size relative to parent (h1..h6 element) */
+ font-size: 80% }
+
+table.citation {
+ border-left: solid 1px gray;
+ margin-left: 1px }
+
+table.docinfo {
+ margin: 2em 4em }
+
+table.docutils {
+ margin-top: 0.5em ;
+ margin-bottom: 0.5em }
+
+table.footnote {
+ border-left: solid 1px black;
+ margin-left: 1px }
+
+table.docutils td, table.docutils th,
+table.docinfo td, table.docinfo th {
+ padding-left: 0.5em ;
+ padding-right: 0.5em ;
+ vertical-align: top }
+
+table.docutils th.field-name, table.docinfo th.docinfo-name {
+ font-weight: bold ;
+ text-align: left ;
+ white-space: nowrap ;
+ padding-left: 0 }
+
+h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
+h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
+ font-size: 100% }
+
+tt.docutils {
+ background-color: #eeeeee }
+
+ul.auto-toc {
+ list-style-type: none }
+
+</style>
+</head>
+<body>
+<div class="document" id="ez-component-webdav-design-1-0">
+<h1 class="title">eZ component: Webdav, Design, 1.0</h1>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr><th class="docinfo-name">Author:</th>
+<td>Kore Nordmann, Tobias Schlitt</td></tr>
+<tr><th class="docinfo-name">Revision:</th>
+<td>$Rev$</td></tr>
+<tr><th class="docinfo-name">Date:</th>
+<td>$Date$</td></tr>
+<tr><th class="docinfo-name">Status:</th>
+<td>Draft</td></tr>
+</tbody>
+</table>
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#scope" id="id1" name="id1">Scope</a></li>
+<li><a class="reference" href="#design-overview" id="id2" name="id2">Design
overview</a></li>
+<li><a class="reference" href="#tiers" id="id3" name="id3">Tiers</a></li>
+<li><a class="reference" href="#classes" id="id4" name="id4">Classes</a><ul>
+<li><a class="reference" href="#ezcwebdavserver" id="id5"
name="id5">ezcWebdavServer</a></li>
+<li><a class="reference" href="#ezcwebdavbackend" id="id6"
name="id6">ezcWebdavBackend</a></li>
+<li><a class="reference" href="#ezcwebdavtransport" id="id7"
name="id7">ezcWebdavTransport</a></li>
+<li><a class="reference" href="#ezcwebdavpathfactory" id="id8"
name="id8">ezcWebdavPathFactory</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#example-code" id="id9" name="id9">Example
code</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id1" id="scope" name="scope">Scope</a></h1>
+<p>The scope of this document is to describe the initial design of a component
+that provides a WebDAV server, which works with all major other implementations
+of the <a class="reference"
href="http://en.wikipedia.org/wiki/WebDAV";>WebDAV</a> protocol.</p>
+<p>It is currently not planned to also offer a WebDAV client component.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="design-overview"
name="design-overview">Design overview</a></h1>
+<p>Because of the variaty of buggy and incomplete implementations of WebDAV,
this
+component will provide an abstraction to suite the different needs. Beside
+that, an abstract interface to the backend will be provided.</p>
+<p>The main class of this component will provide a fully <a class="reference"
href="http://tools.ietf.org/html/rfc2518";>RFC 2518</a> compliant
+implementation of a <a class="reference"
href="http://en.wikipedia.org/wiki/WebDAV";>WebDAV</a> server. An instance of
this class retrieves an
+instance of a handler class, which takes care for performing the requested
+operations on a backend (for example the filesystem).</p>
+<p>Additionally, a collection of classes, which inherit the main class will be
+provided. Each of this classes will provide a compatibility layer on top of the
+RFC implementation, which works correctly with one or more "buggy"
WebDAV
+clients. A factory pattern implementation will be provided, which takes
+automatically care of creating the correct server instance for a client.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="tiers" name="tiers">Tiers</a></h1>
+<p>The component is basically devided into 3 tiers: The top tier, being
+represented by the main server class. An instance of this class is responsible
+to dispatch a received request to a correct transport handler, which is capable
+of parsing the request.</p>
+<p>The transport handler level is the second tier. Classes in this tier are
+responsible to parse an incoming request and extract all relevant information
+to generate a response for it into a struct object. These struct object is then
+passed back to the server object.</p>
+<p>Based on the request struct object, the server checks the capabilities of
its
+third tier, the used backend handler. If the handler object provides all
+necessary capabilities to generate a response, it is called to do so. If the
+server class can perform emulation of not available capabilities and rely on
+different features of the backend. In case there is no way, the backend can
+handle the request, the server class will indicate that with an error
+response.</p>
+<p>The way back flows through the 3 tiers back again: The backend handler
+generates a response object, which is passed back to the main server object,
+which makes the active transport handler encode the response and sends it back
+to the client.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="classes"
name="classes">Classes</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id5" id="ezcwebdavserver"
name="ezcwebdavserver">ezcWebdavServer</a></h2>
+<p>The ezcWebdavServer class is the main class of the package. It has to be
+instantiated to create a server instance and provides a method to get the
+server up and running. An object of this class takes the main controll over
+serving the webdav service.</p>
+<p>Among the configuration of the server instance there must be: A backend
handler
+object, which will be used to serve the received WebDAV requests. A fitting
+configuration for the backend handler. A collection of transport handlers which
+can be used to parse incoming requests. General configuration on the bevahiour
+of the server instance (like locking and stuff).</p>
+<p>The backend handler object must extend the base class
ezcWebdavBackendHandler
+and must indicate to the main server, which capabilities it provides. The
+server class can potentially emulate certain capabilities, if the handler does
+not provide it. An example here is locking, which can be either performed by
+the handler itself or the main server class.</p>
+<p>Such emulation functionality could possibly be extracted to a third
category of
+classes, which is only loaded by the main server object on-demand.</p>
+<p>All configured transport handlers must implement the interface
+ezcWebdavTransportHandler, which defines the necessary methods.</p>
+<p>The standard webdav server contains a list of transport handlers associated
+with regular expressions which should match the client name to be used. As a
+fallback the standards compliant transport handler will be used.</p>
+<p>Special implementation added by the user will be add on top of the list, to
be
+used at highest priority.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id6" id="ezcwebdavbackend"
name="ezcwebdavbackend">ezcWebdavBackend</a></h2>
+<p>All backend handlers for the Webdav component must extends this abstract
base
+class and implement its abstract methods for very basic WebDAV serving. The
+operations defined for every backend handler to be mandatory are:</p>
+<ul class="simple">
+<li>head()</li>
+<li>get()</li>
+<li>propFind()</li>
+<li>propFetch()</li>
+</ul>
+<p>All other WebDAV operations are optional to be implemented by a backend
handler
+and are defined by the handler itself. The additional basic capabilities of
+backend handlers are indicated by implementing interfaces for the support
+additional request methods, like put, change, etc.</p>
+<p>Additional features, like encryption support will be indicated by returning
a
+bitmask of supported features by the backend handler.</p>
+<p>The logical groups of capabilities are:</p>
+<dl class="docutils">
+<dt>Put</dt>
+<dd>The put capability indicates, that a handler is capable of handling file
+uploads via HTTP-PUT method.</dd>
+<dt>Change</dt>
+<dd>This sub class of WebDAV operations defines delete, copy and move
operations to
+be supported by the handler class.</dd>
+<dt>Make collection</dt>
+<dd>The creation of new collections also makes up a capability unit and can
+optionally be implemented.</dd>
+<dt>Lock</dt>
+<dd>If the hander provides locking facilities on its own, the main server
object
+must not take care about that.</dd>
+<dt>GZIP-Compress</dt>
+<dd>Handlers implementing this facility can deal with GZIP and bzip2 based
+compression.</dd>
+</dl>
+<p>If a handler does not support a certain facility and the main server object
is
+not capable of emulating it, the server will respond using a "501 Not
+Implemented" server error.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id7" id="ezcwebdavtransport"
name="ezcwebdavtransport">ezcWebdavTransport</a></h2>
+<p>A class implementing this interface is capable of parsing a raw HTTP request
+into a struct extending ezcWebdavRequest and generating the HTTP response out
+of the ezcWebdavResponse struct. One transport handler is usually built to
+handle the communication with a certain set of specific client
+implementations.</p>
+<p>A transport handler class will be able to parse the incoming HTTP request
data
+into a struct identifying a certain type of request and containg all necessary
+and unified data, so that a backend handler can repsond to it.</p>
+<p>The backend handler will then create a corresponding response object, which
+will be encoded back into HTTP data by the transport handler and send to the
+client by the server.</p>
+<p>Each request type will come with its own struct classes to represent request
+and response data for the request. Beside the structured HTTP data, the structs
+can contain any additional information that must be transferred between server,
+transport handler and backend handler.</p>
+<p>All struct classes representing either a request of response of the server
will
+extend the abstract base classes ezcWebdavRequest and ezcWebdavResponse.</p>
+<p>An example of this structure is: ezcWebdavGetRequest and
ezcWebdavGetResponse</p>
+<p>These 2 classes will be used to serve GET requests. Beside the usual request
+information - like URI, date and headers - the request object will contain
+information about partial GET mechanisms to use and what else is important.
+The backend handler will return an instance of ezcWebdavGetResponse if the
+request was handled correctly, or a corresponding ezcWebdavErrorResponse
+object, if the request failed.</p>
+<p>The main server instance will know about available clients and will have a
+regular expression for each of them, to identify the clients it communicates
+to by matching the regualr expression against the client name provided in the
+HTTP headers.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id8" id="ezcwebdavpathfactory"
name="ezcwebdavpathfactory">ezcWebdavPathFactory</a></h2>
+<p>This class is meant to calculate the path of the requested item from the
+backend based on the given path by the webdav client. The resulting path
+string is absolute to the root of the backend repository.</p>
+<p>This class is necessary to calculate the correct path when a server uses
+rewrite rules for mapping directories to one or more webdav implementations.
+The basic class uses pathinfo to parse the requested file / collection.</p>
+<p>Request: /path/to/webdav.php/path/to/file
+Result: /path/to/file</p>
+<p>You may want to provide custome implementations for different mappings so
that
+rewrite could be used by the webserver to access files.</p>
+<p>Request: /images/path/to/file
+Rewritten: /path/to/dav_images.php/path/to/file
+Result: /path/to/file</p>
+<p>The factory class is necessary, because the paths contained in the request
+body will match the same scheme like the original request path, but not be
+rewritten by the webserver, so that the user may extend the path factory to
+fit his own purposes.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="example-code"
name="example-code">Example code</a></h1>
+<p>The following snippet shows the API calls necessary to get a WebDAV server
up
+and running.</p>
+<pre class="literal-block">
+ <?php
+
+ $server = new ezcWebdavServer();
+
+ // Server data using file backend with data in "path/"
+ $server->backend = new ezcWebdavBackendFile( '/path' );
+
+// Optionally register aditional transport handlers
+ //
+ // This step is only required, when a user wants to provide own
+ // implementations for special clients.
+ $server->registerTransportHandler(
+ // Regular expression to match client name
+ '(Microsoft.*Webdav\s+XP)i',
+ // Class name of transport handler, extending
ezcWebdavTransportHandler
+ 'ezcWebdavMicrosoftTransport'
+ );
+ $server->registerTransportHandler(
+ // Regular expression to match client name
+ '(.*Firefox.*)i',
+ // Class name of transport handler, extending
ezcWebdavTransportHandler
+ 'ezcWebdavMozillaTransport'
+ );
+
+ // Serve requests
+ $server->handle();
+</pre>
+<!-- Local Variables:
+mode: rst
+fill-column: 79
+End:
+vim: et syn=rst tw=79 -->
+</div>
+</div>
+</body>
+</html>
Added: trunk/Webdav/tests/data/put_test.xml
==============================================================================
--- trunk/Webdav/tests/data/put_test.xml (added)
+++ trunk/Webdav/tests/data/put_test.xml [iso-8859-1] Wed Oct 17 15:15:46 2007
@@ -1,0 +1,120 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE document PUBLIC "+//IDN docutils.sourceforge.net//DTD Docutils
Generic//EN//XML" "http://docutils.sourceforge.net/docs/ref/docutils.dtd";>
+<!-- Generated by Docutils 0.4 -->
+<document ids="ez-component-webdav-design-1-0" names="ez\ component:\ webdav,\
design,\ 1.0" source="Webdav/design/design.txt" title="eZ component: Webdav,
Design, 1.0"><title>eZ component: Webdav, Design,
1.0</title><docinfo><author>Kore Nordmann, Tobias
Schlitt</author><revision>$Rev$</revision><date>$Date$</date><status>Draft</status></docinfo><topic
classes="contents" ids="contents"
names="contents"><title>Contents</title><bullet_list><list_item><paragraph><reference
ids="id1"
refid="scope">Scope</reference></paragraph></list_item><list_item><paragraph><reference
ids="id2" refid="design-overview">Design
overview</reference></paragraph></list_item><list_item><paragraph><reference
ids="id3"
refid="tiers">Tiers</reference></paragraph></list_item><list_item><paragraph><reference
ids="id4"
refid="classes">Classes</reference></paragraph><bullet_list><list_item><paragraph><reference
ids="id5"
refid="ezcwebdavserver">ezcWebdavServer</reference></paragraph></list_item><list_item><paragraph><reference
ids="id6"
refid="ezcwebdavbackend">ezcWebdavBackend</reference></paragraph></list_item><list_item><paragraph><reference
ids="id7"
refid="ezcwebdavtransport">ezcWebdavTransport</reference></paragraph></list_item><list_item><paragraph><reference
ids="id8"
refid="ezcwebdavpathfactory">ezcWebdavPathFactory</reference></paragraph></list_item></bullet_list></list_item><list_item><paragraph><reference
ids="id9" refid="example-code">Example
code</reference></paragraph></list_item></bullet_list></topic><section
ids="scope" names="scope"><title refid="id1">Scope</title><paragraph>The scope
of this document is to describe the initial design of a component
+that provides a WebDAV server, which works with all major other implementations
+of the <reference name="WebDAV"
refuri="http://en.wikipedia.org/wiki/WebDAV";>WebDAV</reference>
protocol.</paragraph><target ids="webdav" names="webdav"
refuri="http://en.wikipedia.org/wiki/WebDAV"/><paragraph>It is currently not
planned to also offer a WebDAV client component.</paragraph></section><section
ids="design-overview" names="design\ overview"><title refid="id2">Design
overview</title><paragraph>Because of the variaty of buggy and incomplete
implementations of WebDAV, this
+component will provide an abstraction to suite the different needs. Beside
+that, an abstract interface to the backend will be
provided.</paragraph><paragraph>The main class of this component will provide a
fully <reference name="RFC 2518"
refuri="http://tools.ietf.org/html/rfc2518";>RFC 2518</reference> compliant
+implementation of a <reference name="WebDAV"
refuri="http://en.wikipedia.org/wiki/WebDAV";>WebDAV</reference> server. An
instance of this class retrieves an
+instance of a handler class, which takes care for performing the requested
+operations on a backend (for example the filesystem).</paragraph><target
ids="rfc-2518" names="rfc\ 2518"
refuri="http://tools.ietf.org/html/rfc2518"/><paragraph>Additionally, a
collection of classes, which inherit the main class will be
+provided. Each of this classes will provide a compatibility layer on top of the
+RFC implementation, which works correctly with one or more "buggy"
WebDAV
+clients. A factory pattern implementation will be provided, which takes
+automatically care of creating the correct server instance for a
client.</paragraph></section><section ids="tiers" names="tiers"><title
refid="id3">Tiers</title><paragraph>The component is basically devided into 3
tiers: The top tier, being
+represented by the main server class. An instance of this class is responsible
+to dispatch a received request to a correct transport handler, which is capable
+of parsing the request.</paragraph><paragraph>The transport handler level is
the second tier. Classes in this tier are
+responsible to parse an incoming request and extract all relevant information
+to generate a response for it into a struct object. These struct object is then
+passed back to the server object.</paragraph><paragraph>Based on the request
struct object, the server checks the capabilities of its
+third tier, the used backend handler. If the handler object provides all
+necessary capabilities to generate a response, it is called to do so. If the
+server class can perform emulation of not available capabilities and rely on
+different features of the backend. In case there is no way, the backend can
+handle the request, the server class will indicate that with an error
+response.</paragraph><paragraph>The way back flows through the 3 tiers back
again: The backend handler
+generates a response object, which is passed back to the main server object,
+which makes the active transport handler encode the response and sends it back
+to the client.</paragraph></section><section ids="classes"
names="classes"><title refid="id4">Classes</title><section
ids="ezcwebdavserver" names="ezcwebdavserver"><title
refid="id5">ezcWebdavServer</title><paragraph>The ezcWebdavServer class is the
main class of the package. It has to be
+instantiated to create a server instance and provides a method to get the
+server up and running. An object of this class takes the main controll over
+serving the webdav service.</paragraph><paragraph>Among the configuration of
the server instance there must be: A backend handler
+object, which will be used to serve the received WebDAV requests. A fitting
+configuration for the backend handler. A collection of transport handlers which
+can be used to parse incoming requests. General configuration on the bevahiour
+of the server instance (like locking and stuff).</paragraph><paragraph>The
backend handler object must extend the base class ezcWebdavBackendHandler
+and must indicate to the main server, which capabilities it provides. The
+server class can potentially emulate certain capabilities, if the handler does
+not provide it. An example here is locking, which can be either performed by
+the handler itself or the main server class.</paragraph><paragraph>Such
emulation functionality could possibly be extracted to a third category of
+classes, which is only loaded by the main server object
on-demand.</paragraph><paragraph>All configured transport handlers must
implement the interface
+ezcWebdavTransportHandler, which defines the necessary
methods.</paragraph><paragraph>The standard webdav server contains a list of
transport handlers associated
+with regular expressions which should match the client name to be used. As a
+fallback the standards compliant transport handler will be
used.</paragraph><paragraph>Special implementation added by the user will be
add on top of the list, to be
+used at highest priority.</paragraph></section><section ids="ezcwebdavbackend"
names="ezcwebdavbackend"><title
refid="id6">ezcWebdavBackend</title><paragraph>All backend handlers for the
Webdav component must extends this abstract base
+class and implement its abstract methods for very basic WebDAV serving. The
+operations defined for every backend handler to be mandatory
are:</paragraph><bullet_list
bullet="-"><list_item><paragraph>head()</paragraph></list_item><list_item><paragraph>get()</paragraph></list_item><list_item><paragraph>propFind()</paragraph></list_item><list_item><paragraph>propFetch()</paragraph></list_item></bullet_list><paragraph>All
other WebDAV operations are optional to be implemented by a backend handler
+and are defined by the handler itself. The additional basic capabilities of
+backend handlers are indicated by implementing interfaces for the support
+additional request methods, like put, change,
etc.</paragraph><paragraph>Additional features, like encryption support will be
indicated by returning a
+bitmask of supported features by the backend
handler.</paragraph><paragraph>The logical groups of capabilities
are:</paragraph><definition_list><definition_list_item><term>Put</term><definition><paragraph>The
put capability indicates, that a handler is capable of handling file
+uploads via HTTP-PUT
method.</paragraph></definition></definition_list_item><definition_list_item><term>Change</term><definition><paragraph>This
sub class of WebDAV operations defines delete, copy and move operations to
+be supported by the handler
class.</paragraph></definition></definition_list_item><definition_list_item><term>Make
collection</term><definition><paragraph>The creation of new collections also
makes up a capability unit and can
+optionally be
implemented.</paragraph></definition></definition_list_item><definition_list_item><term>Lock</term><definition><paragraph>If
the hander provides locking facilities on its own, the main server object
+must not take care about
that.</paragraph></definition></definition_list_item><definition_list_item><term>GZIP-Compress</term><definition><paragraph>Handlers
implementing this facility can deal with GZIP and bzip2 based
+compression.</paragraph></definition></definition_list_item></definition_list><paragraph>If
a handler does not support a certain facility and the main server object is
+not capable of emulating it, the server will respond using a "501 Not
+Implemented" server error.</paragraph></section><section
ids="ezcwebdavtransport" names="ezcwebdavtransport"><title
refid="id7">ezcWebdavTransport</title><paragraph>A class implementing this
interface is capable of parsing a raw HTTP request
+into a struct extending ezcWebdavRequest and generating the HTTP response out
+of the ezcWebdavResponse struct. One transport handler is usually built to
+handle the communication with a certain set of specific client
+implementations.</paragraph><paragraph>A transport handler class will be able
to parse the incoming HTTP request data
+into a struct identifying a certain type of request and containg all necessary
+and unified data, so that a backend handler can repsond to
it.</paragraph><paragraph>The backend handler will then create a corresponding
response object, which
+will be encoded back into HTTP data by the transport handler and send to the
+client by the server.</paragraph><paragraph>Each request type will come with
its own struct classes to represent request
+and response data for the request. Beside the structured HTTP data, the structs
+can contain any additional information that must be transferred between server,
+transport handler and backend handler.</paragraph><paragraph>All struct
classes representing either a request of response of the server will
+extend the abstract base classes ezcWebdavRequest and
ezcWebdavResponse.</paragraph><paragraph>An example of this structure is:
ezcWebdavGetRequest and ezcWebdavGetResponse</paragraph><paragraph>These 2
classes will be used to serve GET requests. Beside the usual request
+information - like URI, date and headers - the request object will contain
+information about partial GET mechanisms to use and what else is important.
+The backend handler will return an instance of ezcWebdavGetResponse if the
+request was handled correctly, or a corresponding ezcWebdavErrorResponse
+object, if the request failed.</paragraph><paragraph>The main server instance
will know about available clients and will have a
+regular expression for each of them, to identify the clients it communicates
+to by matching the regualr expression against the client name provided in the
+HTTP headers.</paragraph></section><section ids="ezcwebdavpathfactory"
names="ezcwebdavpathfactory"><title
refid="id8">ezcWebdavPathFactory</title><paragraph>This class is meant to
calculate the path of the requested item from the
+backend based on the given path by the webdav client. The resulting path
+string is absolute to the root of the backend
repository.</paragraph><paragraph>This class is necessary to calculate the
correct path when a server uses
+rewrite rules for mapping directories to one or more webdav implementations.
+The basic class uses pathinfo to parse the requested file /
collection.</paragraph><paragraph>Request: /path/to/webdav.php/path/to/file
+Result: /path/to/file</paragraph><paragraph>You may want to provide custome
implementations for different mappings so that
+rewrite could be used by the webserver to access
files.</paragraph><paragraph>Request: /images/path/to/file
+Rewritten: /path/to/dav_images.php/path/to/file
+Result: /path/to/file</paragraph><paragraph>The factory class is necessary,
because the paths contained in the request
+body will match the same scheme like the original request path, but not be
+rewritten by the webserver, so that the user may extend the path factory to
+fit his own purposes.</paragraph></section></section><section
ids="example-code" names="example\ code"><title refid="id9">Example
code</title><paragraph>The following snippet shows the API calls necessary to
get a WebDAV server up
+and running.</paragraph><literal_block xml:space="preserve"> <?php
+
+ $server = new ezcWebdavServer();
+
+ // Server data using file backend with data in "path/"
+ $server->backend = new ezcWebdavBackendFile( '/path' );
+
+// Optionally register aditional transport handlers
+ //
+ // This step is only required, when a user wants to provide own
+ // implementations for special clients.
+ $server->registerTransportHandler(
+ // Regular expression to match client name
+ '(Microsoft.*Webdav\s+XP)i',
+ // Class name of transport handler, extending
ezcWebdavTransportHandler
+ 'ezcWebdavMicrosoftTransport'
+ );
+ $server->registerTransportHandler(
+ // Regular expression to match client name
+ '(.*Firefox.*)i',
+ // Class name of transport handler, extending
ezcWebdavTransportHandler
+ 'ezcWebdavMozillaTransport'
+ );
+
+ // Serve requests
+ $server->handle();</literal_block><comment xml:space="preserve">Local
Variables:
+mode: rst
+fill-column: 79
+End:
+vim: et syn=rst tw=79</comment></section></document>
Added: trunk/Webdav/tests/data/put_test.zip
==============================================================================
Binary file - no diff available.
Propchange: trunk/Webdav/tests/data/put_test.zip
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
--
svn-components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/svn-components
