> 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?
I have read a bit more, and { and } are always disallowed in any of
the RFCs. 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:
URI uri = UriBuilder.fromPath("x").path("{x}").build("h{ll");
System.out.println(uri);
Gives:
x/h%7Bll
But you certainly know that better ;-)
> Would you mind logging an issue?
Sure. 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?
Weird.
Why must everything related to browsers be that painful?
Martin