[
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: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%.
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.
-- Jeff J.
Thanks for your consideration,
- Corey
