Received: with LISTAR (v1.0.0; list gopher); Wed, 27 Dec 2000 15:37:21 -0600 (CST) Return-Path: <spectre@stockholm.ptloma.edu> Delivered-To: gopher@complete.org Received: from stockholm.ptloma.edu (stockholm.ptloma.edu [199.106.86.50]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 04D2F3B808 for <gopher@complete.org>; Wed, 27 Dec 2000 15:37:21 -0600 (CST) Received: (from spectre@localhost) by stockholm.ptloma.edu (8.9.1/8.9.1) id NAA15654 for gopher@complete.org; Wed, 27 Dec 2000 13:36:58 -0800 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) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 10 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: spectre@stockholm.ptloma.edu Precedence: bulk Reply-to: gopher@complete.org X-list: gopher

> 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 ----