Implicitly Decodes Encoded URIs

[Dominic Visco]

Not sure if this is to be expected but the HttpRequest.parseUri method is using the getPath() method of java.net.URI instead of getRawPath(). This presents a problem in two places:

1. In AbstractHttpClient.run the request is cloned which triggers another call to HttpRequest.parseUri from HttpRequest.setUri on the new Cloned Object but this will receive the decoded path. This will throw an exception if the original uri required encoding to prevent a URISyntaxException from occuring
2. Also within JerseyHttpClient.doExecute the client.resource call is passed the decoded URI which will throw an exception as well if the decoded URI required encoding.

Maybe I am missing something but I can't see how else to get around the issue given the API provided. I ended up having to extend the HttpRequest class and override the calls to clone and parseUri while using reflection to access the uri field.

[Bud Byrd]

I know it's been a while for this issue, but do you have an example to reproduce? I'm looking at this for 2.0, and I cannot reproduce the issue (at least the one specific to cloning).

I've tried the following, still using .getPath():

def 'this should fail, but it does not'() {
    setup:
    HttpRequest request = new HttpRequest('http://localhost/the+bads')

    when:
    request = (HttpRequest) request.clone()

    then:
    request.getUri() == 'http://localhost/the+bads'
}

Maybe some of the restructuring has fixes this, but the request object still clones itself the same way, so I'd think it would behave the same. Am I missing something?

[Bud Byrd]

Digging through the code, I found the issue is caused when paths have character escaping (encoding starts with '%'). I reproduced the issue and submitted a fix that will be present in 2.0. Thanks for the report!

[Dominic Visco]

No problem thanks for the lib!