[http, https | telnet, tn3270, rlogin | gopher | file | ftp | wais | news, nntp, snews | newspost, newsreply, snewspost, snewsreply | mailto | finger | cso | bibp | lynxexec, lynxprog | lynxcgi| NcFTP | internal]

URL Schemes Supported in Lynx

• http://www.w3.org/Addressing/rfc1738.txt
• ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt

Lynx resolves partial or relative URLs in documents with respect to the BASE if one was specified, otherwise with respect to the document's absolute URL, using the rules described in RFC1808:

• http://www.w3.org/Addressing/rfc1808.txt
• ftp://ftp.rfc-editor.org/in-notes/rfc1808.txt

• Uniform Resource Identifiers (URI) Working Group

When entering a URL on the command line to be used as the startfile, or at the prompt for a 'g'oto entry, a partial host field can be used and the scheme field can be omitted if the scheme and fully qualified domain name can be constructed internally by using the URL_DOMAIN_PREFIXES and URL_DOMAIN_SUFFIXES definitions in the Lynx configuration file. See the explanation of those definitions and their use in your lynx.cfg. For example, wfbr will be treated as http://www.wfbr.edu/, and wfbr/dir/lynx will be treated as http://www.wfbr.edu/dir/lynx, but gopher.wfbr.edu/11/_fileserv/_lynx will be treated as gopher://gopher.wfbr.edu/11/_fileserv/_lynx. For files or directories on the local host, a tilde (~) is expanded to the path of the account's login directory, e.g., ~/foo will be expanded to file://localhost/your/login/directory/foo. The tilde expansion is done homologously on Unix and VMS. On VMS, Lynx also will expand any file or directory spec recognizable to DCL into a valid URL, e.g., [] will be expanded to file://localhost/current/default/directory. These expansions are SOLELY for startfile or 'g'oto entries! Any partial or relative URLs within HTML documents are resolved according to the rules specified in RFC1808 and subsequent IETF drafts.

The http and https URLs:

      http://host:port/path?searchpart#fragment

The https URL has the same format, but the default port is :443.

The telnet, tn3270, and rlogin URLs:

      telnet://user:password@host:port

The user and/or :password fields may be omitted, and the @ should be omitted if neither is present. The port defaults to :23 when omitted in the URL.

A tn3270 or rlogin URL is specified equivalently, and similarly spawns a tn3270 or rlogin session. The actual behavior is dependent on the TCP-IP software installed on the local and target hosts.

It is unwise to include the :password field except for URLs which point to anonymous or other public access accounts, and for most TCP-IP software you will be prompted for a password whether or not one was included in the URL.

The gopher URL:

      gopher://host:port/gopher-path

Lynx does not overtly support the gopher+ protocol, and does not represent itself as gopher+ capable when communicating with gopher servers. Lynx might transmit any (hex-escaped-tab-separated) extended gopher+ fields in a URL if an author included them in a document, but is likely to mishandle what the gopher server returns in such cases, and would not generate and transmit them itself. For pre-formed URLs to submit gopher searches, it may be better to use a ? rather than hex-escaped tab (%09) as the separator for the searchpart in the selector, e.g.:
gopher://gopher.wfbr.edu/77/_shell/search.shell%20/_shell/walker?lynx* Lynx will handle the %09 if you use that instead of ?, but other WWW clients may mishandle it.

For the gophertype which signifies HTML (h), if the selector begins with GET%20/ Lynx will convert the gopher URL to an http URL, e.g.:

gopher://www.wfbr.edu:80/hGET%20/

http://www.wfbr.edu/

The file URL:

file://localhost/path

The /path is treated as originating at the root, unless you include a tilde (~), e.g.:

      file://localhost/~/foo   will be converted to:
      file://localhost/your/login/directory/foo

On VMS, the first element of the path, if not a tilde, is assumed to be a device, e.g.:

      file://localhost/www_root/directory/filename.suffix

The ftp URL:

      ftp://host:port/path;type=[D,I, or A]
      ftp://username@host:port/path;type=[D,I, or A]

The default port is :21 and the default username is anonymous. If username is included, Lynx will prompt you for the password. For anonymous ftp, Lynx uses your personal_mail_address (user@host) as the password if it has been defined via the 'o'ptions menu. Otherwise, Lynx uses the dummy password WWWUser. (A password can also be embedded in the URL, by replacing username with username:password. This is strongly discouraged for 'real' passwords that must be kept secret, since URLs with the completely unencrypted password may show up on the screen, in HISTORY and LIST pages etc., and may even become visible to remote sites for example through Referer headers.) Do not include the @ if neither username nor :password is included.

The ;type= parameter can be used with value D, I, or A to force handling of the URL as, respectively, a directory listing, binary file, or ASCII file. The Lynx ftp gateway normally determines this itself, but the parameter can be used if the internal procedure draws an incorrect inference about the nature of the ftp URL.

The /path is treated according to RFC1738 for VMS and VM/CMS ftp servers. The lead slash (/) is treated purely as a separator, not as a designator for the root, and the path string if present is treated as in or under the login directory. For VMS ftp servers, if you wish to have the first element treated as a device rather than file or subdirectory name, begin it with a hex-escaped slash (%2f), e.g.:

ftp://user@myhost/%2fsys$common/syshlp

      ftp://ubvm.cc.buffalo.edu/vmsysu%3alistserv.webshare

For Unix and Unix-emulation ftp servers, RFC1738 is not respected and the lead slash is treated as the root, i.e., the /path is handled equivalently to that in file URLs. The distinction is irrelevant for anonymous ftp, but matters when using ftp for non-anonymous accounts. If you are using ftp with a Unix server and do wish to get a listing of the login directory or have the path string treated as a file or path under the login directory, include a tilde (~) as for file URLs, e.g.:

      ftp://user@myhost/~

The wais URL:

      wais://host:port/database
      wais://host:port/database?wais_query
      wais://host:port/database/wais_type/wais_path

Direct wais support is built into Lynx for VMS, and can be compiled into Lynx on Unix.

If only a database is indicated in the URL, Lynx returns an ISINDEX cover page for searching that database, and will submit your search with the wais_query appended. Lynx will convert the server's reply into a hit list with URLs that include the wais_type and wais_path for retrieving items from the hit list.

The news, nntp, and snews URLs:

If the URL requires authentication, lynx will prompt you for the username and password. These are cached during a session, for reuse on the same host. If $HOME/.newsauth exists, lynx initializes its cache from this file. The .newsauth file contents are one line per entry: hostname, password and username (in that order) separated by a space.

The formats are:

      news:newsgroup (retrieves list of messages in newsgroup)
      news:messageID (retrieves the message)
      news:* (retrieves list of all available newsgroups)
      nntp://host:port/newsgroup
      nntp://host:port/messageID
      nntp://host:port/*

The messageID is the message's unique identifier, consisting of an identification string and the host of origin for the message (ident_string@origin_host).

Lynx also supports wildcarding via an asterisk for listings of news hierarchies or sub-hierarchies, e.g.:

      news:comp.infosystems.*
      nntp://host:port/comp.infosystems.*

Lynx allows you both to reply to the author of a news message via email, and, if news posting has been enabled, to send a followup message to the newsgroup (see newspost, newsreply, snewspost, snewsreply).

Lynx converts any strings in news messages which appear to be a URL with a supported scheme into a link for accessing that URL.

Lynx also supports the newsgroup and message number URL scheme:

      news:newsgroup/startNo-endNo (lists message range in newsgroup)
      news:newsgroup/messageNo     (retrieves the message by number)
      nntp://host:port/newsgroup/startNo-endNo
      nntp://host:port/newsgroup/messageNo

The newspost, newsreply, snewspost, and snewsreply URLs:

The formats are:

      newspost://host:port/newsgroup(s)  (post a new message)
      newsreply://host:port/newsgroup(s) (post a followup message)

If the host field is omitted, it defaults to that pointed to by the NNTPSERVER configuration or environmental variable. Inclusion of at least one newsgroup in the URL is required, and additional groups can be specified as a comma-separated list. Wildcarding of newsgroup names is not supported for these URLs. For newsreply and snewsreply URLs, if an external editor has been defined via the Options Menu, the user is offered an option to include the currently displayed document, which presumably is a news article with a followup link that was activated, and if confirmed, each line of that document is prefixed with a right-angle-bracket. The user is expected to edit such an inclusion so that only the passages relevant to the followup message are retained.

These URLs can be used as command line startfiles (in which case, Lynx will exit after posting the message, and the newreply or snewsreply URLs degrade to newspost or snewpost URLs, respectively). They also can be used as HREF attribute values in any HTML document homologously to mailto URLs, with the qualification that they presently are supported only by Lynx.

The mailto URL:

      mailto:user@host

The description of the mailto URL in RFC1738 has been interpreted by some as allowing only a single recipient, but Lynx invented the mailto URL, has always supported a series of user@host addresses as a comma-separated list, and still does. For compatibility with Explorer, Lynx also accepts a semi-colon-separated list.

For compatibility with Netscape, Lynx parses any ?subject=The%20Subject appended to the URL, trims the URL at the ?, and uses the value as the default Subject: for the message or FORM content mailing. This is not recommended practice. The preferred way to indicate the default Subject: for a LINK or Anchor with a mailto HREF, or a FORM with a mailto ACTION, is via a TITLE attribute with the subject string as its value, e.g.:

      <LINK REV="made"
            HREF="mailto:me@myhost,her@herhost" TITLE="The Subject">

      <A HREF="mailto:user@host" TITLE="The Subject">...</A>

      <FORM METHOD="post" ENCTYPE="text/plain"
            ACTION="mailto:WebMaster@host" TITLE="The Subject">
       ...
      </FORM>

Note that a TITLE attribute for FORM is now included in the HTML specifications. Some clients use a SUBJECT attribute for this purpose in FORM tags, and Lynx recognizes that as a synonym for TITLE.

Lynx also will process any to=address(es), cc=address(es), keywords=word_list and/or body=message fields in ?searchpart tack-ons to mailto URLs. The to and/or cc values can be single addresses, or comma- or semi-colon-separated lists of addresses. All addresses, and any body values, will be offered for approval by the user before proceeding with a mailing. Any other name=value pairs in the ?searchpart will be ignored. Also, if the mailto URL is the ACTION for a FORM, any body in a ?searchpart tack-on will be ignored, because the body of the mailing must be constructed solely from the the FORM's content. Lynx expects multiple name=value pairs in a ?searchpart tack-on to be separated by ampersands, as in the original Netscape implementation, and in an equally ill-advised IETF draft of that implementation (draft-hoffman-mailto-url-03.txt). These should be represented as entities (&) in the HTML markup. This functionality is generally desired, but the IETF backward compatibility principal normally would lead to a new scheme being used (e.g., mail:, or smtp:), rather than breaking mailto: implementations.

If ENCTYPE="text/plain" is specified for a FORM with a mailto ACTION, Lynx will not hex escape the name=value pairs of the FORM's content, and will use physical newlines instead of '&' or ';' to separate the pairs, so that the content will be readable directly. Otherwise, Lynx will mail the content with the default:

      ENCTYPE="application/x-www-form-urlencoded" ('&' separates pairs)

      ENCTYPE="application/sgml-form-urlencoded" (';' separates pairs)

Note that when mailing FORM content Lynx wraps any lines longer than 78 characters, to avoid buffer overflows in mail software and to ensure reliable transmission across gateways. If the ENCTYPE was not text/plain, any script which decodes the mailed content should ignore the physical newlines and recognize only hex escaped newline characters as intended to be present in the decoded content.

If the mailto URL is not the ACTION for a FORM, and if an external editor has been defined via the Options Menu, the user is offered an option to include the currently displayed document. If this option is accepted, each line of that document is prefixed with a right-angle-bracket, and the prefixed inclusion should be trimmed by the user to just those passages relevant to the message which will be sent.

The finger URL:

 finger://host                         finger://@host
 finger://host/                        finger://@host/
 finger://host/%2fw                    finger://@host/w
 finger://host/w                       finger://host/w/
 finger://host/username[@host]         finger://username@host
 finger://host/username[@host]/        finger://username@host/
 finger://host/w/username[@host]       finger://username@host/w
 finger://host/%2fw%20username[@host]  finger://host/username[@host]/w
 finger://host/w/username

Activating a finger URL will send a request to the finger server via port 79 on the host specified. You can include :79 in the URL, but no other value is allowed. The /w or /%2fw is used to request a full report for finger servers which support it, and is not case sensitive (i.e., can be /W or /%2fW). Any strings in the report which appear to be a URL with a supported scheme will be converted into a link for accessing that URL.

An alternative way to access finger servers is via gopher URLs with port 79 and the plain text (0) gophertype specified:
gopher://host:79/0
Lynx will handle such URLs equivalently to overt finger URLs, including creation of links for any strings which appear to be supported URLs.

The cso URL:

cso://host

You also can use a gopher URL format with port 105 and the CSO (2) gophertype specified:

      gopher://host:105/2

Lynx will parse the stream returned by the server for the above URLs and create a FORM for submitting additional requests (searches) to the server. Any strings in the reports returned for these requests (searches) which appear to be a URL with a supported scheme will be converted into a link for accessing that URL.

The bibp URL:

Lynx provides built-in support for bibliographic protocol (BibP). BibP links are links to published works such as books or journal articles, without a predefined server. BibP links are intended for resolution by a local bibhost server (http://bibhost/) if it exists. Otherwise, resolution is performed by a document-specified server or a known global server.

The lynxexec and lynxprog URLs:

      lynxexec:dir/date/size foo:[blah] (VMS)
      lynxexec:ls -l /foo/blah          (Unix)
      lynxprog:news

You optionally can include //localhost/ in the URL, between the scheme field and the command, but that is always implied. The lynxexec and lynxprog URLs differ only in that with lynxexec you are prompted to enter RETURN before Lynx clears the screen and restores the previously displayed document, so that you can read any screen output generated by the spawned command, whereas no such pause is imposed upon exit from the utility invoked via lynxprog.

These are Lynxisms and should be used only in local documents intended solely for Lynx.

The lynxcgi URL:

      lynxcgi://localhost/path_to_CGI_script

This is a Lynxism and should be used only in local documents intended solely for Lynx, or for limited local testing of CGI scripts without an http server.

The NcFTP URL:

	ftpHost:fileSpecification

	ftp.gnu.org:/pub/gnu

The LYNXfoo internal URLs:

As you discover what they are, and are tempted to use them externally in documents, you should resist that temptation:

• There already is too much browser-specific markup around...
• The schemes, or their meanings, may change between Lynx versions.
• Even if a scheme stays the same, some aspect of its behavior may be modified without notice, or the context in which it is allowed may change.
• If it doesn't work as expected when used outside of the intended purpose, don't expect anyone to "fix" it.

For example, tempting though it might be, do not use these:

      Return to your <A HREF="LYNXHIST:0">Startfile</A>
      Review your <A HREF="LYNXKEYMAP:">Keymap</A>

If you must try one, the second is OK from the command line:

      lynx LYNXKEYMAP:

      g LYNXMESSAGES:
      g LYNXCOMPILEOPTS:
      g LYNXCFG: