Received: with ECARTIS (v1.0.0; list gopher); Wed, 20 Mar 2002 20:34:26 -0500 (EST) Return-Path: <jgoerzen@complete.org> Delivered-To: gopher@complete.org Received: from christoph.complete.org (pcp947166pcs.cstltn01.in.comcast.net [68.58.145.248]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 15C7D3B81F for <gopher@complete.org>; Wed, 20 Mar 2002 20:34:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by christoph.complete.org (Postfix) with ESMTP id 17EF95A3F9; Wed, 20 Mar 2002 20:34:25 -0500 (EST) Date: Wed, 20 Mar 2002 20:34:24 -0500 Subject: [gopher] Re: \n.\n Content-type: text/plain; charset=US-ASCII Mime-Version: 1.0 (Apple Message framework v481) Cc: gopher@complete.org To: Jon Nelson <jnelson@jamponi.net> From: John Goerzen <jgoerzen@complete.org> In-Reply-To: <20020320193037.271e98bc.jnelson@jamponi.net> Message-Id: <C6B8B067-3C6B-11D6-B325-0003930BF072@complete.org> Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.481) X-archive-position: 520 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: jgoerzen@complete.org 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

On Wednesday, March 20, 2002, at 08:30 PM, Jon Nelson wrote:

>> much data was actually available to read -- or a code indicating that >> the other side has finished transmitting and has closed the connection > > Actually, John, using "close" to signal end-of-file is a classic and > *very dangerous* practice. Additionally, HTTP/1.0 does *not* use

I was choosing my words carefully while trying to avoid being overly complex!

Actually, the server should do a shutdown() followed by a close(). In the client, read() will properly return EOF in this case.

What we gain by \n.\n is only the ability to detect that a text file has not been transmitted in full. If this happens, every client that I know of will simply ignore the error and display what it got.

What we lose is the ability to reliably transfer text files containing \n.\n without modification.

So, in essence, we have not gained anything by that \n.\n to date.

> "close" to indicate end-of-file, but rather content-length. In fact,

Yet often HTTP/1.0 headers omit content-length (esp CGI).

> can cause a TCP "close", not just a process on the other end issuing > a close system call.

What of these would we handle materially different than we would with the \n.\n support?

> I would suggest not altering the gopher0 protocol at this late a stage. > If you want to modify something, create gopher++ or gopher2, don't > go willy-nilly modifying a protocol that has been established for so > long.

For most everything else, I'd agree. But we have a case where:

1. New clients will communicate just fine with old servers. Text files will just have an extra . at the end.

2. New servers will communicate just fine with old clients. The clients stop at EOF anyway. Several already do not care about \n.\n.

> Additionally, "\n.\n" is a well-known specifier for end-of-length, and > it is used in POP3, SMTP and several other line-oriented protocols.

But there's a difference. Gopher will never read more commands from the client during the single connection. SMTP, for instance, will. With Gopher, the client sends a filename and \n and that's ALL. The client could even do a shutdown() at this point. (And probably should.)

-- John