\t<selector>\t<server>\t<port> > > to tell the client that everything is ok and to give him the > location of the file. > > In case the upload is ok the server may choose if it sends only > the basic `i'-ok or the whole directory entry. The latter assumes > that the server has processed the upload completly which may not > be always true. > > > Regards > > Wolfgang Zekoll - -- Timm Murray GPG Key Fingerprint: 32E9 DBAF 8089 ECB7 696D 560B AA9B 9E29 C69C 7CB4 - ---------- Intel CPUs are not defective, they just act that way. --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3HBvEACgkQqpueKcacfLTnWQCdFEK3eINzatlxGl0MUk461i35 dAQAn0Ho4LWinJSf0XJwl/b+H9Csbtlm =7JDr -----END PGP SIGNATURE----- -- Attached file included as plaintext by Ecartis -- -- File: Gopher+-Upload.txt Gopher+ Uploading By Timm Murray CHANGELOG Nov. 4, 2002 -- Added Wolfgang Zekoll's suggestions. (Client sends Gopher type and server sending final response) INTRODUCTION This document describes a means of uploading files to a Gopher server using Gopher+ attributes. In breaking with Gopher tradition, this document uses '\t' to denote a tab, '\r' to denote a cariage return, and '\n' to denote a newline. 'C:' is a line of text sent by the client, and 'S: is a line sent by the server. MENU SELECTOR 'u' is defined as being the item type indicating an upload selector. It is recommended that any upload fields use Gopher+ Authentication before allowing an upload. Example: uUpload a file\t/incoming\thost\tport\t*\r\n Clients should expect to go through the +ASK exchange for the upload even if a '?' is not present in the Gopher+ section. PREFORMING THE UPLOAD After the optional authentication exchange, the client sends meta information about the file being uploaded. The following exchange takes place: C: [selector string] \r\n S: +ASK \r\n S: Ask: Size of file (bytes)? \r\n S: Ask: Selector string to put under? \r\n S: Ask: Gopher type? \r\n S: AskF: File to send \r\n S: AskL: Additional information \r\n C: <size of file, in bytes> \r\n C: <description> \r\n C: <selector string> \r\n C: <gopher type> \r\n C: <filename> \r\n C: <additional info> \r\n C: <the file itself> S: iUpload accepted S: <type> \t <title> \t <selector> \t <server> \t <port> \r\n In keeping with Gopher+, a size of -1 means "read data until a period on a line by itself". A size of -2 means "read data until I close the connection" (this meathod is strongly discouraged). Any size of >= 0 means "read this many bytes, then close the connection". The "description" sent MAY be used by servers for the 'user' field in menu entries. Clients SHOULD keep this under 70 characters, in keeping with Gopher tradition for 'user' fields. It MUST NOT contain any tab characters. The "selector string" sent for the file MAY be ignored by servers. It is used only as a guide for servers that choose to use it. Like the selector string, the "gopher type" sent MAY be ignored by servers. It specifies the suggested Gopher type for this file. The filename sent MUST be ignored by servers. The "AskF" statement mearly provides the client with a chance to open a file dialog box so the user can choose the file to send (or however else the client wishes to handle it). Clients MAY send an empty string for the filename. ["Additional info" section] Once the file is transfered, and assuming that the size sent was not -2 ("read until I close the connection"), the server returns one of two messages. If the file is accepted, the server returns: S: iUpload accepted \r\n S: <type> \t <title> \t <selector> \t <server> \t <port> \r\n This tells the client the final position of the file on the server. This information MAY be different than what was actually sent by the client. If the file is not accepted, an error message is sent: S: 3Error uploading file

Received: with ECARTIS (v1.0.0; list gopher); Mon, 04 Nov 2002 18:45:46 -0500 (EST) Return-Path: Delivered-To: gopher@complete.org Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by gesundheit.complete.org (Postfix) with ESMTP id A7922644A2 for ; Mon, 4 Nov 2002 18:45:45 -0500 (EST) Received: from [10.9.9.9] (helo=fetch.runbox.com) by lufsen.runbox.com with esmtp (Exim 4.05-VA-mm1) id 188quc-00072z-00 for gopher@complete.org; Tue, 05 Nov 2002 00:45:42 +0100 Received: from [204.71.148.59] (helo=enterprise) (Authenticated Sender=hardburn) by fetch.runbox.com with asmtp (Exim 3.35 #1) id 188quK-0007G0-00 for gopher@complete.org; Tue, 05 Nov 2002 00:45:25 +0100 From: Timm Murray To: gopher@complete.org Subject: [gopher] Re: Gopher+ Uploading Date: Mon, 4 Nov 2002 17:46:55 -0600 X-Mailer: KMail [version 1.4] References: In-Reply-To: MIME-Version: 1.0 Content-type: text/plain Message-Id: <200211041746.58933.hardburn@runbox.com> Content-Transfer-Encoding: 8bit X-archive-position: 710 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: hardburn@runbox.com 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Excelent points. I've added these suggestions to the protocol. The current document is attached. On Monday 04 November 2002 18:06, wzk@happy-ent.de wrote: > Hello, > > the e-mail configuration of my brand new linux computer wasn't as good as > I thought. However, a quick talk to my provider gave me the (hopefully) > right hint. > > ---------- Forwarded message ---------- > Date: Sat, 2 Nov 2002 02:00:47 +0100 (CET) > From: wzk@happy-ent.de > To: gopher@complete.org > Subject: Re: [gopher] Gopher+ Uploading > > Hello Timm, > > nice proposal, but (you expected it) I have some comments. > > 1. The client should tell the server the suggested gopher type of the > uploaded file. The server can act with this information as with the > other, use or ignore (and override) it. > > 2. The server should send a final response after the file has been > uploaded (this implies that a filesize of -2 as upload parameter can > not be used). I suggest three types of responses. Each response > is formatted like a gopher directory entry: > > 3Error processing upload > > to signal an error, > > iUpload accepted > > to tell the client that the upload is ok, and the full item's > gopher directory entry > > \t\t<selector>\t<server>\t<port> > > to tell the client that everything is ok and to give him the > location of the file. > > In case the upload is ok the server may choose if it sends only > the basic `i'-ok or the whole directory entry. The latter assumes > that the server has processed the upload completly which may not > be always true. > > > Regards > > Wolfgang Zekoll - -- Timm Murray GPG Key Fingerprint: 32E9 DBAF 8089 ECB7 696D 560B AA9B 9E29 C69C 7CB4 - ---------- Intel CPUs are not defective, they just act that way. --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3HBvEACgkQqpueKcacfLTnWQCdFEK3eINzatlxGl0MUk461i35 dAQAn0Ho4LWinJSf0XJwl/b+H9Csbtlm =7JDr -----END PGP SIGNATURE----- -- Attached file included as plaintext by Ecartis -- -- File: Gopher+-Upload.txt Gopher+ Uploading By Timm Murray CHANGELOG Nov. 4, 2002 -- Added Wolfgang Zekoll's suggestions. (Client sends Gopher type and server sending final response) INTRODUCTION This document describes a means of uploading files to a Gopher server using Gopher+ attributes. In breaking with Gopher tradition, this document uses '\t' to denote a tab, '\r' to denote a cariage return, and '\n' to denote a newline. 'C:' is a line of text sent by the client, and 'S: is a line sent by the server. MENU SELECTOR 'u' is defined as being the item type indicating an upload selector. It is recommended that any upload fields use Gopher+ Authentication before allowing an upload. Example: uUpload a file\t/incoming\thost\tport\t*\r\n Clients should expect to go through the +ASK exchange for the upload even if a '?' is not present in the Gopher+ section. PREFORMING THE UPLOAD After the optional authentication exchange, the client sends meta information about the file being uploaded. The following exchange takes place: C: [selector string] \r\n S: +ASK \r\n S: Ask: Size of file (bytes)? \r\n S: Ask: Selector string to put under? \r\n S: Ask: Gopher type? \r\n S: AskF: File to send \r\n S: AskL: Additional information \r\n C: <size of file, in bytes> \r\n C: <description> \r\n C: <selector string> \r\n C: <gopher type> \r\n C: <filename> \r\n C: <additional info> \r\n C: <the file itself> S: iUpload accepted S: <type> \t <title> \t <selector> \t <server> \t <port> \r\n In keeping with Gopher+, a size of -1 means "read data until a period on a line by itself". A size of -2 means "read data until I close the connection" (this meathod is strongly discouraged). Any size of >= 0 means "read this many bytes, then close the connection". The "description" sent MAY be used by servers for the 'user' field in menu entries. Clients SHOULD keep this under 70 characters, in keeping with Gopher tradition for 'user' fields. It MUST NOT contain any tab characters. The "selector string" sent for the file MAY be ignored by servers. It is used only as a guide for servers that choose to use it. Like the selector string, the "gopher type" sent MAY be ignored by servers. It specifies the suggested Gopher type for this file. The filename sent MUST be ignored by servers. The "AskF" statement mearly provides the client with a chance to open a file dialog box so the user can choose the file to send (or however else the client wishes to handle it). Clients MAY send an empty string for the filename. ["Additional info" section] Once the file is transfered, and assuming that the size sent was not -2 ("read until I close the connection"), the server returns one of two messages. If the file is accepted, the server returns: S: iUpload accepted \r\n S: <type> \t <title> \t <selector> \t <server> \t <port> \r\n This tells the client the final position of the file on the server. This information MAY be different than what was actually sent by the client. If the file is not accepted, an error message is sent: S: 3Error uploading file