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:38:16 GMT

    [ 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

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


- 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

View raw message