On Jul 15, 2009, at 2:08 PM, Martin Probst wrote:
>> Note that it is the '{' character that is causing the issue in the
>> example
>> you presented. If you remove the '{' and '}' then it should work.
>
> Ah, overlooked it. But the slash should be illegal as well in 2396,
> I think:
>
> "Within a query component, the characters ";", "/", "?", ":", "@",
> "&", "=", "+", ",", and "$" are reserved."
>
> Even though that does work in URI.create(...). Or am I
> misunderstanding the meaning of "reserved" here?
>
No, java.net.URI does not do what it says it does :-)
> I have read a bit more, and { and } are always disallowed in any of
> the RFCs.
Where does it state that in RFC 3986? i looked but could find anything
related to the reservation (or unwise use) of such characters.
> So this is simply another case of browsers consistently and
> very annoyingly implementing something which is not the spec. Though
> java.net.URI doesn't seem to be that much better...
>
>> The way to fix this (which may related to another issue with '{'
>> and '}'
>> in paths but is likely to be harder to fix because of the way
>> java.net.URI
>> is utilized) is for the UriBuilder implementation to have a mode
>> where by
>> '{' and "}' characters are not treated as syntax for template
>> parameters.
>> Then when Jersey builds the URI and adds the query parameter
>> the '{' and "}' characters will get percent encoded.
>
> I don't quite understand where or why the UriBuilder comes in - this
> happens when Jersey simply gets hit by an HTTP request with an illegal
> URI - I'm not constructing such a URI inside Jersey. If I try passing
> in curly braces to a URI builder, all is fine:
>
Because the Jersey ServletContainer builds the base and request URIs
using UriBuilder.
> URI uri = UriBuilder.fromPath("x").path("{x}").build("h{ll");
> System.out.println(uri);
>
> Gives:
>
> x/h%7Bll
>
> But you certainly know that better ;-)
>
Try:
URI uri = UriBuilder.fromPath("x").path("{x}").build();
Or:
URI uri =
UriBuilder.fromPath("x").replaceQuery("xquery=<res>{count(//
*:dependency)}</res>").build();
The problem is UriBuilder assumes '{' and '}' are syntax for template
parameters, thus they are not encoded, even when no template values
are supplied.
>> Would you mind logging an issue?
>
> Sure.
Thanks.
> But I just noticed something even odder. If you create an HTML
> form that uses GET, everything works fine, both in Safari and Firefox.
> So if you just type something into the address bar it gets escaped
> incorrectly (but some things do get escaped!), if you use an HTML form
> the browser behaves correctly. Shouldn't this be the same code path?
It should. I guess the latter is using URI processing of the HTML
libraries. Might be worth logging a bug against Firefox?
> Weird.
>
> Why must everything related to browsers be that painful?
>
:-) i call it the wild wild web.
Paul.