Community
Participate
Working Groups
This method in HttpFileRetrieveTransfer: protected static int getPortFromURL(String url) { final int colonSlashSlash = url.indexOf("://"); //$NON-NLS-1$ final int colonPort = url.indexOf(':', colonSlashSlash + 1); if (colonPort < 0) return urlUsesHttps(url) ? HTTPS_PORT : HTTP_PORT; final int requestPath = url.indexOf('/', colonPort + 1); int end; if (requestPath < 0) end = url.length(); else end = requestPath; return Integer.parseInt(url.substring(colonPort + 1, end)); } Does not do a good job when the url is malformed. As an example - try feeding it "http:bogus". The result is that it tries to transform "bogus" to a port number - with a NumberFormatException as the result. Insert this after the first line in the method to correct it; if(colonSlashSlash < 0) return urlUsesHttps(url) ? HTTPS_PORT : HTTP_PORT; Since it is not meaningful to try to look for a port if there is no :// in the URL. Have not searched if there are similar methods in other transfer protocols. The methods getHostFromUrl, and getPathFromUrl have similar problems on malformed URLs as they start searching for "/" from a position -1 + 3.
Hi Hendrik, I'm not opposed to making things more robust but the String url is actually retrieved from the URL instance (e.g. line 441 in HttpClientRetrieveFileTransfer: final String urlString = getRemoteFileURL().toString(); the URL instance returned by getRemoteFileURL() is provided by the IFileID in the initial request...so it's been through the URL parser...which I'm assuming will/should prevent any malformed urls. So, in any event...were you able to trigger an exception in the ECF code somehow by passing in a valid IFileID?
In p2 the ECFFileTransport.download receives a String that it passes on. If this String lacks "://" it is still a valid URL, but the getPortForURL() method does not handle this case. So, I was wrong in saying it was an invalid URL, just not a URL that getPortForUrl() does a good job in translating - it will trigger a NumberFormatException. Try it with "http:bogus" for instance - it thinks that ":bogus" is a port number.
(In reply to comment #2) > In p2 the ECFFileTransport.download receives a String that it passes on. If > this String lacks "://" it is still a valid URL, but the getPortForURL() method > does not handle this case. > > So, I was wrong in saying it was an invalid URL, just not a URL that > getPortForUrl() does a good job in translating - it will trigger a > NumberFormatException. > > Try it with "http:bogus" for instance - it thinks that ":bogus" is a port > number. > I didn't realize http:bogus was a valid URL...learn something new everyday. Thanks.
(In reply to comment #3) Henrik...were you thinking of creating a patch for these specific cases? Or should I assign to myself and do it?
(In reply to comment #4) > (In reply to comment #3) > > Henrik...were you thinking of creating a patch for these specific cases? > > Or should I assign to myself and do it? > Well, the fix to the immediate problem is to insert two lines... as described in the first post. I can produce a patch if that helps you.
Applied suggested checks to HttpclientRetrieveFileTransfer.getPortFromURL, getHostFromURL, getPathFromURL. Thanks Hendrik. Resolving as fixed.
