[
https://issues.apache.org/jira/browse/JCR-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659609#action_12659609
]
Julian Reschke commented on JCR-1917:
-------------------------------------
> First of all thank you very much for the speedy response to the report.
You're welcome.
> I am testing against bedework (http://www.bedework.org/bedework/) so the
> debate is whether the server is broken, but no matter.
I see.
> 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.
Nope. See http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.17.p.7:
"...Element ordering is irrelevant unless otherwise stated,..."
So if a recipient, be it a server or a client, expects a specific ordering,
it's broken.
> ....
I don't think Jackrabbit should start adding workarounds for broken software if
it can be avoided. So I'd propose to first raise an issue against that server.
> 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.
