[
https://issues.apache.org/jira/browse/JCR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641731#comment-13641731
]
Julian Reschke commented on JCR-1873:
-------------------------------------
Hi there,
so I just spent quite some time in the aftermath of these changes,
fixing bugs in the client and the server related to handling absolute
paths (instead of absolute URIs); see JCR-3535 plus sub tasks for details.
Reminder: this is about allowing the server to use absolute paths where
previously full URIs were used (for instance, in multistatus's DAV:href
element).
Specification background: for DAV:href, it was always allowed to use a
full path instead of a URI. As a matter of fact, Apache mod_dav always
has been doing this.
In Jackrabbit, until recently we only supported full URIs. A fully
conforming server needs to deal with absolute paths in request bodies,
and resolve them against the request URI. Furthermore, when it finds a
full URI, it should check the authority component against the real
server address.
Also, in RFC 4918 we relaxed the protocol to allow paths instead of URIs
in header fields as well (such as "Destination:"). Fortunately, we added
this to Jackrabbit a long time ago, so only a bit of work was left (see
<https://issues.apache.org/jira/browse/JCR-3574>).
What we have now works with both absolute URIs and absolute paths. Here
"works" means that the integration tests for jcr2dav behave the same in
both cases.
However, there are multiple points that trouble me:
- the way we run tests, we only test one configuration
- we assume that both client and server have the same preference (which
doesn't make any sense at all)
- we have code that throws away the authority component instead of
checking it (yes, added by me to make progress more quickly)
Some of the problems seem to be caused by the way we have done JCR-1873,
where we just forced the Locators to use absolute paths. This is ok for
*generating* DAV:href elements, but doesn't work at all for *resolving*
(where you always need to support both formats).
So I believe this needs more cleanup, in particular as this code is
going to be used for Oak as well (right?).
Proposal:
- Refactor code so that the Locators *always* have knowledge about the
full URI, can handle both formats as input, and can be configured which
of the two formats to emit. Hopefully, this will move all URI resolution
related code into a common place.
- Use java.net.URI in many places where we know use String (avoiding
constant re-parsing)
- Ultimately, change the default to always use absolute paths instead of
URIs
These changes will affect a lot of code, but they *should* be easy to
port back as the server/webdav parts have been stable for a long time.
Feedback appreciated,
Julian
> It should be possible to define how hrefs are generated for WebDav
> ------------------------------------------------------------------
>
> Key: JCR-1873
> URL: https://issues.apache.org/jira/browse/JCR-1873
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-webdav
> Affects Versions: 2.4.3, 2.5.2
> Reporter: Marc
> Assignee: Claus Köll
> Fix For: 2.4.4, 2.6
>
> Attachments: JCR-1873.patch
>
>
> Jackrabbit's WebDav implementation puts absolute URLs in the content of e.g.
> multistatus responses. This makes the use of secured reverse proxies
> impossible as these URLs reflect the scheme and host of the jackrabbit server
> and not the proxy's server. Julian Reschke suggested [1] to use absolute
> paths instead of absolute URLs.
> [1]
> http://markmail.org/message/qc6gd4hmqlstrny7#query:+page:1+mid:3cmqdxbedvryvms7+state:results
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
