[
http://issues.apache.org/jira/browse/JCR-184?page=comments#action_12330015 ]
angela commented on JCR-184:
----------------------------
hi brian
i worked on the escaping of those characters, that are valid with an uri but
are marked reserved with JSR170. apart from the solution proposed by tobi (i
tried that out finally), i considered a few more. neither seemed to provide a
satisfying result.
the overall summary: while it was basically possible to find a way to deal with
resources containing reserved characters in the name, all solutions bear some
risks.
the following considerations were involved:
- create resources with any uri compliant name
- create jcr items with valid names
- deal with any items that are present in the repository (even those that were
not created via webdav)
- possibility to decode itempath/itemnames in order not to produce
inconsistencies (PUT vs
subsequet PROPFIND). thus, the need for unambigous detection of jcr-encoded
characters.
- if possible, avoid garbeled item names
- easy encoding/decoding of a dav-resourcehandle/itempath. e.g. an easy
solution that does not
require exhaustive parsing, may ignore those characters, that are valid in an
item-path, but
illegal in a name ('/', '[', ' ]', ':', whitespace in certain position).
result:
none of the variants (i implemented the encoding proposed by tobi) fulfilled
all of the above criteria.
specially, i always found extra situations where the special handling of some
characters would potentially lead to ambiguity (or severe problems).
second i feel a bit concerned about an encoding/decoding that is present in the
webdav layer only (a translator between servletpath and itempath basically) and
could lead to problems (or at least strange results) with other applications
acting on the same repository.
to conclude:
my personal feeling is, that introducing that extra encoding in the
webdav-contribution, would rather decrease stability.
now, if you are really desperate without the ability to have a single quote in
your resource path, we should definitely discuss this again. but without the
urgent need, i would rather try to avoid to commit my modifications (at least
in the way i implemented it). i tried to deal with illegal characters in
webdav before and always experienced that workarounds finally caused other
issues.
thoughts?
kind regards
angela
> Simple Webdav: jcr-encoding for resource names contain invalid characters.
> --------------------------------------------------------------------------
>
> Key: JCR-184
> URL: http://issues.apache.org/jira/browse/JCR-184
> Project: Jackrabbit
> Type: Improvement
> Reporter: Brian Moseley
> Assignee: angela
> Priority: Minor
>
> jcr-server is a bit problematic in the way it treats the display name of a
> webdav resource. specifically it forces the display name to be the same as
> the name of the resource itself, rather than an arbitrary textual description
> of the resource. this is an acceptable default value for a resource's display
> name, but a webdav client should be able to change the display name at any
> point after creation of the resource.
> rfc 2518 says:
> 13.2 displayname Property
> Name: displayname
> Namespace: DAV:
> Purpose: Provides a name for the resource that is suitable for
> presentation to a user.
> Description: The displayname property should be defined on all DAV
> compliant resources. If present, the property contains a description
> of the resource that is suitable for presentation to a user.
> <!ELEMENT displayname (#PCDATA) >
> i realize that the goal of the simple webdav server is to support
> nt:collection and nt:file, which don't allow extra properties. that's fine; i
> have defined my own dav:collection and dav:resource node types on which i can
> add a dav:displayname property. i can then override
> DavResourceImpl.getDisplayName() to return the value of that property.
> the problem is that DavResourceImpl.getDisplayName() as already implemented
> has a couple of other purposes - calculating the resource name for a node
> that is about to be created and returning the resource name from an existing
> node.
> furthermore, both resource and display names could potentially contain
> characters that are illegal in jcr names. we've talked in the past about
> encoding these strings in order to use them as jcr names. this encoding would
> be necessary for the resource name (which is used as the node's name) but not
> for the display name (which would be persisted as a property value).
> i propose the following DavResourceImpl methods:
> getResourceName() - returns the (unencoded) name of the resource, which is
> either the name of the resource's node (if the resource exists) or the final
> segment of the resource's uri path
> getDisplayName() - returns the value of the resource's DAV:displayname
> property (if both the resource and property exist) or the string returned
> from getResourceName
> DavResourceImpl could simply always `return getResourceName()' as its
> implementation of getDisplayName(). subclasses would be free to override it
> to retrieve the display name from a jcr property.
> DavResourceImpl would also take care of encoding the resource name before
> creating the new node and decoding the resource name before returning it from
> getResourceName().
> thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
