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

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

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.

> 
> I do not think it is a situation that should be handled by us if a URI
> does not handle it.  Worst-case scenario is that it is an unsupported
> scenario.

I will try opening a bug and see if it gets me anywhere.

Thanks,

- Corey