[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] connection names embedded in URI's
|
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". Now, if we are talking connection
name, that gets appended at the end of the URI. The query part of the
URI can use octets to specify special characters such as the space
character so it may be that the encoding step is simply missing somewhere.
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
