Hello,
We have a REST request that we'd like to use with a @PathParam that contains an absolute URL. For this to work, the path param must be URL encoded, otherwise slashes in the parameter will cause RESTEasy (and potentially other JAX-RS implementations?) to get thrown off when trying to match the incoming request to a java method. As far as I can tell, this used to work until issue #184 was raised. The change for this issue was to always encode path params (existing behavior) unless the param is an absolute URL (the new behavior). It seems to me that the user requesting this change put forth a bogus use case and that the implementation is flawed.
Regarding the use case, it appears that ahumellihuk was attempting to make use of a path param to dictate the full URL that the request went to. The proper solution in that case would have been to change the service root (Defaults.setServiceRoot). Using a path param to dictate the scheme/host/port that a request goes to was never the right thing to do since a path param is, as the name implies, part of the path and not the full URL. Further, there was no followup from the user that reports whether the change worked as they hoped, but I suspect that it did not.
I say that the implementation is flawed because all it checks is whether a path param starts with "http". This means that any string, regardless of whether it is actually an absolute URL as the fix intended to handle, does not get URL encoded. This can also put you in a situation where a string like "http/moreText" throws off path matching at the server since the slash won't be encoded.
I plan on putting up a new PR soon that reverts the change introduced for issue #184, but figured I'd post here first to make sure there isn't something I'm overlooking.
Craig