Message-ID: <3C990671.CAD13DAC@sympatico.ca>
Date: Wed, 20 Mar 2002 17:00:17 -0500
From: Ralph Furmaniak <sugaku@sympatico.ca>
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
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


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