Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)

HTTP State Management Using "Cookies" 1 2 3 4 TCP/IP Interactive and Remote Application Protocols

Menus and User Resource Selection

After receiving this sort of directory list, the Gopher client software will display a menu to the user containing all the resource names the server provided. The user then selects his or her desired item from the menu, and the client retrieves it by making a connection to the appropriate server and port number and sending the selector string of that resource. If this itself represents a subdirectory, a new directory listing for that subdirectory will be sent by the server; if some other type of resource, it will be accessed according to the requirements of the resource type.

For example, suppose this line were sent from the server to the client:

0Gopher Introduction<Tab>intro<Tab>gopher.someserver.org<Tab>70

This would be presented to the user as the file called “Gopher Introduction” in a menu containing other options. If the user chose it, the client would initiate a connection to the gopher server “gopher.someserver.org” at port 70, and then send the selector string “intro” to that server to retrieve the document.

As I hinted at the start of this discussion, both Gopher and the World Wide Web are intended for the same basic purpose: providing access to repositories of information, with links between related documents and resources. However, they take a very different approach to how that information is accessed, especially in two key areas: user interface and resource linking.

Gopher’s presentation to the user is entirely oriented around its hierarchical file system. As a result, Gopher is inherently menu-based, and the user interface usually based on a simple text presentation of those menus. In contrast, information on World Wide Web servers can be organized in any manner, and presented to the user in whatever form or fashion the owner of the server desires. The Web is much more “free form”, and there is no need to use a directory structure unless that is advantageous in some way.

Linking in the World Wide Web is done directly between documents, most often using Hypertext Markup Language (HTML) tags. When someone writing document A mentions something relevant to document B, he or she puts a link to B right into document A itself. Gopher, on the other hand, is not designed to use links in this way. Instead, linking is intended to be done using the directory tree we described earlier.

HTTP State Management Using "Cookies" 1 2 3 4 TCP/IP Interactive and Remote Application Protocols