Received: with ECARTIS (v1.0.0; list gopher); Wed, 20 Mar 2002 17:01:51 -0500 (EST) Return-Path: <sugaku@sympatico.ca> Delivered-To: gopher@complete.org Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 3B7643B80D for <gopher@complete.org>; Wed, 20 Mar 2002 17:01:51 -0500 (EST) Received: from sympatico.ca ([64.228.194.67]) by tomts20-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020320220150.WVCC26555.tomts20-srv.bellnexxia.net@sympatico.ca> for <gopher@complete.org>; Wed, 20 Mar 2002 17:01:50 -0500 Message-ID: <3C990671.CAD13DAC@sympatico.ca> Date: Wed, 20 Mar 2002 17:00:17 -0500 From: Ralph Furmaniak <sugaku@sympatico.ca> X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: gopher@complete.org Subject: [gopher] Re: \n.\n References: <DC4522A8-3C47-11D6-B325-0003930BF072@complete.org> <p05010404b8beb412dd09@[205.189.158.32]> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 515 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: sugaku@sympatico.ca Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:ecartis@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Ecartis version 1.0.0 List-ID: Gopher <gopher.complete.org> X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> X-list: gopher

> I don't know much about server design and certainly about this > implementation (yet), but I do understand that the gopher0 and + spec > indicated that the reason for \n.\n is to indicate EOF.

The server always closes the connection after sending the final \n.\n, so it is not difficult for a client to determine when the file is finished. I am not sure if all clients are actually smart enough to see this, but it shouldn't be a big problem.

The problem is that there will still be some old servers and clients (ie: web browsers) running. Clients will still need to be able to strip away the final \n.\n from some servers (providing the server then closes the connection), and if files end with \n.\n the server will have to add another \n.\n because of this. Unless we want to finally break the backwards-compatability for web browsers and older clients, servers will still need to perform their magic when \n.\n appears in the file. Clients will then have to demagic it.

This problem only holds with gopher0, though. Gopher+ already has a way to circumvent this, as will anything else we develop.