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
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


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