I'm sending a request using Java. My path is constructed like this:
path = "http://server/" + obj + "?param=1"
Since obj can contain a space I'm using URLEncoder before that line: obj = URLEncoder.encode(obj, "UTF-8");
So if obj is "foo bar" the resulting path is: "http://server/foo+bar?param=1". Eg. Firefox converts "http://server/foo bar?param=1" to "http://server/foo%20bar?param=1". As far as I know both is correct.

I don't exactly know why, but RESTeasy Encodes the incomming URL again an decodes it after that. But it does. In org.jboss.resteasy.util.Encode.encodeSegment(String, boolean), line 137 (Version 1.1.GA) the path segments are encoded and in the result some special characters and escape sequences are replaced again:
result = URLEncoder.encode(segment, "UTF-8").replace("+", "%20").replace("%3B", ";").replace("%3D", "=").replace("%25", "%");
If a space is escaped with %20 (Firefox example) the URLEncoder repaces this to %2520, which is then replaced back to %20. See last replace in line above. So the URLDecoder at org.jboss.resteasy.specimpl.UriInfoImpl.UriInfoImpl(URI, URI, String, String, List<PathSegment>) line 44 (Version 1.1.GA) converts this correctly to a space again. So the corresponding PathParam is correctly "foo bar".

But if the space is represented as '' this does not work. The URLEncoder converts this to %2B which is not replaced back. So the URLDecoder replaces it with '' and the corresponding PathParam hast the wrong value of "foo+bar".

Imho RESTeasy should handle both escapes of a space '+' and '%20'.

PS.:
In current trunk (Rev 851) the URLEncode.encode has moved to line 150 but not changed. So I think the problem is still present, but I didn't test it.