users@jsr311.java.net

Re: JAX-RS: UriBuilder encoding

From: Stephan Koops <Stephan.Koops_at_web.de>
Date: Fri, 18 Jul 2008 12:18:25 +0200

Hi James,

I think
UriBuilder.fromPath(s.replaceAll(“%”, “%25”));
is boilerplate code, that we should avoid. And it is not realy easy to
use. If you have data from the database or whereever, and it contains a
percent sign, followed by to hex digit signs, than it should be possible
to directly put them into the UriBuilder without the boilerplate code.

Let's see, what the others think.

best regards
   Stephan

Manger, James H schrieb:
>
> > Perhaps … a third mode is useful? I know, it makes it more
> complicated, but I think we need it:
>
>
>
> NO.
>
>
>
> A UriBuilder.quote(String) static method can %-escape all unreserved
> chars, ensuring the input provides “content” – not “structure” – to a URI.
>
> A mode that does not %-escape percent signs allows the caller to build
> every possible valid URI.
>
>
>
> The remaining modes add too little to warrant any complications.
>
>
>
> If a caller really wants to escape percent chars as well, just change:
>
> UriBuilder.fromPath(s);
>
> to
>
> UriBuilder.fromPath(s.replaceAll(“%”, “%25”));
>
>
>
> If a caller really wants an exception if non-uri chars are present:
>
> if (!s.matches(“[-._~a-zA-Z0-9:/?#[\\]@!$&’()*+,;=%]*”))
>
> throw new IllegalArgumentException();
>
>
>
> Hence, if the API just supports mode 3, a caller can still implement
> modes 1 & 2 without much code – if they really need to, which I
> believe will be extremely rare.
>
>
>
> James Manger
>
> ------------------------------------------------------------------------
>
> *From:* Stephan.Koops_at_web.de [mailto:Stephan.Koops_at_web.de]
> *Sent:* Thursday, 17 July 2008 7:20 PM
> *To:* users_at_jsr311.dev.java.net
>
>
>
> Hi James, hi Marc,
>
>
> Perhaps we a third mode is useful? I know, it makes it more
> complicated, but I think we need it:
>
> 1. no encode, only check (same as current false)
> 2. encode everything, including '%' (what Marc intended for true)
> 3. encode everything excluding valid percent encoded values
> (suggestion of James and also my understanding of true)
>
>
> It could be explicit documented in the javadoc, that the both last
> are equivalent, if no percent char is available. This reduces fear
> of complexity by app developers.
>
> Marc, if I remeber right, you talked about a next API version.
> When should it come? Is it right, that this should not change?
>