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:
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.
The https URL has the same format, but the default port is :443. Patches for support of https URLs and the CONNECT procedure are available for qualified recipients via links in the Lynx Enhanced Pages. US Export laws and associated red tape pose severe impediments to inclusion of this support in the general distributions of freeware WWW clients such as Lynx. Sorry.
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 TCPIP 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 TCPIP software you will be prompted for a password whether or not one was included in the URL.
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 preformed 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/
will become:
http://www.wfbr.edu/
The port field will be retained if it is not :80, and will default
to :70 if it was defaulted originally. These conventions were
adopted during development of the University of Minnisota gopher software
to facilitate the offering of links to MIME-capable http servers in the
listings returned by gopher servers, but should be considered Lynxisms
and UMN Gopherisms.
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
The latter feature is a Lynxism, is done homologously on Unix and VMS,
and should be used ONLY in local documents intended for Lynx.
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
should be used for: www_root:[directory]filename.suffix
If you are unsure how to specify a file URL in local documents on
VMS, invoke Lynx with the desired file or directory as the
startfile using any spec acceptible to DCL, and then
use the showinfo command (=) to see the file
URL which Lynx created for it.
The default port is :21 and the default username is anonymous. If username is included but not :password, Lynx will prompt you for the password. This is recommended, as otherwise the URL will have it completely unencrypted. Do not include the @ if neither username nor :password is included. 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.
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 seperator, 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
can be used for a listing of sys$common:[syshlp]
Also, on VM/CMS ftp servers, if the path string begins
with vmsysu%3a it receives special handling as an SFS
path, e.g.:
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/~
Direct wais support is built into Lynx for VMS, and can be compiled into Lynx on Unix. If direct wais support is not available, Lynx uses the W3C wais gateway.
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 messageID is the message's unique identifier, consisting of an indentification 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.*
(snews same as nntp, but the default port is :563)
This is not in RFC1738 and may not be supported by all other clients.
For news URLs, Lynx allows you both to reply to the author of a message via email, and, if news posting has been enabled, to send a followup message to the newsgroup. Only email replies to the author are permitted via nntp URLs.
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: The description of the mailto URL in RCF1738 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.: <A
HREF="mailto:user@host" TITLE="The Subject">...</A>
<FORM METHOD="post" ENCTYPE="text/plain" Note that a TITLE attribute for FORM has been proposed but not included
in any HTML specifications or drafts, and should be considered a Lynxism
until/unless it is. Some clients use a SUBJECT attribute for this purpose
in FORM tags, and Lynx recognizes that as a synonym for TITLE.
If ENCTYPE="text/plain" is specified for a FORM with a mailto
ACTION, Lynx will not hex escape the name=value pairs, and will use physical
newlines instead of '&' to separate the pairs, so that the
content will be readable directly. Otherwise, Lynx will mail the content
with ENCTYPE="application/www-form-urlencoded". Lynx wraps any
lines longer than 78 characters in the FORM content, to avoid buffer
overflows in mail sofware and to ensure reliable transmission across
gateways.
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: You also can use a gopher URL format with port 105 and the CSO
(2) gophertype specified: 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.
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.
This is a Lynxisms and should be used only in local documents intended
solely for Lynx.
On VMS, you are advised to use the threaded OSU http server, available
from ftp://osu.edu as freeware, if your site does not already have an http
server. It can be installed as a purely local script server, and is far
more efficient and comprehensive than any code which might be incorporated
within Lynx.
news:newsgroup/startNo-endNo
news:newgroup/messageNo
nntp://host:port/newsgroup/startNo-endNo
nntp://host:port/newsgroup/messageNo
(snews same as nntp, but the default port is :563)
Use of this scheme is not recommended, because the message numbers
are specific to each nntp server, unlike the unique identifiers for
news messages.
The mailto URL:
The mailto URL is used to provide links that when activated can be
used to send a comment or the content of a FORM to an Internet email
address (user@host). The format is:
mailto:user@host
<LINK REV="made"
HREF="mailto:me@myhost,her@herhost" TITLE="The Subject">
ACTION="mailto:WebMaster@host" TITLE="The Subject">
...
</FORM>
The finger URL:
Lynx has full support for the finger protocol, but a format for finger
URLs has not yet been adopted by the IETF. The formats supported by Lynx
therefore include every possibility not inconsistent with RFC1738,
including:
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
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:
The cso URL is intended to provide a gateway to CSO/PH (QI) servers.
The requests are made on port 105 by default (:105), with the
following overt cso URL format:
cso://host
gopher://host:105/2
The lynxexec and lynxprog URLs:
If execution of spawned commands has been enabled in your Lynx image, the
lynxexec and lynxprog URLs can be used to execute arbitrary system commands
or invoke system utilities. Any system command and associated switches
or qualifiers can be used, with the syntax appropriate for a shell running
Lynx on Unix, or for DCL on VMS, e.g.:
lynxexec:dir/date/size foo:[blah]
lynxexec:ls -l /foo/blah
lynxprog:news
(Note, however, that restrictions on acceptible commands or utilities
may be imposed by the system administrator.)
The lynxcgi URL:
The lynxcgi URL is implemented only on Unix, can be used as the
ACTION for a FORM, and if enabled in your Lynx image has the format:
lynxcgi://localhost/path_to_CGI_script
where //localhost/ is optional and always implied. The
output of the script must be text/html and is rendered and displayed
by Lynx. (Note that restrictions on acceptible paths can be imposed
by the system administrator.)
The LYNXfoo internal URLs:
Lynx uses a variety of internal URL schemes as structured stream
objects for communication among its display modules. If you discover
what they are, and are tempted to use them externally in documents,
find the self-restraint to resist that temptation!