[
https://issues.apache.org/jira/browse/JCR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641732#comment-13641732
]
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.
> 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
