From: Cameron Kaiser <spectre@stockholm.ptloma.edu>
Message-Id: <200012272136.NAA15654@stockholm.ptloma.edu>
Subject: [gopher] Re: Gopher Protocol Issue
In-Reply-To: <20001227100207.A26368@mothra> from David Allen at "Dec 27,
 0 10:02:07 am"
To: gopher@complete.org
Date: Wed, 27 Dec 2000 13:36:58 -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


> UMN gopherd when sending a file out to the client removes anything at
> the end of the line (carriage returns, line feeds) and then adds
> carriage return, linefeed to the end of the line.  What sucks about
> this is that if your line is just terminated with a linefeed, ala
> UNIX, the file you're sending  actually gets BIGGER because of the
> extra carriage returns.  That's a real problem, because if the server
> sends a gopher+ header saying how many bytes it's going to send
> according to the filesize, and then ADDS carraige returns, the client
> has a problem.

There's a larger issue at hand of how backwards-compatible Gopher+ is,
so I'll of course put in my two cents at the end of this :-)

> So how do you reconcile this?  Is it "correct" behavior for a gopherd
> to terminate ALL lines with "\r\n" even if that's not part of the
> original data it's sending?  (In the original gopher RFC, it
> specifically says that for directory listings, each line should be
> terminated with "\r\n".  But for regular files, it doesn't say)  This
> would be intensely lousy, since it would mean that the server wouldn't
> know how many bytes it was going to send unless it looked through the
> files and counted the number of occurances of that pattern before
> hand, which isn't very efficient.

Actually, some clients will break without the \r\n termination of lines
in text files -- TurboGopher for the Mac is one of these offenders.
I ran into this problem when designing Bucktooth when I discovered that
files were getting munged on my Power Mac. Unix gopher and Lynx show them
fine, of course, but where there's smoke there's fire. So I now leave
them in (or add them through the server), which makes TG happy and doesn't
break Unix gopher or Lynx.

Gopher+ is sort of a nebulous extension and there are a lot of inconsistencies
in it, the one you mention being one of many. It's a lot of good ideas that
should be implemented but aren't in a developer-friendly form with all the
kinks accounted for. That's why I gave up trying to create a wholly compliant
implementation in Bucktooth -- it only supports enough Gopher+ to tell a
client bent on sending G+ requests that it shouldn't do that, and that's all.
I have enough intricacies in the core protocol to worry about without G+ :-(
Before further development continues, I think there should be some work on
getting the Gopher+ sketch turned into a much more solid proposal.

-- 
----------------------------- personal page: http://www.armory.com/~spectre/ --
 Cameron Kaiser, Point Loma Nazarene University * ckaiser@stockholm.ptloma.edu
-- Rational behavior is a choice, not a predestination. -- Kent Paul Dolan ----