Did not find a collection resource.

[Andreas Gohr]

Hey,

As I wrote before, I'm mainly working with the cadaver command line
client (uses the neon library). And somehow it now complains about my
implementation not being WebDAV enabled.

$ cadaver http://localhost/dokuwiki/lib/plugins/webdav/dav.php
Authentication required for DokuWiki WebDAV on server `localhost':
Username: admin
Password:
Could not access /dokuwiki/lib/plugins/webdav/dav.php/ (not WebDAV-enabled?):
Did not find a collection resource.
Connection to `localhost' closed.

I can run cadaver with -t and it will ignore the error. Doing an ls
then will list my collection just fine.

From what I understand, the client will issue a PROPFIND on the given
endpoint for connecting and will do the same for directory listings.
So why does it complain on connecting but the ls works without errors?

Did anyone get similar errors or can give me a hint at what I should look?

Andi

PS: can anyone recommend a simple logging Proxy (that runs on Linux)
to debug what goes on between my client and the server?

--
splitbrain.org

[Evert Pot]

Hi Andreas,

On 29-Jan-09, at 10:36 AM, Andreas Gohr wrote:

>
> Hey,
>
> As I wrote before, I'm mainly working with the cadaver command line
> client (uses the neon library). And somehow it now complains about my
> implementation not being WebDAV enabled.
>
> $ cadaver http://localhost/dokuwiki/lib/plugins/webdav/dav.php
> Authentication required for DokuWiki WebDAV on server `localhost':
> Username: admin
> Password:
> Could not access /dokuwiki/lib/plugins/webdav/dav.php/ (not WebDAV-
> enabled?):
> Did not find a collection resource.
> Connection to `localhost' closed.
>
> I can run cadaver with -t and it will ignore the error. Doing an ls
> then will list my collection just fine.
>

Trying it with my own setup, things seem to work as expected.

> From what I understand, the client will issue a PROPFIND on the given
> endpoint for connecting and will do the same for directory listings.
> So why does it complain on connecting but the ls works without errors?

This is correct. It will also do an 'OPTIONS' request right before
that. I've seen some clients do an options on the root:

OPTIONS /

or even:

OPTIONS *

I wonder if that's somehow related.

>
> Did anyone get similar errors or can give me a hint at what I should
> look?
>
> Andi
>
> PS: can anyone recommend a simple logging Proxy (that runs on Linux)
> to debug what goes on between my client and the server?

The debugging proxy I personally use is charles. This runs on linux,
but is a java app, but you'll need X-Windows as it's all gui..
If someone is aware of a console based debugging proxy, I'll be very
glad to hear about it as well :)

Some form of a debugging proxy is always strongly recommended if you
run into any problems at all. It would be possible to just hook into
the PHP scripts and log the request/response manually, but that would
for example not cover the case where cadaver hits the / first (if
that's even the case..)

If you're tied to the command line, you could still always do some
stuff with tcpdump.

Evert

[Andreas Gohr]

Hello again,

>> Did not find a collection resource.
>> Connection to `localhost' closed.
>

> This is correct. It will also do an 'OPTIONS' request right before
> that. I've seen some clients do an options on the root:

OPTIONS /dokuwiki/lib/plugins/webdav/dav.php/ HTTP/1.1

is what I get. Interestingly the answer has a content-type of
text/html is that correct? (it has an empty body though).

In the following propfind I get this response:

<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>/dokuwiki/lib/plugins/webdav/dav.php/media/</d:href>
<d:propstat>
<d:prop>
<d:getcontentlength>0</d:getcontentlength>
<d:getlastmodified
xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
b:dt="dateTime.rfc1123">Tue, 03 Feb 2009 10:30:23
+0100</d:getlastmodified>
<d:resourcetype>
<d:collection />
</d:resourcetype>
</d:prop>
<d:status>HTTP/1.1 200 Ok</d:status>
</d:propstat>
<d:propstat>
<d:prop>
<executable xmlns="http://apache.org/dav/props/" />
<d:checked-in />
<d:checked-out />
</d:prop>
<d:status>HTTP/1.1 404 Not Found</d:status>
</d:propstat>
</d:response>
</d:multistatus>

The 404 for checked-in/checked-out seems okay to me. I'm not sure
about the rest. Are there any ressources on the web where I can see
some example communication traces? The ones in the specs weren't that
helpful.

> The debugging proxy I personally use is charles. This runs on linux,
> but is a java app, but you'll need X-Windows as it's all gui..

Using it now. Really useful. A FOSS program would be preferred, though.

Andi

--
splitbrain.org

[Evert Pot]

On 3-Feb-09, at 4:43 AM, Andreas Gohr wrote:

> OPTIONS /dokuwiki/lib/plugins/webdav/dav.php/ HTTP/1.1
>
> is what I get. Interestingly the answer has a content-type of
> text/html is that correct? (it has an empty body though).

That's just the PHP default, so no harm there..

This looks perfect to me..

The response header should have been :

HTTP/1.1 207 Multi-status
Content-type: text/html; charset="utf-8"

The '404 not found parts in the response only relate to the requested
properties which weren't available for the specified resource..

Since you mentioned this was a DavFS problem, I'm going to do some
digging here tonight as well. It's definitely odd at the least, since
as far as I know the spec was implemented correctly (according to
litmus, which uses libneon like DavFS).

Are you using DavFS2? Would you mind giving me an exact version number?

Evert

[Andreas Gohr]

> The response header should have been :
>
> HTTP/1.1 207 Multi-status
> Content-type: text/html; charset="utf-8"

You're probably more in the details of the DAV specs, but I would have
expectes a content-type of

Content-type: text/xml; charset="utf-8"

> The '404 not found parts in the response only relate to the requested
> properties which weren't available for the specified resource..

That's what I thought too.

> Since you mentioned this was a DavFS problem, I'm going to do some
> digging here tonight as well. It's definitely odd at the least, since
> as far as I know the spec was implemented correctly (according to
> litmus, which uses libneon like DavFS).

It's not a DavFS problem, but a cadaver problem (which uses libneon
though). Here are the exact version strings:

$ cadaver --version
cadaver 0.23.2
neon 0.28.3: Library build, IPv6, Expat 2.0.1, zlib 1.2.3.3, OpenSSL
0.9.8i 15 Sep 2008.
readline 5.2

Andi

--
splitbrain.org

[Evert Pot]

On 4-Feb-09, at 4:19 AM, Andreas Gohr wrote:

>
>> The response header should have been :
>>
>> HTTP/1.1 207 Multi-status
>> Content-type: text/html; charset="utf-8"
>
> You're probably more in the details of the DAV specs, but I would have
> expectes a content-type of
>
> Content-type: text/xml; charset="utf-8"
>

You're right.. thats actually how it's done now, I should just copy-
paste the next time :)

>
> It's not a DavFS problem, but a cadaver problem (which uses libneon
> though). Here are the exact version strings:
>
> $ cadaver --version
> cadaver 0.23.2
> neon 0.28.3: Library build, IPv6, Expat 2.0.1, zlib 1.2.3.3, OpenSSL
> 0.9.8i 15 Sep 2008.
> readline 5.2

Great, I'm going to do some digging into this tonight.. Hope to be
able to find some information..

Evert

[Evert Pot]

On 4-Feb-09, at 4:19 AM, Andreas Gohr wrote:

>
> It's not a DavFS problem, but a cadaver problem (which uses libneon
> though). Here are the exact version strings:
>
> $ cadaver --version
> cadaver 0.23.2
> neon 0.28.3: Library build, IPv6, Expat 2.0.1, zlib 1.2.3.3, OpenSSL
> 0.9.8i 15 Sep 2008.
> readline 5.2
>

Over here:

$ cadaver -V
cadaver 0.22.3
neon 0.25.5: Library build, IPv6, libxml 2.6.26, zlib 1.2.3, OpenSSL
0.9.8b 04 May 2006.
readline 5.2

Everything works as expected, with my slightly older versions.

My testing url is http://sabredav.evertpot.com/
Would you mind checking if you're getting similar problems there?

Evert

[Evert | Rooftop]

Update: getting a similar issue now.

[Evert Pot]

Found the issue.

Quick workaround:

change line 158 from ObjectTree.php:

if ($depth==0 || $depth == Sabre_DAV_Server::DEPTH_INFINITY) {

to

if (true || $depth==0 || $depth == Sabre_DAV_Server::DEPTH_INFINITY) {

I'm opening up the books/specs tonight to see what the actual intended
behaviour there is, because I don't want to do any guessing. I have a
hunch I will just end up taking that condition out.

Evert

[Evert | Rooftop]

On Feb 4, 6:27 pm, Evert Pot <evert...@gmail.com> wrote:
> Found the issue.
>
> Quick workaround:
>
> change line 158 from ObjectTree.php:
>
> if ($depth==0 || $depth == Sabre_DAV_Server::DEPTH_INFINITY) {
>
> to
>
> if (true || $depth==0 || $depth == Sabre_DAV_Server::DEPTH_INFINITY) {
>
> I'm opening up the books/specs tonight to see what the actual intended  
> behaviour there is, because I don't want to do any guessing. I have a  
> hunch I will just end up taking that condition out.
>

This is exactly what I did now, as the specs didn't mention it should
be done otherwise. So if you're using the trunk, an 'svn up' will fix
this; otherwise you'll have to wait for 0.6.

I remembered the reasoning for why I did it this way in the first
place. I noticed that with some clients (windows if i recall
correctly) would actually always show 1 nameless directory within
every directory. I might have fixed this since then through other
means, but I'll only be able to truly test this one I get back in the
office, where there's windows machines :)

What's left for me to get 0.6 out, is mainly thorough testing across
clients. I'm thinking this will all be done on saturday.

Thanks for your patience :)
Evert

[Andreas Gohr]

> This is exactly what I did now, as the specs didn't mention it should
> be done otherwise. So if you're using the trunk, an 'svn up' will fix
> this; otherwise you'll have to wait for 0.6.

Works perfect.

> Thanks for your patience :)

No, thank you for looking into this :-)

ANdi

--
splitbrain.org