The server indicates (in Gopher and Gopher+ directory listings) if an
item is Gopher+ or not by appending an additional field with a
?) to the directory entry:
1Some old directoryFfoo selectorFhost1Fport1 1Some new directoryFbar selectorFhost1Fport1F+ 0Some file or otherFmoo selectorFhost2Fport2F+
+ signals various things:
+the response uses Gopher+ protocol, that is a status code is sent (
-for failure) and a length indicator.
!instead of a
$returns all Gopher+ information for all items in the directory.
Old servers may handle Gopher+ requests in any way the choose. They may even send error messages - but could also just reply with a standard reply.
Gopher+ replies differ from Gopher. Gopher+ starts always with a
status indicator (
-) followed by a response length indicator.
Most of the time a client may be able to detect the response protocol
from the first line but not always. Therefore, the client should know,
if the requested item (or server) supports Gopher+ or not.
Exception: Gopher directories never start with a
+ (or a
Therefore it would be safe when clients request directories in Gopher+
from a server and the server replies in whatever it understands: Gopher+
Gopher+ information about an item starts always with an +INFO: block:
+INFO: 0Some file or otherFmoo selectorFhost2Fport2F+ +ADMIN: Admin: Frodo Gophermeister <firstname.lastname@example.org> Mod-Date: Wed Jul 28 17:02:01 1993 <19930728170201> +VIEWS: Text/plain: <10k> application/postscript: <100k>
The blocks start with a
+ in column 1 and entries in a block start
with a blank. You can think of Gopher+ information a text blocks
looking similar like MIME-headers and items may have any amount of
them as the server (or site maintainer) thinks is useful.
Only few things are specified for Gopher+ information:
|+INFO:||the item's directory entry|
|+ADMIN:||item administrator and last modification date|
|+VIEWS:||lists the different available views (MIME-types)|
|+ABSTRACT:||holds a multi-line text and/or points to a separate item|
The +INFO: block starts the Gopher+ information and it mandatory for all items (when listed in a Gopher+ format). It signals the beginning of the Gopher+ information from the +INFO: line. Nothing is said about any further contents of that block.
The +VIEWS: block is not mentioned to be mandatory but UMN gopher insists on it if the item is a file. For directories is can work without. Furthermore, the first listed entry should be the type, which is suggested by the server. (Why not just use the selector from the directory entry to get that?)
Other Gopher+ blocks may be added - and clients are needed to support them.
Gopher+ uses an additional request field to tell the server what precisely is requested.
|+||requests the item transfer by Gopher+ protocol.|
|+rep||requests the item's representation (content type) rep.|
|!||2.5||requests the item's Gopher+ information.|
|$||2.7||requests all Gopher+ information about all items in a directory.|
|?||2.8||seems to be only an item marker, not a request value.|
|<none>||nothing special, a Gopher0 request.|
? marker seems to be used for dynamic items. Clients have to
get and interpret the item's +ASK: block to get the input form.
Directory requests have some interesting variations depending on the plus selector.
+requests the directory contents without an Gopher+ information but using Gopher+ protocol.
!returns Gopher+ information about the directory itself.
! an be used to get Gopher+ information about any other item
$ may be followed by a list of Gopher+ blocks
the client wants, e.g.
$+VIEWS+ABSTRACT (2.7). But section
2.7. says also that
+rep is used to request a certain content representation of
the item (today we call that "content-type"). If the content-type
doesn't exist the client gets an error message.
Since Gopher+ is optional and servers support Gopher0 too, client may
run a mixed mode: collect item meta information by Gopher+ using
requests and get items by regular Gopher protocol. Using both version
may help implementing Gopher+ in old clients.