GenericUrl does not handle path segment encoding properly

[kilink]

GenericUrl cannot handle URLs with path segments where keys or values contain reserved characters such as semicolon, equals, or comma.

Example URL:

http://example.com/index.html;foo=ba%3Br%3B%21;baz=quux

After passing to GenericUrl:

http://example.com/index.html;foo=ba;r;!;baz=quux

Note that the value of the foo parameter has now been mangled due to the decoding of %3B to ";". It would now be impossible for a server or other client to parse this URL correctly.

GenericUrl is the only way to specify a URL using the Google HTTP client. GenericUrl also does not allow any customization of escaping behavior or overriding of its build method. Due to this inflexibility, the client is not capable of interacting with servers that require supplying data via path segments if any of the values contains a reserved delimiter character.

Frankly, I do not understand why GenericUrl attempts to fiddle with the passed in URL in such a manner, particularly if a URL or URI object is passed in. It is also frustrating that there is no possible way for consumers to work around this issue, since we are forced to use the concrete GenericUrl class, which does not allow extension.

I'd like to see this issue fixed, but furthermore, as other issues have suggested, why not open up GenericUrl? Perhaps make it an interface with simpler implementations that allow one to supply an unmolested URL directly. Another option is to allow one to supply a URL object to HttpRequest / HttpRequestFactory.

Code example where URL is built using UriTemplate:

String url = UriTemplate.expand("http://example.com/index.html",
            "{;keys*}",
            ImmutableMap.of("keys", ImmutableMap.of("foo", "ba;r;!", "baz", "quux")),
            false);
// url == http://example.com/index.html;foo=ba%3Br%3B%21;baz=quux
GenericUrl genericUrl = new GenericUrl(url);
// genericUrl.build() or genericUrl.toString() == http://example.com/index.html;foo=ba;r;!;baz=quux

[corydolphin]

Is there any way to work around this? I'm hitting the same issue, and would prefer not to have to change HTTP client implementations.

[mattwhisenhunt]

Duplicate of #398