A related issue is what to do with:
UriBuilder.fromPath("a").segment("b/{foo:.+}").build("c/d")
I think the builder should do context-sensitive encoding of the value
before doing anything with the regex so you'd get:
a/b%2fc%2fd
rather than
a/b%2fc/d
whereas
UriBuilder.fromPath("a").path("b/{foo:.+}").build("c/d")
would yield
a/b/c/d
Marc.
On Jul 31, 2008, at 11:23 AM, Marc Hadley wrote:
> On Jul 29, 2008, at 9:37 AM, Paul Sandoz wrote:
>
>> Manger, James H wrote:
>>> The latest UriBuilder looks pretty good.
>>> One aspect that isn’t clear (or isn’t how I would like it) is how
>>> a placeholder in a @Path value is treated.
>>> What does the following create?
>>> UriBuilder.fromResource( @Path(“widget/{id}/info”) ).build(“X/123”)
>>> 1. “widget/X/123/info”; or
>>> 2. “widget/X%2F123/info”
>
> Currently 1.
>
>>>
>>> @Path explicitly states that {id} is a segment (not a path) for
>>> matching. That is, it matches [^/]+ so %2F is ok, but ‘/’ is not.
>>> UriBuilder really needs to treat it the same way. In this case the
>>> path(Method), path(Class), and path(Class, String) methods will
>>> escape a placeholder as a segment, while the path(String),
>>> fromPath(String) and replacePath(String) methods will escape a
>>> placeholder as a path.
>
> I don't see why path(@Path("{foo}")) should be treated differently
> to path("{foo}"). In the ideal case either method should escape the
> value of foo according to its regex (either explicit or implicit)
> not based on where the template comes from.
>
>>> I think that is too confusing for such a common case.
>>> First, I suggest renaming the path(Method), path(Class), and
>>> path(Class, String) methods to resource(…) as an explicit
>>> indication that they escape placeholder values differently than
>>> other *path(…) methods – and for consistency with
>>> fromResource(Class).
>>>
>>
>> Good suggestion for renaming to be consistent.
>>
> I'd rather rename fromResource to fromPath so that the method name
> reflects the URI component being affected, but I think the current
> naming is also fine.
>
>>
>>> Second, I suggest the resource(..) methods make some effort to
>>> handle a regex in a @Path placeholder – without requiring JAX-RS
>>> implementations to understand arbitrary regular expressions.
>>> Possible text:
>>> “For each placeholder in a @Path value:
>>> 1. If there is no regex, treat it as a segment placeholder (%-
>>> escape
>>> ‘/’s);
>>> 2. If the regex is “.*” or “.+”, treat it as a path placeholder
>>> (don’t escape ‘/’s);
>>> 3. For any other regex, %-escape all non-unreserved characters.
>>> A JAX-RS implementation MAY relax the 3^rd rule above by not %-
>>> escaping characters that it knows are allowed by the regex. An
>>> application should not rely on a JAX-RS implementation to
>>> recognize such situations.
>>> A UriBuilderException shall be thrown if a placeholder value
>>> (after %-escaping) does not match the regex given in a @Path
>>> placeholder.”
>>>
>>
>> Need to think about this a little more about the above. I am not
>> sure i like the processing of certain regexes. It may be simpler to
>> validate the value against the regex and reject if it does not
>> match rather manage the encoding or not of '/'.
>>
> I'd also prefer to validate against the regex rather than requiring
> the implementation to parse the regex. Encoding based on specific
> regex values is bound to cause issues when a developer starts to use
> more specific regex values and I think its too onerous to require
> implementations to be able to parse an arbitrary regex and formulate
> an encoding scheme to match.
>
> That said, I'm actually OK with the status quo where the onus falls
> on the developer to supply values consistent with the path vs path
> segment distinction.
>
> Marc.
>
>
>>
>>> I think those rules should not be too onerous to implement. After
>>> some more experience some common regexs for @Path values may
>>> emerge. A future version of JAX-RS could easily extend the above
>>> rules to require support for additional regexes – or they just get
>>> implemented in most JAX-RS implementations so applications can
>>> rely on them anyway. An implementation that tries escaping
>>> different reserved char until the regex matches may even be
>>> feasible.
>>> James Manger
>>>
>>
>> --
>> | ? + ? = To question
>> ----------------\
>> Paul Sandoz
>> x38109
>> +33-4-76188109
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.