proposal for file: uri standard
John Dennis
jdennis at redhat.com
Wed Apr 7 18:22:07 EEST 2004
I assume the issue here is whether the hostname is FQDN (Fully Qualified
Domain Name). gethostname may or may not return a FQDN. It is not a
misconfiguration or error if the name returned by gethostname is not
FQDN. Further it is not an error (but bad practice) for the returned
hostname to not match the DNS name of the host (this can occur if you
call sethostname). Using gethostbyname should return the DNS FQDN, which
is much more canonical and I think is more in line with the desired
result.
Just as a nit, and I'm not 100% sure about this, if some has reset the
hostname I'm not sure passing that to gethostbyname will do the right
thing, it might be better to call gethostbyaddr. But that's a real
corner case and I wouldn't lose sleep over it. I think the real issue is
that its not unusual for gethostname to return a hostname without its
domain information.
John
On Wed, 2004-04-07 at 06:30, Thomas Leonard wrote:
> On Wed, Apr 07, 2004 at 10:07:18AM +0200, Alexander Larsson wrote:
> > Are people ok with putting up this version on freedesktop.org?
>
> Yep. One thing, though:
>
> > > Hostnames
> > > ---------
> > >
> > > When generating a file: uri the hostname part, if nonempty, should be
> > > whatever is returned from gethostname(). This means that the name is
> > > canonical for all users on the same machine, so that you can easily
> > > see if the referenced file is on the current machine. Note that
> > > "localhost" or an empty hostname needs to be handled specially, always
> > > meaning the host the uri is being interpreted on.
>
> I noticed we have this code in ROX-Filer to generate the hostname:
>
> if (gethostname(buffer, 4096) == 0) {
> /* gethostname doesn't always return the full name... */
> struct hostent *ent;
>
> buffer[4095] = '\0';
> ent = gethostbyname(buffer);
> name = g_strdup(ent ? ent->h_name : buffer);
>
>
> However, perhaps such machines are just misconfigured?
--
John Dennis <jdennis at redhat.com>
More information about the xdg
mailing list