jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1917) Report Info appends properties after content
Date Mon, 29 Dec 2008 19:14:44 GMT

    [ 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message