On Jun 1, 2010, at 9: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.
It is not clear to me what the are different implementation
requirements with UriBuilder for the two RFCs. We are anyway limited
to what java.net.URI supports.
> 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.
>
Yes.
>
> 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).
>
Yes, proxies can be an issue. Since there is no canonical ordering of
query parameters in a query component it can result in multiple URIs
for the same resource state.
My general rule of thumb for query component is to ask the question
"would happen if you removed the query component and do a GET?". If a
query component is required it may be an issue but it can be framework
dependent. JAX-RS matches on paths not query parameters.
Paul.