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.