Re: URL context constructor broken?
On 12/30/2010 08:20 AM, Roedy Green wrote:
There in a URL constructor that takes an context url and a relative
String. It is supposed to merge them into a new URL. It mostly
works, but fails on this list of real world examples with a
MalformedURLException. I am trying to analyse the location field in an
http redirect and apply it to the original URL.
Are these bugs, or "features"?
[long list of URL "additions" elided]
According to the docs for the constructor to which you refer, "If the spec's
path component begins with a slash character "/" then the path is treated as
absolute and the spec path replaces the context path."
In your example,
http://new.myfonts.com/fonts/linotype/frutiger/ +
/fonts/adobe/frutiger/
the "spec" is "/fonts/adobe/frutiger/". The resulting URL from
new URL( "http://new.myfonts.com/fonts/linotype/frutiger/",
"/fonts/adobe/frutiger/" )
should have been
"http://new.myfonts.com/fonts/adobe/frutiger/" as I read the docs.
'MalformedURLException' is only documented to occur "if no protocol is
specified, or an unknown protocol is found." But the protocol is present in
the context, so it should be that "the scheme component is inherited from the
context URL." Likewise, "[i]f the authority component is absent in the spec
then the authority of the new URL will be inherited from the context."
The key seems to be in the phrase ??[i]f the spec's path component begins with
a slash character "/"??. How does the constructor decide what is the "path
component" of the spec? Maybe it thinks that the authority is "fonts". If so
it might be trying to construct the URL "http://fonts/adobe/frutiger/", which
does contain a scheme but looks pretty malformed to me.
I didn't look through the source for 'java.net.URL', so obviously I'm
speculating, but absent seeing your actual constructor calls (SSCCE anyone?)
I'm guessing "bug".
--
Lew
Ceci n'est pas une pipe.