Re: [linuxtools-dev] connection names embedded in URI's

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 01/04/2012 02:00 PM, Corey Ashford wrote:
> On 01/04/2012 01:41 PM, Jeff Johnston wrote:
>> On 01/04/2012 02:55 PM, Corey Ashford wrote:
>>> On 01/04/2012 11:46 AM, Jeff Johnston wrote:
>>>> On 01/04/2012 02:10 PM, Corey Ashford wrote:
>>>>> Hi Jeff,
>>>>>
>>>>> I ran across an interesting problem with using the URI's that are
>>>>> formed
>>>>> in the linuxtools plug-in.  I wonder if you have any thoughts on
>>>>> this...
>>>>>
>>>>> We end up with URI's that look something like:
>>>>>
>>>>> remotetools://<connection-name>/<path-to-something>
>>>>>
>>>>> The problem that I ran into is that if I instantiate a URI object based
>>>>> on one of these strings, I get a URISyntaxException thrown if the
>>>>> <connection-name>   contains any embedded blanks, or characters
>>>>> other than
>>>>> a-zA-Z0-9, hyphen, and dots.  The syntax is defined by RFC-952 and
>>>>> RFC-1123.  RFC-952 states:
>>>>>
>>>>>      A "name" (Net, Host, Gateway, or Domain name) is a text string up
>>>>>      to 24 characters drawn from the alphabet (A-Z), digits (0-9),
>>>>> minus
>>>>>      sign (-), and period (.).  Note that periods are only allowed when
>>>>>      they serve to delimit components of "domain style names".
>>>>>
>>>>> RFC-1123 relaxed the above rules, allowing up to 255 characters, and
>>>>> allowing the first character to be a digit (so as to allow for IP
>>>>> addresses).
>>>>>
>>>>>
>>>>> It seems to me that there are a two solutions to this problem:
>>>>>
>>>>> 1) Create our own URI-like class that is more forgiving of the
>>>>> characters in the "host" field.
>>>>>
>>>>
>>>> I am definitely not in favour of this.
>>>>
>>>>> 2) Request that the upstream Remote Tools and RSE folks restrict the
>>>>> connection names according to the above limitation (e.g. no embedded
>>>>> blanks, etc.).  My hunch is that this would be a no go.
>>>>>
>>>>
>>>> This would be my take.  If one cannot represent the name as a URI, then
>>>> it should be restricted at creation time.  I would suggest a bug be
>>>> opened.
>>>>
>>>>> Any others?
>>>>>
>>>>> Have you run into this issue before?  What do you think?
>>>>>
>>>>
>>>> I have never run into the situation because all my host names are
>>>> sensible (either http addresses or simple all-character names).  I
>>>> believe that should be the over-whelming majority of cases, if not 100%.
>>>
>>> Actually, if you create a Remote Tools connection, the default name is
>>> "Remote Host" (notice the embedded blank).  So if you don't change the
>>> name, you get an error when you instantiate a URI based on this name.
>>>
>>
>> Hmm, are we talking connection name or host name?  The host name has to
>> be a legitimate host to connect to.  You presumably don't have a machine
>> on the network called "Remote Host".
> 
> Ok, I had assumed that Remote Tools and RSE formulate their URI's in the
> same way, but apparently they don't (according to you and Greg Watson).
>  For Remote Tools, the connection name (not the hostname/IP address)
> gets placed into the URI's <host> field.  For example, if I leave the
> connection name as "Remote Host", but specify a working hostname for
> that connection, I get a URI that looks like this:
> 
> remotetools://Remote Host/<path-to-resource>
> 
> Note that the actual hostname is not encoded into the URI.
> 
> For rse, I guess you get something like:
> 
> rse://<hostname>/<path-to-resource>?connection="Remote Host"
> 
> That said, when I use the file selector from RSE, it gives me a URI that
> looks similar to the one used for Remote Tools.  I need to look into how
> I wrote the file selector for RSE to make sure that's not my error, though.

I have a follow up on this one.  This is my error... I instantiated a
URI based on the path that was returned from the browseFile method, a
host based on the connection name, and no "query" containing the
connection name at the end.

URI selectedURI = new URI(scheme, connectionName, selectedPath, null);

So we have the situation that Remote Tools and RSE really do use two
different URI schemes.  As an example, I created a project in ~/xnew on
a remote machine (elm3b4.beaverton.ibm.com) using RSE and Remote Tools
using the connection name "Remote Host".

On RSE I get:

rse://elm3b4.beaverton.ibm.com/home/corey/xnew?Remote%20Host

Using Remote Tools I get:

remotetools://Remote%20Host/home/corey/xnew


I was able to use IRemoteFileManager.toURI() to fix the problem in my
resource selector widgets.

So unless I run into some other hang-up, I think this is a non-issue now.

Thanks for your help!

- Corey