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

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

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.

BTW, I filed bugzilla 325650 on this issue, and got a response from Greg
Watson already.  He suggests I use IRemoteFileManager#toURI(String)
which is suppose to handle correctly escaping the non-RFC-compliant
connection names.

I think we may need to make this method part of the remote file proxy.

- Corey