Community
Participate
Working Groups
Build Identifier: M20110909-1335 When you create a connection in Remote Tools (or RSE for that matter), the connection name should be restricted to the characters that are allowed by RFT-952 (and amended by RFC-1123). I'm asking for this because we end up with URI's that look something like: remotetools://<connection-name>/<path-to-resource> If I instantiate a URI based on one of these strings, the URI class will throw a URISyntaxException if the connection-name contains embedded blanks or other disallowed characters, such as underscores. The above RFC's accurately detail the syntax rules of the allowed host names. In addition to enforcing the above rules, changing the connection creator will also require changing the default connection name, which is currently "Remote Host" (notice the embedded blank). Perhaps it could be "RemoteHost". Note that RSE has the same problem, and I will be filing a bugzilla against it as well. Reproducible: Always Steps to Reproduce: N/A
Correction: (In reply to comment #0) .... > > When you create a connection in Remote Tools (or RSE for that matter), the > connection name should be restricted to the characters that are allowed by > RFT-952 (and amended by RFC-1123). That should be "RFC-952" not "RFT-952".
Note that I reported a problem with spaces in the connection name in https://bugs.eclipse.org/bugs/show_bug.cgi?id=332867 and I remember something being "fixed" to allow this to work, but the bug indicates I have a poor memory. I definitely remember it not working for me at the time and a decision being made that spaces in names should be OK. It's related anyway.
You should not build these URI's manually, instead you should use IRemoteFileManager#toURI(String path) to construct a compatible URI. This will handle the necessary escaping when there are special characters in the connection name. This will work for either Remote Tools or RSE. If you really want to build a Remote Tools URI manually, then you should use one of the URI constructors that take separate components. These will escape the authority component correctly. However I wouldn't recommend this as you're assuming how the connection name will be used in the URI, and there is no guarantee this will always be the case. If you're trying to do the same thing for RSE, then you have even more of a problem. RSE does not use the connection name (alias in RSE terminology), it uses the connection address (hostname or IP address). This makes it impossible to distinguish between two connections that point to the same host. If you want to specify the alias, then you have to supply it as a query component in the URI.
(In reply to comment #3) > You should not build these URI's manually, instead you should use > IRemoteFileManager#toURI(String path) to construct a compatible URI. This will > handle the necessary escaping when there are special characters in the > connection name. This will work for either Remote Tools or RSE. > > If you really want to build a Remote Tools URI manually, then you should use > one of the URI constructors that take separate components. These will escape > the authority component correctly. However I wouldn't recommend this as you're > assuming how the connection name will be used in the URI, and there is no > guarantee this will always be the case. > > If you're trying to do the same thing for RSE, then you have even more of a > problem. RSE does not use the connection name (alias in RSE terminology), it > uses the connection address (hostname or IP address). This makes it impossible > to distinguish between two connections that point to the same host. If you want > to specify the alias, then you have to supply it as a query component in the > URI. I'll give IRemoteFileManager.toURI(String) a shot. Thanks for the tip! If this works out, I'll go ahead and close this bugzilla.
(In reply to comment #4) > I'll give IRemoteFileManager.toURI(String) a shot. Thanks for the tip! > > If this works out, I'll go ahead and close this bugzilla. So far, this does solve the immediate problem. I may have other questions later, but I'll close this bugzilla for now as RESOLVED, INVALID.
