In an attempt to summarize our options and the requirements (as I
understand them):
Requirements:
* Path element must be URL safe
* Path element must not be ambiguous
* Path element must not restrict the URL namespace further
* Solution must be generic so it may be applied to any other
use-case with invalid URL characters
* Solution should be as natural & simple as possible to REST developers.
Options for '/' within REST path element:
* .../management/domain/resource/admin-object-resource/jndi/foo/property
o Security Concerns: ??
o Client Coding issues: None.
o Readability: OK (JNDI name may be confused for part of the path)
o Ambiguous: Yes (JNDI slashes are not distinguishable from
the path elements)
o Other Issues: Just the ambiguity.
* .../management/domain/resource/admin-object-resource/jndi%2Ffoo/property
o Security Concerns: ??
o Client Coding issues: Must call urlencode on JNDI name
(simple & expected)
o Readability: Good
o Ambiguous: No
o Other Issues: Grizzly may not allow %2F???
* .../management/domain/resource/admin-object-resource/(jndi/foo)/property
o Security Concerns: ??
o Client Coding issues: Must know to put parenthesis "()"
around JNDI name and to NOT urlencode it.
o Readability:
OK. This is not a typical solution so it looks funny. '/'
inside ()'s
may be confusing (looks like 2 tokens: "(jndi" and "foo)".
o Ambiguous:
No. However, you need to know the special rules to read it
correctly
(i.e. ()'s have higher precendence than '/'). This is not a
standard
and will be confusing.
o Other Issues: None.
* .../management/domain/resource/admin-object-resource/jndi%252Ffoo/property
o Security Concerns: Nothing known.
o Client Coding issues:
Must call urlencode on JNDI name 2x. This may be confusing
as to why it
must be called 2x. However, it is simple to implement since
it uses a
standard encoding.
o Readability: OK. Will be confusing that it is encoded 2x
instead of the standard of 1x.
o Ambiguous: No
o Other Issues: None.
* .../management/domain/resource/admin-object-resource/property?jndiName=jndi_at_
o Security Concerns: Nothing known.
o Client Coding issues: Must call urlencode on JNDI name
(simple & expected); must add a Query String parameter.
o Readability: OK (see other issues)
o Ambiguous: Yes (see other issues)
o Other Issues:
Query String parameters are not ordered in Java and cannot
be related
to a particular path element easily. This does not provide
good a
general solution to allowing '/' characters in path
elements. It makes
it difficult to read the path as a relative path identifying
a single
object. It also may be ambiguous if more than 1 path element
needs to
allow '/' in its name.
I look forward to discussing this at the admin iteam...
Ken
On 06/01/2010 12:00 PM, Bruno Harbulot wrote:
>
> On 01/06/10 17:23, Paul Sandoz wrote:
>
>>> On 01/06/10 11:47, Andreas Loew wrote:
>>>> Hi Paul,
>>>>
>>>> Paul Sandoz schrieb:
>>>>
>>>>>> Not quite: '{' and '}' are just "unsafe" characters,
>>>>>
>>>>> They are disallowed in the URI syntax:
>>>>>
>>>>> http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.2.4.3
>>>>
>>>> while I don't want to argue with you about the subtleties of the fact
>>>> that curly brackets are *not* part of *neither* "reserved" *nor*
>>>> "unreserved" characters, it seems to me that the following would be
>>>> fully sanctioned by the spec:
>>>>
>>>> .../management/domain/resources/admin-object-resource/(jndi/foo)
>>>>
>>>> because "normal" brackets are "unreserved" characters: "Data
>>>> characters
>>>> that are allowed in a URI but do not have a reserved purpose are
>>>> called
>>>> unreserved."
>>>>
>>>> So how about wrapping resource values that contain "reserved"
>>>> characters
>>>> by a pair of (unreserved) "normal" brackets '(' and ')'?
>>>
>>> I'm not sure whether you want to take more recent RFCs into
>>> consideration, but in RFC 3986, which obsoletes RFC 2389,
>>
>> Good point. I was using the URI spec that is referenced by HTTP 1.1
>> (maybe the work on tidying up the HTTP spec will update the reference?)
>>
>>
>>> parentheses are reserved characters:
>>>
>>> http://tools.ietf.org/html/rfc3986#section-2.2
>>>
>>> Section 2.4 is probably relevant to this discussion too (especially
>>> its last sentence).
>>>
>>
>> I am not sure what the last sentence actually means in terms of parsing
>> a URI :-) but i strongly suspect for HTTP schemes and the path component
>> that '(' and ')' are OK. Jersey does not encode such characters when URI
>> building path components e.g.:
>>
>> URI u = UriBuilder.fromPath("/(xxx/yyy)/zzz").build();
>>
>> BTW IIRC Microsoft's Astoria uses '[' and ']' for delimitation and those
>> are percent encoded.
>>
>> It would be so much easier if we could use %2F !
>
> I guess Jersey might not follow the newer RFC.
> What I meant with the relevance of the last sentence of section 2.4,
> is that it more or less implies that, once the path components
> (separated with '/' have been split) and %2F decoded, further tools in
> the dispatch chain shouldn't split them further.
>
> I wasn't aware of the security issue with %2F and proxy servers, but
> it sounds more like a case of fixing the way the server behind the
> proxy interprets them when it shouldn't.
>
>
> Coming back to the original problem... To be honest, I don't use
> Glassfish every day so I'm not sure whether I'm going to go off topic
> here, but from a REST point of view, there's no such thing as a
> RESTful URI (and I think no one had used that expression in the thread
> so far, so no problem here ;-) ).
>
> This is a question that often comes back on the rest-discuss list, but
> the important point in REST is how you can link and get the resources.
> Considering that the query part is an integral part of the URI
> (although some implementations don't necessarily view it this way),
> these two elements are more or less equivalent in terms of "URI
> RESTfulness":
> <a href="http://myblog.example/pages/1">First page</a>
> <a href="http://myblog.example/?page=1">First page</a>
>
> People often think that RESTful systems must have "RESTful URIs" that
> are query-free. That's not strictly true as far as the REST constraint
> are concerned from a theoretical point of view.
> It's mostly an aesthetic matter, which is frankly barely relevant if
> you follow the hypermedia constraints of REST. Having a query in the
> URI is often a bad sign when the parameters symbolise actions (e.g.
> "?action=delete"), so that's probably why they're often discouraged.
>
> Whilst
> <http://localhost:4848/management/domain/resources/admin-object-resource/jndi-foo?convertDash=true>
> could be considered as symbolising an action (arguable, since it
> clearly wasn't the intent),
> it sounds like
> <http://localhost:4848/management/domain/resources/admin-object-resource/?resource=jndi%2Ffoo>
> would be just fine.
>
> Where having a query part or not matters is in terms of
> implementation, regarding how the query is dispatched to whatever
> needs to process that query. That's of course where the problem is
> here. I think the two main downsides of using a query are that not all
> proxy cache the requests with queries and that it also makes it harder
> to use another query on that resource or to build a sub-hierarchy (I'm
> not sure if it would be the case here).
>
>
> Best wishes,
>
> Bruno.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>