On Jul 15, 2008, at 11:33 PM, Manger, James H wrote:
>
> First, I better clarify a major assumption.
> I have been assuming that a percent character will be escaped when
> encode=true.
> UriBuilder.fromPath("abc%2Fdef", true) -> "abc%252Fdef"
> Is this correct? It seems to be what Jersey does, but the spec is
> not totally clear. The spec (javadoc) talks about "automatic
> encoding of illegal characters". Percent characters are not illegal
> in URIs -- as long as they are followed by a pair of hex digits.
>
Yes, with encode=true, the intent was that '%' would be encoded to %25.
>
> As an alternative way of explaining my point, consider what would
> happen if encode=true mode did NOT escape '%' characters.
> * 99.99% of encode=true usage is unchanged as raw '%' chars are
> rarely used in URIs.
> * For the remaining usage, the developer has to write "%25" instead
> of "%".
> * For handling "uncontrolled" input, the chars that can cause
> problems goes from 2 {} to 3 {}% -- which cannot make it materially
> harder. If fact, handling "uncontrolled" input becomes much easier.
> The caller can escape these 3 chars then keep using encode=true mode
> (to take care of the context-sensitive & i18n encoding). With the
> current modes the caller has to switch to encode=false mode.
> Consequently, they have to do all the context-sensitive and i18n
> encoding themselves.
I kind of imagined that uncontrolled input would be inserted into URI
as the values of URI template variables rather than directly as URI
components. If this is true then the presence of {} is unlikely to
cause an issue. The same applies to % since all three chars would be
encoded if encode=true. If you wanted to allow uncontrolled input to
include pct-escaped chars as well as other chars that aren't legal
then you would have to do some manual processing but I don't see that
as a common use case - it seems more common that strings are either
completely encoded or not encoded at all. Could you suggest some use-
cases where the change you suggest would improve the developer
experience.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.