RequestInfo.getPath() should be URL decoded

[Nic Munroe]

Currently RequestInfo.getPath() returns the path as it was sent into the server (minus the query string) - this means any URL encoding in the path is not automatically decoded. A side effect of this is that path parameter values are also not automatically decoded.

We should fix this so that RequestInfo.getPath() is automatically URL decoded, and that path parameter values are similarly decoded. We can fix both issues at once by modifying this line of code: https://github.com/Nike-Inc/riposte/blob/master/riposte-spi/src/main/java/com/nike/riposte/server/http/impl/RequestInfoImpl.java#L99

Instead of this.path = HttpUtils.extractPath(uri);, that line should read this.path = QueryStringDecoder.decodeComponent(HttpUtils.extractPath(uri));, with QueryStringDecoder being the Netty io.netty.handler.codec.http.QueryStringDecoder. As the javadocs for QueryStringDecoder.decodeComponent(...) state, this is equivalent to Java's built-in URLDecoder.decode(...) method, just faster and with less garbage for the GC to collect.

It makes sense that RequestInfo.getUri() should stay untouched and provide the raw value passed into the server. So in addition to the line of code mentioned above to fix the issue, whoever fixes this should update the RequestInfo.getUri() and RequestInfo.getPath() javadocs to indicate that getPath() is automatically URL decoded, but getUri() is not decoded.

And of course RequestInfoImplTest should include unit tests that verify getPath() and path params are properly decoded, and getUri() is left encoded. RequestInfoImplTest's setPathParamsBasedOnPathTemplate_works_as_expected(...) method could have a few dataprovider cases added to prove the path params part, and uber_constructor_works_for_valid_values() and netty_helper_constructor_populates_request_info_appropriately() could probably be modified to prove getPath() is decoded while getUri() is not.

[Nic Munroe]

@rabeyta version 0.8.2 has been released with these changes. Thanks for the fix!