Angela,
first of all many thanks for you long reply. Comments inline.
Angela Schreiber wrote:
hi julian
First step was to run the generic test suite Litmus
(<http://www.webdav.org/neon/litmus/>), which currently reports a
range of failures,
i let litmus run a couple of times in the past and send
the commented results to the list:
1) initial litmus result.
that post also explains, why PROPPATCH fails with the
default setup: by default non-collection resources represent
jcr nodes with nodetype nt:file. This nodetype does not allow
to set random properties.
http://www.mail-archive.com/[email protected]/msg02792.html
2) a more recent test (after reworking the dav-library while
getting rid of JDOM)
http://www.mail-archive.com/[email protected]/msg04037.html
Thanks for the pointer (Yes, I should have scanned the mailing list
archives first. Sorry.).
One difference over here is that I apparently have a newer Litmus
version (0.10.5) which includes more test cases (see below). You may
want to update your copy :-).
Regarding PROPPATCH: understood. However, I really tried hard but
couldn't figure out so far how to reconfigure the system so that custom
properties are allowed? Or does this require a change in the code base?
From the p.o.v. of the user of a generic WebDAV server, I'd expect
custom properties to be supported.
some of which seem to be trivial (non wellformed request bodies not
rejected with status 400),
brian originally posted findings resulting from litmus
tests. at that time we decided, that we try to work around
invalid xml within PROPFIND although this is not compliant
with the RFC. if i'm not mistaken, there is still a 'todo' in
the webdav-request impl class.
Yes, there is. Right now, PROPFIND with a broken request body behaves as
if no body was present. I think that's a bug, and I don't think any
client relies on that. From an implementation point of view, the generic
method that gets the DOM of the request body should have a flag
(indicating whether a request body is required), and it should be
allowed to throw an exception (when required body not present, or body
not wellformed). From a debugging point of view, returning the message
of the XML parser exception in the response body may be useful for
developers implementing custom clients...
some not (such as If header evaluation problems,
this one i missed so far :)
See below.
Also, what are the current goals for jcr-server? Is it just a
proof-of-concept, or is it supposed to become a fully compliant
implementation of the applicable RFCs? Is it supposed to follow the
changes in RFC2518bis as well?
at the very beginning the aim was to provide a 'simple'
dav-view to a JSR170 compliant repository (that what we
still call the 'simple server') as well as a webdav
remoting for a JSR170 repository (the 'jcr-server').
Ah. I was completely confused by the the two different things, now I
understand :-).
the webdav library which does not have any dependencies
to the jcr-api was just a side-effect of the efforts
made for the server implementations... in the meantime
we put some work into the library, to improve compliance
with the various webdav RFCs.
regarding compliance of the 2 implementations:
a) jcr-server: since the aim of this impl is to provide
remoting of the jsr170 api; compliance to dav-RFC is
fine but not the primary goal.
b) simple-server: compliance it definitely required.
however, the supported feature-set is forced by the
underlying repository. its not the dav-implementation that
builts or govers the data storage. i guess, this has been
the source of some misunderstanding in the past.
currently the simple-server only implements compliance
levels 1,2. jeremi planned to add additional functionality
to the simple server.
I think it would be interesting to come up with a plan that would avoid
that distinction. A "common" server like that would be a fully compliant
(or as compliant as possible) server, and the JCR functionality that
doesn't map properly would be hidden somehow from generic clients. That way.
for further information regarding aims and current status
of the jcr-server see the following posts:
http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03658.html
http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03693.html
http://www.mail-archive.com/[email protected]/msg03762.html
Thanks.
Below are the Litmus 0.10.5 results I'm currently seeing, with in-lined
comments.
-> running `basic':
0. init.................. pass
1. begin................. pass
2. options............... pass
3. put_get............... pass
4. put_get_utf8_segment.. pass
5. mkcol_over_plain...... pass
6. delete................ pass
7. delete_null........... pass
8. delete_fragment....... pass
9. mkcol................. pass
10. mkcol_again........... pass
11. delete_coll........... pass
12. mkcol_no_parent....... pass
13. mkcol_with_body....... pass
14. finish................ pass
<- summary for `basic': of 15 tests run: 15 passed, 0 failed. 100.0%
-> running `copymove':
0. init.................. pass
1. begin................. pass
2. copy_init............. pass
3. copy_simple........... pass
4. copy_overwrite........ pass
5. copy_nodestcoll....... WARNING: COPY to non-existant collection
'/jackrabbit-server/repository/default/litmus/nonesuch' gave '403
Forbidden' not 409
...................... pass (with 1 warning)
In
<http://www.mail-archive.com/[email protected]/msg02792.html>,
you wrote:
"[ note: because 'shallow' copy is not possible with jcr and results in
503.
test would pass otherwise ]"
I'm not sure what the reference about shallow copy is about; as far as I
can tell, Litmus is doing a deep (default) copy, and just wants the
server to reject the request with 409 because that's what RFC2518
mandates when the parent collection for the target resource doesn't exist.
6. copy_cleanup.......... pass
7. copy_coll............. pass
8. move.................. pass
9. move_coll............. pass
10. move_cleanup.......... pass
11. finish................ pass
<- summary for `copymove': of 12 tests run: 12 passed, 0 failed. 100.0%
-> 1 warning was issued.
-> running `props':
0. init.................. pass
1. begin................. pass
2. propfind_invalid...... FAIL (PROPFIND with non-well-formed XML
request body got 207 response not 400)
3. propfind_invalid2..... FAIL (PROPFIND with invalid namespace
declaration in body (see FAQ) got 207 response not 400)
(see above)
4. propfind_d0........... pass
5. propinit.............. pass
6. propset............... FAIL (PROPPATCH on
`/jackrabbit-server/repository/default/litmus/prop':
http://localhost:8080/jackrabbit-server/repository/default/litmus/prop:
409 Conflict )
7. propget............... SKIPPED
8. propextended.......... pass
9. propmove.............. SKIPPED
10. propget............... SKIPPED
11. propdeletes........... SKIPPED
12. propget............... SKIPPED
13. propreplace........... SKIPPED
14. propget............... SKIPPED
15. propnullns............ SKIPPED
16. propget............... SKIPPED
17. prophighunicode....... SKIPPED
18. propget............... SKIPPED
19. propvalnspace......... SKIPPED
20. propwformed........... pass
21. propinit.............. pass
22. propmanyns............ FAIL (PROPPATCH on
`/jackrabbit-server/repository/default/litmus/prop':
http://localhost:8080/jackrabbit-server/repository/default/litmus/prop:
409 Conflict )
23. propget............... FAIL (No value given for property
{kappa}somename)
24. propcleanup........... pass
25. finish................ pass
-> 12 tests were skipped.
<- summary for `props': of 14 tests run: 9 passed, 5 failed. 64.3%
-> running `locks':
0. init.................. pass
1. begin................. pass
2. options............... pass
3. precond............... pass
4. init_locks............ pass
5. put................... pass
6. lock_excl............. pass
7. discover.............. pass
8. refresh............... pass
9. notowner_modify....... WARNING: PROPPATCH failed with 0 not 423
...................... pass (with 1 warning)
10. notowner_lock......... pass
11. owner_modify.......... pass
12. notowner_modify....... WARNING: PROPPATCH failed with 0 not 423
...................... pass (with 1 warning)
As mentioned in your earlier email, this is because Litmus expects a 423
instead of a 207 with embedded 423 status. I would say that Litmus is
correct to expect that, as multistatus shouldn't be used unless it's
required by the method definition (in this case, it doesn't seem to make
sense as only one resource would have been affected, and the error is
actually reported for the resource at the request-URI).
I think the majority of other implementations doesn't return a 207 here,
so I wouldn't really be surprised if a client would be confused by that.
13. notowner_lock......... pass
14. copy.................. FAIL (could not COPY locked resource:
403 Forbidden)
(not sure about this one)
15. cond_put.............. pass
16. fail_cond_put......... pass
17. cond_put_with_not..... pass
18. cond_put_corrupt_token WARNING: PUT failed with 412 not 423
...................... pass (with 1 warning)
In this case, an If header specifies two no-tag-lists productions, of
which one always evaluates to true; thus checking the If header should
not fail, and execution of the method should proceed. A 423 is expected
because the required lock token indeed wasn't submitted in the If header.
19. complex_cond_put...... pass
20. fail_complex_cond_put. pass
21. unlock................ pass
22. fail_cond_put_unlocked FAIL (conditional PUT with invalid lock-token
should fail: 204 No Content)
Here, the tests *did* expect a 412, because the If header contained a
single No-tag-list, wich evaluates to false. In general, just because a
resource isn't locked doesn't mean the If header doesn't need to be
evaluated.
23. lock_shared........... FAIL (LOCK on
`/jackrabbit-server/repository/default/litmus/lockme': 412 Precondition
Failed)
This is expected to fail if no shared locks are supported; however 412
seems to be fishy here, as no conditional header is present in the request.
24. notowner_modify....... SKIPPED
25. notowner_lock......... SKIPPED
26. owner_modify.......... SKIPPED
27. double_sharedlock..... SKIPPED
28. notowner_modify....... SKIPPED
29. notowner_lock......... SKIPPED
30. unlock................ SKIPPED
31. prep_collection....... pass
32. lock_collection....... pass
33. owner_modify.......... pass
34. notowner_modify....... WARNING: PROPPATCH failed with 0 not 423
...................... pass (with 1 warning)
35. refresh............... pass
36. indirect_refresh...... pass
37. unlock................ pass
38. finish................ pass
-> 7 tests were skipped.
<- summary for `locks': of 32 tests run: 29 passed, 3 failed. 90.6%
-> 4 warnings were issued.
-> running `http':
0. init.................. pass
1. begin................. pass
2. expect100............. pass
3. finish................ pass
<- summary for `http': of 4 tests run: 4 passed, 0 failed. 100.0%
Best regards, Julian
