From:	SMTP%"VMSGopher-L@trln.lib.unc.edu" 25-JAN-1994 09:37:59.68
To:	EVERHART
CC:	
Subj:	Re: Bug in using Mac servers??

X-Listname: Gopher for VMS implementation and testing
    <VMSGopher-L@trln.lib.unc.edu>
Warnings-To: <>
Errors-To: postmaster@trln.lib.unc.edu
Sender: postmaster@trln.lib.unc.edu
Date: 24 Jan 1994 19:07:01 -0500 (EST)
From: Foteos Macrides <MACRIDES@SCI.WFEB.EDU>
Reply-To: VMSGopher-L@trln.lib.unc.edu
Subject: Re: Bug in using Mac servers??
To: VMSGopher-L@trln.lib.unc.edu
Message-Id: <01H82KZUZES2000HE3@SCI.WFEB.EDU>
X-Vms-To: IN%"VMSGopher-L@trln.lib.unc.edu"
X-Vms-Cc: MACRIDES
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I just wrote:
>I just wrote:
>>George D. Greenwade <bed_gdg@SHSU.edu> wrote:
>>>[...]
>>>					    Under a wide number of Mac
>>>Gopher Servers, the Host= tuple entry points to a numeric IP address.  It
>>>seems that the G+ 2.011 client for VMS postpends a trailing period to this
>>>IP address, rendering it unusable as it is indeed an unknown address.  It
>>>also consistently shows up in the URL created from a "=" or "^" as a
>>>trailing period.
>>>
>>>For those with a G+ 2.011 client, a Mac server to reference and replicate
>>>this behavior is refmac.kent.edu [131.123.20.45], which runs just fine
>>>under the VMS G+ 2.010 client.  Is there a workaround for this??  Help,
>>>please.
>> 
>>	This was another intentional change made by Paul, and there has been a
>>lot of discussion about it in comp.infosystems.gopher.  The change supposedly
>>is in compliance with the current name service RFC (I've never read it, so I
>>don't know), but some TCPIP packages can't handle it, nor can mailers for
>>email addresses that might be constructed from the tuple's Host field (not a
>>problem for G+, which should supply the addresses via the extended tuple
>>fields).  I've been waiting to see how that "controversy" plays out, before
>>doing anything, if anything, in the mods for VMS file set.
>>
>	You motivated me to look at the code instead of just reading about
>this in comp.infosystems.gopher, and for the client there *is* a bug in its
>code.  ./object/GSGopherObj.c has:
>
>
>     /*** Add a period to the end of the Host name (since it's supposed
>          to be a fully qualified domain name, only do this if the first
>	  character isn't a number
>      ***/
>
>     len = strlen(foo);
>
>     if (foo[len] != '.' && (*foo >= '0' && *foo <= '9')) {
>	  foo[len] = '.';
>	  foo[len+1] = '\0';
>     }
>
>Adding the dot to a non-numeric IP speeds things up in that if the host name
>isn't found, the service immediately returns the failure instead of trying
>other names (which will also fail in gopher's case) based on the name service
>rules for non-numeric IP's without a terminal dot.  But... the code is doing
>the test backwards, and therefore adding a dot when it shouldn't, and not when
>it should.  Here's the fix:
>
>************
>File [.OBJECT]GSGOPHEROBJ.C;2
>  923        if (foo[len] != '.' && (*foo < '0' || *foo > '9')) {
>  924   	  foo[len] = '.';
>******
>File [OBJECT]GSGOPHEROBJ.C;1
>  923        if (foo[len] != '.' && (*foo >= '0' && *foo <= '9')) {
>  924   	  foo[len] = '.';
>************
> 
	Hmm...  That line in GSfromNet() of GSGopherObj.c also is looking for
a prexisting terminal dot in the wrong place.  Here's what that line should
be:

     if (foo[len-1] != '.' && (*foo < '0' || *foo > '9')) {

				Fote

=========================================================================
 Foteos Macrides           Worcester Foundation for Experimental Biology
 MACRIDES@SCI.WFEB.EDU     222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
