[
https://issues.apache.org/jira/browse/JCR-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659607#action_12659607
]
Philip Borlin commented on JCR-1917:
------------------------------------
First of all thank you very much for the speedy response to the report.
I am testing against bedework (http://www.bedework.org/bedework/) so the debate
is whether the server is broken, but no matter.
I read the section you were talking about three times to make sure I caught all
the nuances and I have a different interpretation. It seems to me that all
they are saying is that if you see something you can't process just skip it,
don't stop processing. As an example let's say they change the DTD for
calendar-query to:
<!ELEMENT calendar-query (new-feature, (DAV:allprop |
DAV:propname |
DAV:prop)?, filter, timezone?)>
The legacy server receiving this request should skip the new feature but still
expect that the filter element will be after the prop element (if one exists)
and is not expected to look for a prop element after the filter element.
I do have to apologize because the fix I suggested would be a bad idea. It
seems that the RPI WebDAV server (which bedework builds off of) enforces the
ordering of WebDAV requests based off of the examples in the RFCs even though
DTD ordering is not specified. I would not want a change to affect other
users. My new proposal is to add two protected methods that will not change
current behavior but will allow a subclass to have access to everything it
needs to override the toXML() method. The two methods are as follows:
protected Element createElement(Document document) {
return DomUtil.createElement(document, typeLocalName, typeNamespace);
}
protected List getContent() {
return content;
}
The first line of toXML() could be refactored to:
Element reportElement = createElement(document);
for completeness if desired.
> Report Info appends properties after content
> --------------------------------------------
>
> Key: JCR-1917
> URL: https://issues.apache.org/jira/browse/JCR-1917
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-webdav
> Affects Versions: 1.5.0
> Environment: N/A
> Reporter: Philip Borlin
>
> RFC 3253 does not specify any ordering for reports, but RFC 4791 (CalDAV
> specification which is built on top of WebDAV) contains DTD sequences that
> define the order the <prop> elements occur within a report.
> Examples are from section 9.5:
> <!ELEMENT calendar-query ((DAV:allprop |
> DAV:propname |
> DAV:prop)?, filter, timezone?)>
> and from section 9.10
> <!ELEMENT calendar-multiget ((DAV:allprop |
> DAV:propname |
> DAV:prop)?, DAV:href+)>
> As of 1.5.0 org.apache.jackrabbit.webdav.version.report.ReportInfo the
> toXML(Document) method specifically puts the content before the properties.
> I request that we reverse the order and put the properties first before the
> content.
> This fix should have no impact on WebDAV servers since ordering is not
> specified and will allow CalDAV extensions to be built on top of jackrabbit's
> WebDAV.
> Failing to make this fix makes it impossible to add CalDAV extensions on top
> of jackrabbit's WebDAV.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
