Received: with ECARTIS (v1.0.0; list gopher); Thu, 21 Mar 2002 09:27:01 -0500 (EST) Return-Path: Delivered-To: gopher@complete.org Received: from christoph.complete.org (unknown [168.215.193.254]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 1D3613B80B for ; Thu, 21 Mar 2002 09:27:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by christoph.complete.org (Postfix) with ESMTP id A75585A435 for ; Thu, 21 Mar 2002 09:27:00 -0500 (EST) Date: Thu, 21 Mar 2002 09:27:00 -0500 Mime-Version: 1.0 (Apple Message framework v481) Content-type: text/plain; charset=US-ASCII Subject: [gopher] Existing \n.\n behavior From: John Goerzen To: gopher@complete.org Content-Transfer-Encoding: 8bit Message-Id: X-Mailer: Apple Mail (2.481) X-archive-position: 526 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: List-unsubscribe: List-software: Ecartis version 1.0.0 List-ID: Gopher X-List-ID: Gopher List-subscribe: List-owner: List-post: List-archive: X-list: gopher Testing \n.\n in the middle of a file ------------------------------------- Clients: UMN gopher: no special behavior lynx: no special behavior netscape4: no special behavior konqueror: no special behavior IE 5.1/mac: aborts transfer at \n.\n Testing \n.\n at the end of a file ---------------------------------- Clients: UMN gopher: strips it lynx: no special behavior netscape4: no special behavior konqueror: no special behavior IE: strips it Testing no \n.\n at all ----------------------- Clients: UMN gopher: no problems lynx: no problems netscape4: no problems konqueror: no problems IE: no problems UMN gopherd server behavior --------------------------- Normal file (no \n.\n in it): adds \n.\n at end File with \n.\n in middle: passes it through, adds \n.\n at end File with \n.\n at the end: passes it through, adds another \n.\n From this, we can conclude: 1. Since the majority of the Ineternet's gopher servers are presumably running UMN gopherd, we know that they are not doing any special escaping of \n.\n. 2. Of the clients tested, only Internet Explorer did anything special with \n.\n occuring in the middle of a file. All other clients passed it through. 3. Only UMN gopher and IE strip \n.\n at the end of a file. Only IE has trouble with \n.\n in the middle of the file. Therefore: 4. Abolishing \n.\n from being added by servers will have zero negative impact on tested clients. 5. Abolishing all \n.\n behavior will resolve ambiguity about \n.\n occurring at the end of existing text files in UMN gopher immediately (and hopefully IE soon). It will also resolve ambiguity about \n.\n in the middle of files in IE. 6. Clients expecting \n.\n at the end of a file but not getting it are fine. (Old client, new server scenario) 7. Clients not expecting \n.\n at the end of the file but getting it anyway will simply display a "." at the end. All but UMN gopher and IE do this already anyway. (New client, old server scenario) I conclude that immediately abolishing all special \n.\n behavior from all software under the control of this group would have a net positive impact on gophers net-wide, even considering the large installed base of legacy software. -- John