[Zope3-dev] Re: Does WebDAV work on X3 Beta1?

[Philipp von Weitershausen]

Joachim Werner wrote:
>> I'm *pretty* sure that that is due to 
>> zope.app.dav.interfaces.IDAVSchema lacking a schema field for 
>> 'executable'. The zope.app.dav.adapter.DAVSchemaAdapter implements 
>> IDAVSchema and also has an executable method, so I guess it's just a 
>> matter of adding this field to one of the schemas that IDAVSchema 
>> derives from. Would anyone with decent DAV knowledge know which one?
> 
> You are right. I just came to the same conclusion. If I add the field to 
> IDAVSchema things work fine. I can have a look at the WebDAV specs later 
> to find out where it belongs to.

Please file a collector issue and, when you've found where the field is 
supposed to go to, please append the output of 'svn diff' to the issue. 
Make sure to use the Zope3-dev collector.

> But I think this is a more general bug. At least the error message is 
> not what I'd expect. What if a client asks for some other attribute 
> that's not in the schema? Would that mean that the request breaks, too?

There are no arbitrary attributes that one can ask for in DAV, afaik. 
They all have to be part of some namespace, and the commands in a 
namespace are well-defined sets. I just guess we were missing to specify 
the 'executable' attribute.

> If the client does something that's not within the specs there should be 
> a telling error message (like "This is not a valid WebDAV request!"). If 
> it is within the specs Zope should do the right thing (which might be 
> ignoring the attribute in many cases).

Maybe. The question is what really happens when we get an attribute that 
is not defined. The current situation is that there was an attribute 
which *had* an implementation, but no equivalent in the schema 
description...

But, I guess you are right, we should look into DAV compliance and see 
that Zope does the Right Thing. To me, returning a 500 Server Error 
sounds a lot like the right thing; that happens when some exception is 
raised.
We definitely need tests for this kind of behaviour. Your use-cases 
could help a lot there, and it wouldn't be too hard using boilerplate 
functional tests and the output of tcpwatch.

> Stephan, do you know more about this?

If not he, maybe Sidnei da Silva does... CC'ing him.

>> I actually tried to reproduce your error and I couldn't. You didn't 
>> really say WHAT exactly you did... Seems like you pointed Konqueror at 
>> your Zope instance and I have no idea what kind of DAV commands 
>> Konqueror issues. Maybe you can use Shane Hathaway's TCPWatch and give 
>> us a more detailled explanation of what it was that your DAV client 
>> sent and made Zope3 crash. We can then use that to write a test to 
>> ensure this won't happen again.
> 
> Yes, it was Konqueror. I'll double-check with Windows Webfolders, too.
> 
> Unfortunately unit tests are my weak point.

You should strengthen that point! Zope3's whole development philosophy 
is based on constant testing...

> Even more with things like 
> WebDAV. OTOH I think there are test suites for WebDAV in general that 
> could be run against Zope ...

Good idea; I'd be interest in their outcome...

>> Anyway, when I was trying to reproduce your problem, I stumbled upon a 
>> different one. In my root folder, there's an object sitting that 
>> *doesn't* provide IAnnotatable. For annotatable objects, the 
>> zope.app.dublincore.annotatableadapter.ZDCAnnotatableAdapter is used 
>> to feed dublincore metadata to DAV clients. For my object, it was 
>> surprisingly finding an adapter, but obviously not that one. It found 
>> zope.app.pagetemplate.talesapi.ZopeTalesAPI, which, too, tries to 
>> adapt to IZopeDublinCore. If that fails (which it obviously does for 
>> my non-annotatable object), it raises AttributeError.
>>
>> So, I was getting an AttributeError for 'modified' when I tried to an 
>> 'ls' in cadaver. The problem lies in the following lines 
>> (Zope3/src/zope/app/dav/adapter.py)::
>>
>>      def getlastmodified(self):
>>         value = IDCTimes(self.context).modified
>>         if value is None:
>>             return ''
>>
>> This code makes the assumption, that you can *always* get an adapter 
>> to IDCTimes. ITALESAPI includes IDCTimes, that's why I got the 
>> ZopeTalesAPI adapter for my object, which, however, raised an 
>> AttributeError because my object wasn't annotatable after all...
>>
>> So, we should probably
>>
>> a) make the above code still work if IDCTimes adapter can't be found and
>>
>> b) only register the ZopeTalesAPI adapter for annotatable objects
>>
>> Comments?
> 
> 
> Yes, I came accross this one (or at least a very related one) yesterday 
> (second day using Zope X3, so please be patient with me ;-)). If I use 
> objects that don't implement IAnnotatable I get errors in FTP as well as 
> in WebDAV.

(a side note: objects *provide* an interface, class *implement* them; 
the easiest way to make objects provide IAnnotatable is 
directlyProvide()'ing IAttributeAnnotatable on them; or on their class)

>   File "/opt/ZopeX3/lib64/python/zope/app/ftp/__init__.py", line 123, in 
> _mtime
>     dc = IZopeDublinCore(file)
>   File "/opt/ZopeX3/lib64/python/zope/interface/interface.py", line 681, 
> in __call__
>     raise TypeError("Could not adapt", obj, self)
> TypeError: ('Could not adapt', <boring.boring.Boring object at 
> 0x2a98665cf8>, <InterfaceClass 
> zope.app.dublincore.interfaces.IZopeDublinCore>)

That makes perfect sense from looking at the code; this is *not* what 
should happen. The adaption should fall back to None and just quit if it 
can't adapt.

> And this is what I get via WebDAV:
> 
>   File "/opt/ZopeX3/lib64/python/zope/app/dav/propfind.py", line 121, in 
> PROPFIND
>     value = attr()
>   File "/opt/ZopeX3/lib64/python/zope/app/dav/adapter.py", line 43, in 
> creationdate
>     value = IDCTimes(self.context).created
>   File "/opt/ZopeX3/lib64/python/zope/app/pagetemplate/talesapi.py", 
> line 52, in created
>     raise AttributeError, 'created'
> AttributeError: created
> 10.10.1.74 - zope.anybody [30/Jun/2004:12:59:37 +0200] "PROPFIND / 
> HTTP/1.1" 500 308 "" "Mozilla/5.0 (compatible; Konqueror/3.2; Linux) 
> (KHTML, like Gecko)"

Yup. That's precisely the same symptom as me, just a different property. 
The (erronous) code behind it is the same.

The only consequence I see is, like I suggested in an earlier post, that 
both FTP and DAV code should not depend on objects being adaptable to 
IZopeDublinCore. Furthermore, the ZopeTalesAPI adapter should not be 
registered for * but for IAnnotatable.

I would do this, but I don't understand the tests all too well, 
especiall DAV tests. Sidnei?

Philipp