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-1873) It should be possible to define how hrefs are generated for WebDav
Date Thu, 25 Apr 2013 12:36:17 GMT

    [ 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 

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 

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?).


- 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 

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,


> 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

View raw message