Received: with ECARTIS (v1.0.0; list gopher); Sat, 06 Apr 2002 10:33:39 -0500 (EST) Return-Path: <wzk@happy-ent.de> Delivered-To: gopher@complete.org Received: from um1b.pce.de (um1b.pce.de [213.185.64.7]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id C140C3B859 for <gopher@complete.org>; Sat, 6 Apr 2002 10:33:37 -0500 (EST) Received: from win98.happy-ent.de (ppp-huerth-41.pce.de [213.185.65.169]) by um1b.pce.de (8.9.3/8.9.3) with ESMTP id RAA32017; Sat, 6 Apr 2002 17:33:34 +0200 Message-Id: <5.1.0.14.1.20020406171824.009e8c40@um1b.pce.de> X-Sender: qe-wzk@um1b.pce.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 06 Apr 2002 17:39:48 +0200 To: gopher@complete.org, gopher@complete.org From: Wolfgang Zekoll <wzk@happy-ent.de> Subject: [gopher] Re: Pygopherd nearing gopherd replacement In-Reply-To: <EF40ADB8-48A1-11D6-857D-0003930BF072@complete.org> References: <3CACE3A1.464BE377@sympatico.ca> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 571 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: wzk@happy-ent.de 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

At 09:32 05.04.02 -0500, John Goerzen wrote:

>On Thursday, April 4, 2002, at 06:37 PM, Ralph Furmaniak wrote: > > >> Pygopherd also does not add > >> an extra (or "second" if you're using URLs) type character like UMN > >> gopherd does. Because it figures all this out itself, that is > >> unnecessary. > > > > This does have its uses. For example an executable must be able to > > return > > either a plain file or a menu (gophermap format). If you include the >... >Actually, I believe that including it makes the code more complex. >Since the client already knows what sort of document it's getting, >there's no real need for the server to know at that time. Especially >now that we're doing away with \n.\n.

When I tried to drop the leading type character in the gopher selectors I discovered the following problem. The server receives the request

/fooFsomedata

with `F' being a tab character. Now the question for the server is if `/foo' is of type 7 or not. In the first case `somedata' is the query string in the second it's a gopher+ attribute.

To answer this question and to continue the selector parsing the server must first get the type of `/foo'. This is possible but I prefer the server to have a clear understanding of the selector before doing anything else like analysing the request and the addressed item. In other words, I want to make the selector interpretation independent from the available data. Here the leading type character simply helps the server to see how the whole request should be interpreted.

Regards

Wolfgang Zekoll