From: Cameron Kaiser <spectre@stockholm.ptloma.edu>
Message-Id: <200012272205.OAA15038@stockholm.ptloma.edu>
Subject: [gopher] Re: Gopher Protocol Issue
In-Reply-To: <20001227113957.A3800@mothra> from David Allen at "Dec 27,
 0 11:39:57 am"
To: gopher@complete.org
Date: Wed, 27 Dec 2000 14:05:12 -0800 (PST)
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


> > Actually, some clients will break without the \r\n termination of lines
> > in text files -- TurboGopher for the Mac is one of these offenders.
> 
> Breaks as in, it won't display the data properly, or what?  I've never
> used this client.  Well, I'll fess up, I'm a gopher baby, I've only
> used lynx, netscape, UMN gopher, and my own pre-alpha client for a few
> months. 

Oh, you neophyte. :-) When I was testing Bucktooth, I was using hgopher,
Lynx, IE (such as it was), Netscape, TurboGopher, Unix gopher and I recently
got to test it on webTV, so I need to update the "looking at gopher through
a web browser" document to say that works (oddly enough since it's ostensibly
based on IE). I've also been playing with the gopher->web gateway at
heatdeath.org, which is great stuff. One would think the problem of testing on
multiple clients would be ameliorated in gopherspace, though. :-/

> Ah, so of course this brings up the question of whether or not you
> should follow the protocol, buggy clients be damned, or potentially
> break software.  

Yep. However, since it's very unlikely TurboGopher will be maintained and
I know personally of people using it, I accommodate it. Maybe I'll try to
get the source for it and try my hand at patching it with UMN's blessing.

> Well see that was part of what the question was.  Does gopher+
> *require* that each line end with \r\n even when that isn't part of
> the data being sent?  I'm not sure whether or not in this case the
> problem is just a bad idea in the code of UMN gopherd, or if it's
> actually a braindead requirement of gopher+.
> 
> And the whole period doubling thing...frankly, a protocol should never
> force you to send data other than what you want to send.  I.e. if I
> run "diff downloaded_gopher_file /var/gopher/file_being_served" I
> shouldn't ever get any different IMHO.

Well, the spec does provide for dumping files and just closing the connection.
A client is supposed to handle this (I think the specific note is on page
14 of RFC-1436, IIRC) and for awhile that's all Bucktooth did until I got
some complaints from users and added the "period" behaviour in. I would rather
just dump the file.

> When you say "developer-friendly" are you referring to the type of
> situation where you would realistically have to scan an entire file
> for certain patterns before being able to accurately report to the
> client how many bytes were going to be sent?  Servers shouldn't have
> to do all that.

No, I'm being more abstract. The spec for HTTP/1.1 is an excellent example;
we have multiple classes of what a server must do to be minimally,
functionally or maximally compliant. Moreover, the behaviour in multiple
situations is specifically documented to avoid just this sort of ambiguity.
It was very handy when I wrote HTTPi's /1.1 support.

RFC-1436 is much better in this regard. The Gopher+ sketch is terrible.

> The clients I've seen though never send G+ requests unless they know
> they can.  (I.e. when listing the contents of a directory, each dir
> entry has a "\t+" at the end of it.)  

When I run gopher directly at gopher.floodgap.com, providing it with nothing
but the host name, the client immediately makes a G+ request by default if
I don't give it a specific selector. This is client version 2.3.0 (1994).
I'm not sure whether to call this behaviour broken, but it's definitely
antisocial, so that's why the kludge is in Bucktooth to dissuade the client
from trying further G+ requests.

> The gopher+ info is quite old - are the people who wrote that still on
> the map in terms of gopher activity?  The document I've got is dated
> July 30, 1993, written by Farhad Anklesaria, Paul Lindner, Mark P.
> McCahill, Daniel Torrey, David Johnson, Bob Alberti, 
> Microcomputer and Workstation  Networks Center Computer and
> Information Systems University of Minnesota

Mark is definitely still reading the mail sent to the master gopher's
address; I communicated with him a few weeks ago. I don't know about the
rest. Maybe we can lure him onto the mailing list. I'm sure John would
be happy to have an honest-to-goodness authority around also. :-)

> I plead ignorance - how is that type of thing done?

What type of thing?

-- 
----------------------------- personal page: http://www.armory.com/~spectre/ --
 Cameron Kaiser, Point Loma Nazarene University * ckaiser@stockholm.ptloma.edu
-- TODAY'S DUMB TRUE HEADLINE: Enfield Couple Slain; Police Suspect Homicide --