<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 4/20/16 12:38 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128BD2B4@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">I would imagine the only real reason to even do the conversion at all is to enforce the schemes allowed without us implementing any URL parsing, which I'm all for.
</pre>
</blockquote>
<br>
Yeah, that's apparently the only reason it's doing that, in both v2
and v3. <br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128BD2B4@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
The old code base does a pretty aggressive conversion of the original URL into a java.net.URL, then pulls all the individual pieces out one by one (including the query parameters) inside a URLBuilder custom class, and then reconstructs the whole thing. There's no chance a dangling unencoded equals sign would survive that.
The V2 code was very clearly not warranted, but that's water under the bridge since it was thrown out.</pre>
</blockquote>
<br>
Agreed, it's very gratuitous. Looking at the history, originally v2
didn't do that with the URLBuilder. It just worked entirely with,
and returned, String values. When the support for checking allowed
URL schemes was added after the fact, in 2009, that's where the
URLBuilder stuff was introduced. It's weird because the scheme
check is done right in the same method that returns the endpoint
URL, so there really wasn't any reason to change the type that was
returned (which btw was a breaking API change and shouldn't have
been allowed in a patch or minor release...). It could have just
done the parsing and scheme check using the URLBuilder internally,
but still returned the original String. But, too late now.<br>
<br>
</body>
</html>