[gopher] Re: Gopher+ Uploading

[Timm Murray <hardburn@xxxxxxxxxx>]

-----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@xxxxxxxxxxxx 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@xxxxxxxxxxxx
> To: gopher@xxxxxxxxxxxx
> 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
>
>       <type>\t<title>\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