Awesome -- thanks so much! On Dec 18, 2009, at 12:01 PM, Sergey Beryozkin wrote:
> Hi John > > URITemplate was not escaping '*', which alongside with '.' seems to be the > only two characters are also used as reserved characteres > in regexs, '-' seems tp be ok... Fixed on mainline > > thanks for raising this issue and please continue stressing the CXF JAXRS > with some real-world URIs :-) > > cheers, Sergey > > ----- Original Message ----- From: "John Klassa" <[email protected]> > To: "Sergey Beryozkin" <[email protected]> > Cc: <[email protected]> > Sent: Friday, December 18, 2009 2:05 PM > Subject: Re: bug in URITemplate? > > > > Hi Sergey, > > By way of background, the result of pdq.getName() isn't something that goes > through the CXF machinery until this point in time (when I want to put it > into a URI). I fetch it from a back-end database, and then want to put it > into a URI to use in an xlink. Put differently, it's not something I get > from a query parameter (for example), and could preserve an encoding on. > It's just a value that needs to go into a URI (the URI for a "search" > resource, in my case, is "/search/{USERNAME}/{NAMEOFSEARCH}"). > > (I'm actually running into this same thing on the unit test side, as well, > when I try to use WebClient to fetch a URI with a "*" in it. In particular, > when the server side generates an xlink URI with a "*" in it, and my unit > test code fetches the contents of that URI in order to make sure that the > xlink points to the right thing, it bombs. See attached ZIP file with test > case in it.) > > I'd actually tried HttpUtils.pathEncode() already, as in: > > ...path(HttpUtils.pathEncode(pdq.getName()))... > > but pathEncode() doesn't encode the "*". As a workaround, I'd been turning > "*" into "SOMETHINGUGLY" prior to the UriBuilder.path() call, then building > the URI, then turning "SOMETHINGUGLY" back into "*" in the final URI. That > works (on the server end of things), but doesn't seem "right". :-) On the > client side, it still causes a bomb (per my previous paragraph), unless I > then go so far as to manually turn "*" into "%2A". Only then can my unit > test code successfully fetch the resulting URI. > > It seems that "*" is a legitimate URI character (see section 2.3 of > http://www.ietf.org/rfc/rfc2396.txt). So, pathEncode() seems to be doing the > right thing by not encoding the "*". I'm just not sure how to get CXF to > take it, and use it in a URI, without the "something ugly" workaround I > described... And again, that applies to both server- and client-level code > (because WebClient seems to use UriTemplate, as well). > > Thanks! > JK > > > > > -------------------------------------------------------------------------------- > > > > > On Dec 18, 2009, at 8:21 AM, Sergey Beryozkin wrote: > >> Actually, the problem seems to do with the fact that UriBuilderImpl has >> assumed that unencoded >> >> "** Web Query" contains template variables... >> >> pdq.getName() returns a decoded (query sequence). >> >> One possible option is to add @Encoded to the corresponding QueryParam >> declaration and then pass this (still encoded) value to UriBuilder but the >> problem here is that some of the characters which may not be valid in >> queries and thus are encoded may be valid in path components, so no need to >> encode them there. It should still work though... >> >> See, if UriBuilder.path(String value) will attempt to encode the value then >> it may loose the information about the template parameters a given path >> value may contain. ex, "bar{id}". >> >> So try either preserving the encoded information, when getting it from the >> query param, or do >> >> builder.path(org.apache.cxf.jaxrs.utils.HttpUtils.pathEncode(pdq.getName())); >> >> cheers, Sergey >> >> >> >> >>> Hi John >>> >>> If encoded values are present then you need to use >>> UriBuilder.buildEncoded() >>> >>> give it a try please. CXF JAXRS proxy-based api always uses >>> UriBuilder.buildEncoded() >>> >>> Sergey >>> >>> ----- Original Message ----- From: "John Klassa" <[email protected]> >>> To: <[email protected]> >>> Sent: Thursday, December 17, 2009 1:32 PM >>> Subject: bug in URITemplate? >>> >>> >>> >>> This code: >>> >>> return getBaseURI(info) + UriBuilder.fromResource(SearchResource.class) >>> .path(pdq.getOwner()) >>> .path(pdq.getName()) >>> .build() >>> .toString(); >>> >>> dies thusly: >>> >>> java.util.regex.Pattern.error(Pattern.java:1713) >>> java.util.regex.Pattern.sequence(Pattern.java:1878) >>> java.util.regex.Pattern.expr(Pattern.java:1752) >>> java.util.regex.Pattern.compile(Pattern.java:1460) >>> java.util.regex.Pattern.<init>(Pattern.java:1133) >>> java.util.regex.Pattern.compile(Pattern.java:823) >>> org.apache.cxf.jaxrs.model.URITemplate.<init>(URITemplate.java:89) >>> org.apache.cxf.jaxrs.impl.UriBuilderImpl.substituteVarargs(UriBuilderImpl.java:131) >>> org.apache.cxf.jaxrs.impl.UriBuilderImpl.doBuild(UriBuilderImpl.java:80) >>> org.apache.cxf.jaxrs.impl.UriBuilderImpl.build(UriBuilderImpl.java:74) >>> com.cisco.cdets.wsapi.resources.SearchResource.buildURI(SearchResource.java:132) >>> >>> when the getName() call happens to return something like "** Web Query" >>> (with asterisks). I had assumed that the CXF methods would URL escape the >>> information I pass in, in situations like this... I'm guessing that's >>> either not the case, or perhaps there's a bug? >>> >>> As a best practice, in general, should I be escaping these sorts of values >>> myself? >>> >>> FWIW, I'm using CXF 2.2.3. >>> >>> Thanks! >> > >
