[gopher] Re: Gopher Protocol Issue

[Cameron Kaiser <spectre@xxxxxxxxxxxxxxxxxxxx>]

> 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@xxxxxxxxxxxxxxxxxxxx
-- Rational behavior is a choice, not a predestination. -- Kent Paul Dolan ----