796 lines
32 KiB
HTML
796 lines
32 KiB
HTML
<!-- $LynxId: lynx_url_support.html,v 1.37 2021/07/01 21:02:17 tom Exp $ -->
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for HTML5 for Linux version 5.6.0">
|
|
<title>URL Schemes Supported in Lynx</title>
|
|
<link rev="made" href="mailto:lynx-dev@nongnu.org">
|
|
<meta http-equiv="Content-Type" content=
|
|
"text/html; charset=us-ascii">
|
|
<meta name="description" content=
|
|
"Enumerate, describe and provide examples of Lynx's URL support on Unix and VMS. Lynx supports both Web standards and extensions.">
|
|
</head>
|
|
<body>
|
|
<blockquote>
|
|
<p><em>[</em><a href="#http_url">http, https</a> <em>|</em>
|
|
<a href="#telnet_url">telnet, tn3270, rlogin</a> <em>|</em>
|
|
<a href="#gopher_url">gopher</a> <em>|</em> <a href=
|
|
"#file_url">file</a> <em>|</em> <a href="#ftp_url">ftp</a>
|
|
<em>|</em> <a href="#wais_url">wais</a> <em>|</em> <a href=
|
|
"#news_url">news, nntp, snews</a> <em>|</em> <a href=
|
|
"#newspost_url">newspost, newsreply, snewspost, snewsreply</a>
|
|
<em>|</em> <a href="#mailto_url">mailto</a> <em>|</em> <a href=
|
|
"#finger_url">finger</a> <em>|</em> <a href="#cso_url">cso</a>
|
|
<em>|</em> <a href="#bibp_url">bibp</a> <em>|</em> <a href=
|
|
"#exec_url">lynxexec, lynxprog</a> <em>|</em> <a href=
|
|
"#cgi_url">lynxcgi</a><em>|</em> <a href="#ncftp_url">NcFTP</a>
|
|
<em>|</em> <a href="#internal_url">internal</a><em>]</em></p>
|
|
</blockquote>
|
|
|
|
<h1><em>URL Schemes Supported in Lynx</em>
|
|
</h1>
|
|
|
|
<p><strong>Lynx</strong> handles a number of URL types, that are
|
|
enumerated below. For more details about URLs (Uniform Resource
|
|
Locators) see <em>RFC1738</em>:</p>
|
|
|
|
<ul>
|
|
<li><a href=
|
|
"http://www.w3.org/Addressing/rfc1738.txt">http://www.w3.org/Addressing/rfc1738.txt</a></li>
|
|
|
|
<li><a href=
|
|
"ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt">ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt</a></li>
|
|
</ul>
|
|
|
|
<p><strong>Lynx</strong> 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 <em>RFC1808</em>:</p>
|
|
|
|
<ul>
|
|
<li><a href=
|
|
"http://www.w3.org/Addressing/rfc1808.txt">http://www.w3.org/Addressing/rfc1808.txt</a></li>
|
|
|
|
<li><a href=
|
|
"ftp://ftp.rfc-editor.org/in-notes/rfc1808.txt">ftp://ftp.rfc-editor.org/in-notes/rfc1808.txt</a></li>
|
|
</ul>
|
|
|
|
<p>and in subsequent drafts of the <em>IETF</em>:</p>
|
|
|
|
<ul>
|
|
<li><a href=
|
|
"https://web.archive.org/web/20130116065936/http://ftp.ics.uci.edu/pub/ietf/uri/">
|
|
Uniform Resource Identifiers (URI) Working Group</a></li>
|
|
</ul>
|
|
|
|
<p>When entering a URL on the command line to be used as the
|
|
<em>startfile</em>, or at the prompt for a
|
|
“<em>g</em>”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
|
|
<strong>Lynx</strong> configuration file. See the explanation of
|
|
those definitions and their use in your <em>lynx.cfg</em>.</p>
|
|
|
|
<p>For example, <em>wfbr</em> will be treated as
|
|
<em>http://www.wfbr.edu/</em>, and <em>wfbr/dir/lynx</em> will be
|
|
treated as <em>http://www.wfbr.edu/dir/lynx</em>, but
|
|
<em>gopher.wfbr.edu/11/_fileserv/_lynx</em> will be treated as
|
|
<em>gopher://gopher.wfbr.edu/11/_fileserv/_lynx</em>.</p>
|
|
|
|
<p>For files or directories on the local host, a tilde
|
|
(<em>~</em>) is expanded to the path of the account's login
|
|
directory, e.g., <em>~/foo</em> will be expanded to
|
|
<em>file://localhost/your/login/directory/foo</em>. The tilde
|
|
expansion is done homologously on Unix and VMS.</p>
|
|
|
|
<p>On VMS, <strong>Lynx</strong> also will expand any file or
|
|
directory spec recognizable to DCL into a valid URL, e.g.,
|
|
<em>[]</em> will be expanded to
|
|
<em>file://localhost/current/default/directory</em>.</p>
|
|
|
|
<p>These expansions are <em>SOLELY</em> for <em>startfile</em> or
|
|
“<em>g</em>”oto entries! Any partial or relative URLs
|
|
within HTML documents are resolved according to the rules
|
|
specified in RFC1808 and subsequent IETF drafts.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="http_url" id="http_url">The <em>http</em> and
|
|
<em>https</em> URLs:</a></h2>
|
|
|
|
<p><strong>Lynx</strong> handles http URLs exactly as specified
|
|
in RFC1738. The format is:</p>
|
|
|
|
<pre>
|
|
<em>http://host:port/path?searchpart#fragment</em>
|
|
</pre>
|
|
<p>where <em>:port</em> is optional and defaults to <em>:80</em>,
|
|
<em>/path</em> if present is a slash-separated series of symbolic
|
|
elements, and <em>?searchpart</em> if present is the query for an
|
|
ISINDEX search or the content of a FORM with METHOD="GET". The
|
|
<em>#fragment</em> field if present indicates a location in the
|
|
document to seek for display, based on a NAME-ed anchor or an ID
|
|
attribute within the document, and is technically an instruction
|
|
rather than part of the URL. <strong>Lynx</strong> will treat ID
|
|
attributes as NAME-ed anchors for all tags in the BODY of a
|
|
document which can correspond to positions in the rendering of
|
|
the document.</p>
|
|
|
|
<p>The https URL has the same format, but the default port is
|
|
<em>:443</em>.</p>
|
|
|
|
<p><strong>Lynx</strong> relies for https support on external
|
|
libraries (OpenSSL or GnuTLS) whose capabilities have evolved
|
|
over time. In turn, those libraries may depend upon external
|
|
resources for verifying SSL certificates. For instance,
|
|
certification revocation may be provided via the Online
|
|
Certificate Status Protocol (OCSP) which is an external service.
|
|
Without this facility, <strong>Lynx</strong> may not warn about
|
|
websites using revoked SSL certificates.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="telnet_url" id="telnet_url">The <em>telnet</em>,
|
|
<em>tn3270</em>, and <em>rlogin</em> URLs:</a></h2>
|
|
|
|
<p>A <em>telnet</em> URL generally results in
|
|
<strong>Lynx</strong> spawning a telnet session.
|
|
<strong>Lynx</strong> implements the complete telnet URL scheme,
|
|
i.e.:</p>
|
|
|
|
<pre>
|
|
<em>telnet://user:password@host:port</em>
|
|
</pre>
|
|
<p>The <em>user</em> and/or <em>:password</em> fields may be
|
|
omitted, and the <em>@</em> should be omitted if neither is
|
|
present. The port defaults to <em>:23</em> when omitted in the
|
|
URL.</p>
|
|
|
|
<p>A <em>tn3270</em> or <em>rlogin</em> 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.</p>
|
|
|
|
<p>It is unwise to include the <em>:password</em> 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.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="gopher_url" id="gopher_url">The <em>gopher</em>
|
|
URL:</a></h2>
|
|
|
|
<p>The gopher URL takes the form:</p>
|
|
|
|
<pre>
|
|
<em>gopher://host:port/gopher-path</em>
|
|
</pre>
|
|
<p>where <em>:port</em> is optional and defaults to <em>:70</em>,
|
|
and the <em>/gopher-path</em> is opaque (not fully equivalent to
|
|
the slash-separated series of symbolic elements of http paths) as
|
|
explained in RFC1738. Typically, the gopher-path consists of a
|
|
<a href=
|
|
"keystrokes/gopher_types_help.html"><em>gophertype</em></a>
|
|
indicating the file or service type (e.g., <em>0</em> or
|
|
<em>I</em> for plain text or an image, respectively, <em>7</em>
|
|
for a search, or <em>1</em> for a directory), followed by a
|
|
platform-specific <em>selector</em>. Any reserved characters in
|
|
the selector should be hex escaped (<em>%hh</em>), including
|
|
slashes, although hex escaping of slashes is not required by
|
|
<strong>Lynx</strong> in gopher URLs.</p>
|
|
|
|
<p><strong>Lynx</strong> does not overtly support the gopher+
|
|
protocol, and does not represent itself as gopher+ capable when
|
|
communicating with gopher servers. <strong>Lynx</strong> 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 <em>?</em>
|
|
rather than hex-escaped tab (<em>%09</em>) as the separator for
|
|
the <em>searchpart</em> in the <em>selector</em>, e.g.:<br>
|
|
<em>gopher://gopher.wfbr.edu/77/_shell/search.shell%20/_shell/walker?lynx*</em>
|
|
<strong>Lynx</strong> will handle the <em>%09</em> if you use
|
|
that instead of <em>?</em>, but other WWW clients may mishandle
|
|
it.</p>
|
|
|
|
<p>For the <em>gophertype</em> which signifies HTML (<em>h</em>),
|
|
if the <em>selector</em> begins with <em>GET%20/</em>
|
|
<strong>Lynx</strong> will convert the gopher URL to an http URL,
|
|
e.g.:<br></p>
|
|
|
|
<pre>
|
|
<em>gopher://www.wfbr.edu:80/hGET%20/</em>
|
|
</pre>
|
|
<p>will become:<br></p>
|
|
|
|
<pre>
|
|
<em>http://www.wfbr.edu/</em>
|
|
</pre>
|
|
<p>The port field will be retained if it is not <em>:80</em>, and
|
|
will default to <em>:70</em> if it was defaulted originally.
|
|
These conventions were adopted during development of the
|
|
University of Minnesota 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.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="file_url" id="file_url">The <em>file</em> URL:</a></h2>
|
|
|
|
<p>The file URL is used to retrieve files or generate a directory
|
|
listing on the local host. The host field can be
|
|
<em>localhost</em> or a domain name for the local host:<br></p>
|
|
|
|
<pre>
|
|
<em>file://localhost/path</em>
|
|
</pre>
|
|
<p>If you do not use <em>localhost</em> or a domain name for the
|
|
local host, <strong>Lynx</strong> will substitute <em>ftp://</em>
|
|
for <em>file://</em> and treat it as an ftp URL.</p>
|
|
|
|
<p>The <em>/path</em> is treated as originating at the root,
|
|
unless you include a tilde (<em>~</em>), e.g.:</p>
|
|
|
|
<pre>
|
|
<em>file://localhost/~/foo</em> will be converted to:
|
|
<em>file://localhost/your/login/directory/foo</em>
|
|
</pre>
|
|
<p>The latter feature is a Lynxism, is done homologously on Unix
|
|
and VMS, and should be used ONLY in local documents intended for
|
|
<strong>Lynx</strong>.</p>
|
|
|
|
<p>On VMS, the first element of the path, if not a tilde, is
|
|
assumed to be a device, e.g.:</p>
|
|
|
|
<pre>
|
|
<em>file://localhost/www_root/directory/filename.suffix</em>
|
|
</pre>
|
|
<p>should be used for:
|
|
<em>www_root:[directory]filename.suffix</em><br>
|
|
If you are unsure how to specify a file URL in local documents on
|
|
VMS, invoke <strong>Lynx</strong> with the desired file or
|
|
directory as the <em>startfile</em> using any spec acceptable to
|
|
DCL, and then use the <em>showinfo</em> command (<em>=</em>) to
|
|
see the file URL which <strong>Lynx</strong> created for it.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="ftp_url" id="ftp_url">The <em>ftp</em> URL:</a></h2>
|
|
|
|
<p>The ftp URL has the general format:</p>
|
|
|
|
<pre>
|
|
<em>ftp://host:port/path;type=[D,I, or A]</em>
|
|
<em>ftp://username@host:port/path;type=[D,I, or A]</em>
|
|
</pre>
|
|
<p>The default port is <em>:21</em> and the default
|
|
<em>username</em> is <em>anonymous</em>. If <em>username</em> is
|
|
included, <strong>Lynx</strong> will prompt you for the password.
|
|
For anonymous ftp, <strong>Lynx</strong> uses your
|
|
<em>personal_mail_address</em> (user@host) as the
|
|
<em>password</em> if it has been defined via the
|
|
“<em>o</em>”ptions menu. Otherwise,
|
|
<strong>Lynx</strong> uses the dummy password <em>WWWUser</em>.
|
|
(A password can also be embedded in the URL, by replacing
|
|
<em>username</em> with <em>username:password</em>. This is
|
|
strongly discouraged for “real” passwords that must
|
|
be kept secret, since URLs with the completely unencrypted
|
|
<em>password</em> 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 <em>@</em>
|
|
if neither <em>username</em> nor <em>:password</em> is
|
|
included.</p>
|
|
|
|
<p>The <em>;type=</em> parameter can be used with value
|
|
<em>D</em>, <em>I</em>, or <em>A</em> to force handling of the
|
|
URL as, respectively, a directory listing, binary file, or ASCII
|
|
file. The <strong>Lynx</strong> 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.</p>
|
|
|
|
<p>The <em>/path</em> is treated according to RFC1738 for VMS and
|
|
VM/CMS ftp servers. The lead slash (<em>/</em>) is treated purely
|
|
as a separator, not as a designator for the root, and the
|
|
<em>path</em> 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
|
|
(<em>%2f</em>), e.g.:</p>
|
|
|
|
<pre>
|
|
<em>ftp://user@myhost/%2fsys$common/syshlp</em>
|
|
</pre>
|
|
<p>can be used for a listing of sys$common:[syshlp]<br>
|
|
Also, on VM/CMS ftp servers, if the <em>path</em> string begins
|
|
with <em>vmsysu%3a</em> it receives special handling as an SFS
|
|
path, e.g.:</p>
|
|
|
|
<pre>
|
|
<em>ftp://ubvm.cc.buffalo.edu/vmsysu%3alistserv.webshare</em>
|
|
</pre>
|
|
<p>For Unix and Unix-emulation ftp servers, RFC1738 is not
|
|
respected and the lead slash is treated as the root, i.e., the
|
|
<em>/path</em> 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 <em>path</em> string treated as a file or path under
|
|
the login directory, include a tilde (<em>~</em>) as for <a href=
|
|
"#file_url">file</a> URLs, e.g.:</p>
|
|
|
|
<pre>
|
|
<em>ftp://user@myhost/~</em>
|
|
</pre>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="wais_url" id="wais_url">The <em>wais</em> URL:</a></h2>
|
|
|
|
<p>The wais URL is used to retrieve resources using the Wide Area
|
|
Information System protocol. The format is:</p>
|
|
|
|
<pre>
|
|
<em>wais://host:port/database</em>
|
|
<em>wais://host:port/database?wais_query</em>
|
|
<em>wais://host:port/database/wais_type/wais_path</em>
|
|
</pre>
|
|
<p>where <em>:port</em> defaults to <em>:210</em></p>
|
|
|
|
<p>Direct wais support is built into <strong>Lynx</strong> for
|
|
VMS, and can be compiled into <strong>Lynx</strong> on Unix.</p>
|
|
|
|
<p>If only a <em>database</em> is indicated in the URL,
|
|
<strong>Lynx</strong> returns an ISINDEX cover page for searching
|
|
that <em>database</em>, and will submit your search with the
|
|
<em>wais_query</em> appended. <strong>Lynx</strong> will convert
|
|
the server's reply into a hit list with URLs that include the
|
|
<em>wais_type</em> and <em>wais_path</em> for retrieving items
|
|
from the hit list.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="news_url" id="news_url">The <em>news</em>,
|
|
<em>nntp</em>, and <em>snews</em> URLs:</a></h2>
|
|
|
|
<p>The news and nntp URLs are handled by <strong>Lynx</strong> as
|
|
specified in RFC1738, but for compatibility with other clients,
|
|
<strong>Lynx</strong> allows inclusion of host and port fields in
|
|
news URLs, which properly should be used <em>only</em> in nntp
|
|
and snews URLs. If not included in news URLs,
|
|
<strong>Lynx</strong> will use the nntp server pointed to by the
|
|
NNTPSERVER environment variable or configuration symbol (see
|
|
lynx.cfg), with default port <em>:119</em>. A host field must be
|
|
included in nntp URLs, and the port field is optional with the
|
|
same default.</p>
|
|
|
|
<p>If the URL requires authentication, <strong>Lynx</strong> will
|
|
prompt you for the username and password. These are cached during
|
|
a session, for reuse on the same host. If $HOME/.newsauth exists,
|
|
<strong>Lynx</strong> 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.</p>
|
|
|
|
<p>The formats are:<br></p>
|
|
|
|
<pre>
|
|
<em>news:newsgroup</em> (retrieves list of messages in newsgroup)
|
|
<em>news:messageID</em> (retrieves the message)
|
|
<em>news:*</em> (retrieves list of all available newsgroups)
|
|
<em>nntp://host:port/newsgroup</em>
|
|
<em>nntp://host:port/messageID</em>
|
|
<em>nntp://host:port/*</em>
|
|
</pre>
|
|
<p>(snews same as nntp, but the default port is
|
|
<em>:563</em>)</p>
|
|
|
|
<p>The <em>messageID</em> is the message's unique identifier,
|
|
consisting of an identification string and the host of origin for
|
|
the message (<em>ident_string@origin_host</em>).</p>
|
|
|
|
<p><strong>Lynx</strong> also supports wildcarding via an
|
|
asterisk for listings of news hierarchies or sub-hierarchies,
|
|
e.g.:</p>
|
|
|
|
<pre>
|
|
<em>news:comp.infosystems.*</em>
|
|
<em>nntp://host:port/comp.infosystems.*</em>
|
|
</pre>
|
|
<p>(snews same as nntp, but the default port is
|
|
<em>:563</em>)<br>
|
|
This is not in RFC1738 and may not be supported by all other
|
|
clients.</p>
|
|
|
|
<p><strong>Lynx</strong> allows you both to <em>reply</em> to the
|
|
author of a news message via email, and, if news posting has been
|
|
enabled, to send a <em>followup</em> message to the newsgroup
|
|
(see <a href="#newspost_url">newspost, newsreply, snewspost,
|
|
snewsreply</a>).</p>
|
|
|
|
<p><strong>Lynx</strong> converts any strings in news messages
|
|
which appear to be a URL with a supported scheme into a link for
|
|
accessing that URL.</p>
|
|
|
|
<p><strong>Lynx</strong> also supports the newsgroup and message
|
|
number URL scheme:<br></p>
|
|
|
|
<pre>
|
|
<em>news:newsgroup/startNo-endNo</em> (lists message range in newsgroup)
|
|
<em>news:newsgroup/messageNo</em> (retrieves the message by number)
|
|
<em>nntp://host:port/newsgroup/startNo-endNo</em>
|
|
<em>nntp://host:port/newsgroup/messageNo</em>
|
|
</pre>
|
|
<p>(snews same as nntp, but the default port is
|
|
<em>:563</em>)<br>
|
|
Use of this scheme is not recommended, because the message
|
|
numbers are specific to each nntp server, unlike the unique
|
|
identifiers for news messages.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="newspost_url" id="newspost_url">The
|
|
<em>newspost</em>, <em>newsreply</em>, <em>snewspost</em>, and
|
|
<em>snewsreply</em> URLs:</a></h2>
|
|
|
|
<p>When <strong>Lynx</strong> receives group listings or articles
|
|
via <em>news</em>, <em>nntp</em> or <em>snews</em> URLs, it also
|
|
checks whether the nntp server supports posting from the
|
|
<strong>Lynx</strong> user's site, and if so, includes links for
|
|
posting new messages to that server, or for posting followups
|
|
(replies) to previously posted messages. RFC1738, and IETF URL
|
|
drafts through this release of <strong>Lynx</strong>, do not
|
|
include any schemes for posting to news groups.
|
|
<strong>Lynx</strong> has long supported newspost and newreply
|
|
URL schemes for posting new messages or sending followups,
|
|
respectively, to standard nntp servers, with default port
|
|
<em>:119</em>. <strong>Lynx</strong> now also supports homologous
|
|
snewspost and snewsreply URLs for use with SSL capable nntp
|
|
servers.</p>
|
|
|
|
<p>The formats are:</p>
|
|
|
|
<pre>
|
|
<em>newspost://host:port/newsgroup(s)</em> (post a new message)
|
|
<em>newsreply://host:port/newsgroup(s)</em> (post a followup message)
|
|
</pre>
|
|
<p>(snewspost and snewsreply have the same formats, but the
|
|
default port is <em>:563</em>)</p>
|
|
|
|
<p>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 <em>Options Menu</em>, the user is offered an
|
|
option to include the currently displayed document, which
|
|
presumably is a news article with a <em>followup</em> 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.</p>
|
|
|
|
<p>These URLs can be used as command line startfiles (in which
|
|
case, <strong>Lynx</strong> 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 <a href=
|
|
"#mailto_url">mailto</a> URLs, with the qualification that they
|
|
presently are supported only by <strong>Lynx</strong>.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="mailto_url" id="mailto_url">The <em>mailto</em>
|
|
URL:</a></h2>
|
|
|
|
<p>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:</p>
|
|
|
|
<pre>
|
|
<em>mailto:user@host</em>
|
|
</pre>
|
|
<p>The description of the mailto URL in RFC1738 has been
|
|
interpreted by some as allowing only a single recipient, but
|
|
<strong>Lynx</strong> 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,
|
|
<strong>Lynx</strong> also accepts a semi-colon-separated
|
|
list.</p>
|
|
|
|
<p>For compatibility with Netscape, <strong>Lynx</strong> parses
|
|
any <em>?subject=The%20Subject</em> appended to the URL, trims
|
|
the URL at the <em>?</em>, 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.:</p>
|
|
|
|
<pre>
|
|
<em><LINK REV="made"
|
|
HREF="mailto:me@myhost,her@herhost" TITLE="The Subject"></em>
|
|
|
|
<em><A HREF="mailto:user@host" TITLE="The Subject">...</A></em>
|
|
|
|
<em><FORM METHOD="post" ENCTYPE="text/plain"
|
|
ACTION="mailto:WebMaster@host" TITLE="The Subject">
|
|
...
|
|
</FORM></em>
|
|
</pre>
|
|
<p>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 <strong>Lynx</strong> recognizes
|
|
that as a synonym for TITLE.</p>
|
|
|
|
<p><strong>Lynx</strong> also will process any
|
|
<em>to=address(es)</em>, <em>cc=address(es)</em>,
|
|
<em>keywords=word_list</em> and/or <em>body=message</em> fields
|
|
in <em>?searchpart</em> tack-ons to mailto URLs. The <em>to</em>
|
|
and/or <em>cc</em> values can be single addresses, or comma- or
|
|
semi-colon-separated lists of addresses. All addresses, and any
|
|
<em>body</em> values, will be offered for approval by the user
|
|
before proceeding with a mailing. Any other name=value pairs in
|
|
the <em>?searchpart</em> will be ignored. Also, if the mailto URL
|
|
is the ACTION for a FORM, any <em>body</em> in a
|
|
<em>?searchpart</em> tack-on will be ignored, because the body of
|
|
the mailing must be constructed solely from the the FORM's
|
|
content. <strong>Lynx</strong> expects multiple name=value pairs
|
|
in a <em>?searchpart</em> tack-on to be separated by ampersands,
|
|
as in the original Netscape implementation, and in an equally
|
|
ill-advised IETF draft of that implementation (<a href=
|
|
"ftp://ftp.isi.edu/internet-drafts/draft-hoffman-mailto-url-03.txt">draft-hoffman-mailto-url-03.txt</a>).
|
|
These should be represented as entities (<em>&amp;</em>) 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., <em>mail:</em>, or <em>smtp:</em>),
|
|
rather than breaking <em>mailto:</em> implementations.</p>
|
|
|
|
<p>If <em>ENCTYPE="text/plain"</em> is specified for a FORM with
|
|
a mailto ACTION, <strong>Lynx</strong> will not hex escape the
|
|
name=value pairs of the FORM's content, and will use physical
|
|
newlines instead of “<em>&</em>” or
|
|
“<em>;</em>” to separate the pairs, so that the
|
|
content will be readable directly. Otherwise,
|
|
<strong>Lynx</strong> will mail the content with the default:</p>
|
|
|
|
<pre>
|
|
<em>ENCTYPE="application/x-www-form-urlencoded"</em> (“<em>&</em>” separates pairs)
|
|
</pre>
|
|
<p>or:</p>
|
|
|
|
<pre>
|
|
<em>ENCTYPE="application/sgml-form-urlencoded"</em> (“<em>;</em>” separates pairs)
|
|
</pre>
|
|
<p>if the latter was indicated.</p>
|
|
|
|
<p>Note that when mailing FORM content <strong>Lynx</strong>
|
|
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 <em>text/plain</em>, 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.</p>
|
|
|
|
<p>If the mailto URL is not the ACTION for a FORM, and if an
|
|
external editor has been defined via the <em>Options Menu</em>,
|
|
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.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="finger_url" id="finger_url">The <em>finger</em>
|
|
URL:</a></h2>
|
|
|
|
<p><strong>Lynx</strong> 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 <strong>Lynx</strong>
|
|
therefore include every possibility not inconsistent with
|
|
RFC1738, including:</p>
|
|
|
|
<pre>
|
|
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
|
|
</pre>
|
|
<p>Activating a finger URL will send a request to the finger
|
|
server via port 79 on the host specified. You can include
|
|
<em>:79</em> in the URL, but no other value is allowed. The
|
|
<em>/w</em> or <em>/%2fw</em> is used to request a full report
|
|
for finger servers which support it, and is not case sensitive
|
|
(i.e., can be <em>/W</em> or <em>/%2fW</em>). 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.</p>
|
|
|
|
<p>An alternative way to access finger servers is via gopher URLs
|
|
with port 79 and the plain text (<em>0</em>) <em>gophertype</em>
|
|
specified:<br>
|
|
<em>gopher://host:79/0</em><br>
|
|
<strong>Lynx</strong> will handle such URLs equivalently to overt
|
|
finger URLs, including creation of links for any strings which
|
|
appear to be supported URLs.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="cso_url" id="cso_url">The <em>cso</em> URL:</a></h2>
|
|
|
|
<p>The cso URL is intended to provide a gateway to CSO/PH (QI)
|
|
servers. The requests are made on port 105 by default
|
|
(<em>:105</em>), with the following overt cso URL format:<br></p>
|
|
|
|
<pre>
|
|
<em>cso://host</em>
|
|
</pre>
|
|
<p>You also can use a gopher URL format with port 105 and the CSO
|
|
(<em>2</em>) <em>gophertype</em> specified:</p>
|
|
|
|
<pre>
|
|
<em>gopher://host:105/2</em>
|
|
</pre>
|
|
<p><strong>Lynx</strong> 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.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="bibp_url" id="bibp_url">The <em>bibp</em> URL:</a></h2>
|
|
|
|
<p><strong>Lynx</strong> 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.</p>
|
|
|
|
<h2><a name="exec_url" id="exec_url">The <em>lynxexec</em> and
|
|
<em>lynxprog</em> URLs:</a></h2>
|
|
|
|
<p>If execution of spawned commands has been enabled in your
|
|
<strong>Lynx</strong> 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 <strong>Lynx</strong> on Unix, or for DCL on VMS,
|
|
e.g.:</p>
|
|
|
|
<pre>
|
|
<em>lynxexec:dir/date/size foo:[blah]</em> (VMS)
|
|
<em>lynxexec:ls -l /foo/blah</em> (Unix)
|
|
<em>lynxprog:news</em>
|
|
</pre>
|
|
<p>(Note, however, that restrictions on acceptable commands or
|
|
utilities may be imposed by the system administrator.)</p>
|
|
|
|
<p>You optionally can include <em>//localhost/</em> 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 <em>RETURN</em> before
|
|
<strong>Lynx</strong> 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.</p>
|
|
|
|
<p>These are Lynxisms and should be used only in local documents
|
|
intended solely for <strong>Lynx</strong>.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="cgi_url" id="cgi_url">The <em>lynxcgi</em> URL:</a></h2>
|
|
|
|
<p>The lynxcgi URL is implemented only on Unix, can be used as
|
|
the ACTION for a FORM, and if enabled in your
|
|
<strong>Lynx</strong> image has the format:</p>
|
|
|
|
<pre>
|
|
<em>lynxcgi://localhost/path_to_CGI_script</em>
|
|
</pre>
|
|
<p>where <em>//localhost</em> is optional and always implied; the
|
|
full path should be specified, as “~” is not
|
|
recognized; if the script is in the directory
|
|
<strong>Lynx</strong> was started from, the simple file name is
|
|
adequate. The output of the script should be text/html and is
|
|
rendered and displayed by <strong>Lynx</strong>. Restrictions on
|
|
use of lynxcgi and on acceptable paths can be imposed in
|
|
<em>userdefs.h</em> and <em>lynx.cfg</em>, qv.</p>
|
|
|
|
<p>This is a Lynxism and should be used only in local documents
|
|
intended solely for <strong>Lynx</strong>, or for limited local
|
|
testing of CGI scripts without an http server.</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="ncftp_url" id="ncftp_url">The <em>NcFTP</em>
|
|
URL:</a></h2>
|
|
|
|
<p><strong>Lynx</strong> recognizes the NcFTP-style ftp URL,
|
|
e.g.,</p>
|
|
|
|
<pre>
|
|
<cite>ftpHost</cite>:<cite>fileSpecification</cite>
|
|
</pre>
|
|
<p>for example</p>
|
|
|
|
<pre>
|
|
<code>
|
|
ftp.gnu.org:/pub/gnu
|
|
</code>
|
|
</pre>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="internal_url" id="internal_url">The <em>LYNXfoo</em>
|
|
internal URLs:</a></h2>
|
|
|
|
<p><strong>Lynx</strong> uses a variety of private URL schemes
|
|
for communication among its internal modules. They start with
|
|
uppercase letters <code>LYNX</code> by convention, although, as
|
|
input, URL schemes are recognized in a case-insensitive
|
|
manner.</p>
|
|
|
|
<p>As you discover what they are, and are tempted to use them
|
|
externally in documents, you should <em>resist</em> that
|
|
temptation:</p>
|
|
|
|
<ul>
|
|
<li>There already is too much browser-specific markup
|
|
around...</li>
|
|
|
|
<li>The schemes, or their meanings, may change between
|
|
<strong>Lynx</strong> versions.</li>
|
|
|
|
<li>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.</li>
|
|
|
|
<li>If it does not work as expected when used outside of the
|
|
intended purpose, do not expect anyone to "fix" it.</li>
|
|
</ul>
|
|
|
|
<p>For example, tempting though it might be, do not use
|
|
these:</p>
|
|
|
|
<pre>
|
|
<em>Return to your <A HREF="LYNXHIST:0">Startfile</A></em>
|
|
<em>Review your <A HREF="LYNXKEYMAP:">Keymap</A></em>
|
|
</pre>
|
|
<p>(No, they will not do any harm. Yes, they work. But do not
|
|
rely on it.)</p>
|
|
|
|
<p>If you must try one, the second is OK from the command
|
|
line:<br></p>
|
|
|
|
<pre>
|
|
<em>lynx LYNXKEYMAP:</em>
|
|
</pre>
|
|
<p>But within <strong>Lynx</strong>, use the
|
|
“<em>K</em>” keystroke command. Sometimes it may be
|
|
convenient to use a private scheme with
|
|
“<em>g</em>”oto, as in:</p>
|
|
|
|
<pre>
|
|
<em>g LYNXMESSAGES:</em>
|
|
<em>g LYNXCOMPILEOPTS:</em>
|
|
<em>g LYNXCFG:</em>
|
|
</pre>
|
|
<p>But again, there usually is a way in which those special pages
|
|
are meant to be reached that is more convenient.</p>
|
|
</body>
|
|
</html>
|