| Server IP : 103.119.228.120 / Your IP : 3.144.29.213 Web Server : Apache System : Linux v8.techscape8.com 3.10.0-1160.119.1.el7.tuxcare.els2.x86_64 #1 SMP Mon Jul 15 12:09:18 UTC 2024 x86_64 User : nobody ( 99) PHP Version : 5.6.40 Disable Function : shell_exec,symlink,system,exec,proc_get_status,proc_nice,proc_terminate,define_syslog_variables,syslog,openlog,closelog,escapeshellcmd,passthru,ocinum cols,ini_alter,leak,listen,chgrp,apache_note,apache_setenv,debugger_on,debugger_off,ftp_exec,dl,dll,myshellexec,proc_open,socket_bind,proc_close,escapeshellarg,parse_ini_filepopen,fpassthru,exec,passthru,escapeshellarg,escapeshellcmd,proc_close,proc_open,ini_alter,popen,show_source,proc_nice,proc_terminate,proc_get_status,proc_close,pfsockopen,leak,apache_child_terminate,posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,posix_setuid,dl,symlink,shell_exec,system,dl,passthru,escapeshellarg,escapeshellcmd,myshellexec,c99_buff_prepare,c99_sess_put,fpassthru,getdisfunc,fx29exec,fx29exec2,is_windows,disp_freespace,fx29sh_getupdate,fx29_buff_prepare,fx29_sess_put,fx29shexit,fx29fsearch,fx29ftpbrutecheck,fx29sh_tools,fx29sh_about,milw0rm,imagez,sh_name,myshellexec,checkproxyhost,dosyayicek,c99_buff_prepare,c99_sess_put,c99getsource,c99sh_getupdate,c99fsearch,c99shexit,view_perms,posix_getpwuid,posix_getgrgid,posix_kill,parse_perms,parsesort,view_perms_color,set_encoder_input,ls_setcheckboxall,ls_reverse_all,rsg_read,rsg_glob,selfURL,dispsecinfo,unix2DosTime,addFile,system,get_users,view_size,DirFiles,DirFilesWide,DirPrintHTMLHeaders,GetFilesTotal,GetTitles,GetTimeTotal,GetMatchesCount,GetFileMatchesCount,GetResultFiles,fs_copy_dir,fs_copy_obj,fs_move_dir,fs_move_obj,fs_rmdir,SearchText,getmicrotime MySQL : ON | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /usr/local/ssl/local/ssl/local/ssl/share/doc/lynx-2.8.8/lynx_help/ |
Upload File : |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!-- $LynxId: lynx_url_support.html,v 1.30 2012/01/31 10:52:00 tom Exp $ -->
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 6 November 2007), see www.w3.org">
<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">
</head>
<body>
<blockquote>
<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>
</blockquote>
<h1><em>URL Schemes Supported in Lynx</em></h1>
<p>Lynx 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>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
<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>and in subsequent drafts of the <em>IETF</em>:
<ul>
<li><a href="http://www.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 Lynx 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, Lynx 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">The <em>http</em> and <em>https</em>
URLs:</a></h2>
<p>Lynx handles http URLs exactly as specified in RFC1738. The
format is:</p>
<pre>
<em>http://host:port/path?searchpart#fragment</em>
</pre>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. Lynx 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>The https URL has the same format, but the default port is
<em>:443</em>.</p>
<hr>
<h2><a name="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 Lynx spawning a
telnet session. Lynx 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">The <em>gopher</em> URL:</a></h2>
<p>The gopher URL takes the form:</p>
<pre>
<em>gopher://host:port/gopher-path</em>
</pre>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 Lynx in gopher URLs.
<p>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 <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>
Lynx 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> Lynx will
convert the gopher URL to an http URL, e.g.:<br></p>
<pre>
<em>gopher://www.wfbr.edu:80/hGET%20/</em>
</pre>will become:<br>
<pre>
<em>http://www.wfbr.edu/</em>
</pre>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.
<hr>
<h2><a name="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>If you do not use <em>localhost</em> or a domain name for the
local host, Lynx will substitute <em>ftp://</em> for
<em>file://</em> and treat it as an ftp URL.
<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>The latter feature is a Lynxism, is done homologously on Unix
and VMS, and should be used ONLY in local documents intended for
Lynx.
<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>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 Lynx 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 Lynx created for it.
<hr>
<h2><a name="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, Lynx will prompt you for the password. For anonymous
ftp, Lynx 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, Lynx 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 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.</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>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.:
<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">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>where <em>:port</em> defaults to <em>:210</em>
<p>Direct wais support is built into Lynx for VMS, and can be
compiled into Lynx on Unix.</p>
<p>If only a <em>database</em> is indicated in the URL, Lynx
returns an ISINDEX cover page for searching that
<em>database</em>, and will submit your search with the
<em>wais_query</em> appended. Lynx 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">The <em>news</em>, <em>nntp</em>, and
<em>snews</em> URLs:</a></h2>
<p>The news and nntp URLs are handled by Lynx as specified in
RFC1738, but for compatibility with other clients, Lynx 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, Lynx 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, 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.</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>(snews same as nntp, but the default port is <em>:563</em>)
<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>Lynx 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>(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>Lynx 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>Lynx 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>Lynx 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>(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.
<hr>
<h2><a name="newspost_url">The <em>newspost</em>,
<em>newsreply</em>, <em>snewspost</em>, and <em>snewsreply</em>
URLs:</a></h2>
<p>When Lynx 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 Lynx
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 Lynx, do not include any schemes for posting to news
groups. Lynx 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>. Lynx 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>(snewspost and snewsreply have the same formats, but the
default port is <em>:563</em>)
<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, 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 <a href=
"#mailto_url">mailto</a> URLs, with the qualification that they
presently are supported only by Lynx.</p>
<hr>
<h2><a name="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 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.</p>
<p>For compatibility with Netscape, Lynx 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 Lynx recognizes that as a synonym
for TITLE.</p>
<p>Lynx 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. Lynx 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, Lynx 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, Lynx will mail
the content with the default:</p>
<pre>
<em>ENCTYPE="application/x-www-form-urlencoded"</em> ('<em>&</em>' separates pairs)
</pre>or:
<pre>
<em>ENCTYPE="application/sgml-form-urlencoded"</em> ('<em>;</em>' separates pairs)
</pre>if the latter was indicated.
<p>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 <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">The <em>finger</em> URL:</a></h2>
<p>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:</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>
Lynx 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">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>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.</p>
<hr>
<h2><a name="bibp_url">The <em>bibp</em> URL:</a></h2>
<p>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.</p>
<h2><a name="exec_url">The <em>lynxexec</em> and
<em>lynxprog</em> URLs:</a></h2>
<p>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.:</p>
<pre>
<em>lynxexec:dir/date/size foo:[blah]</em> (VMS)
<em>lynxexec:ls -l /foo/blah</em> (Unix)
<em>lynxprog:news</em>
</pre>(Note, however, that restrictions on acceptable commands or
utilities may be imposed by the system administrator.)
<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 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.</p>
<p>These are Lynxisms and should be used only in local documents
intended solely for Lynx.</p>
<hr>
<h2><a name="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 Lynx image has the
format:</p>
<pre>
<em>lynxcgi://localhost/path_to_CGI_script</em>
</pre>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 Lynx was started from, the simple file
name is adequate. The output of the script should be text/html and
is rendered and displayed by Lynx. Restrictions on use of lynxcgi
and on acceptable paths can be imposed in <em>userdefs.h</em> and
<em>lynx.cfg</em>, qv.
<p>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.</p>
<hr>
<h2><a name="ncftp_url">The <em>NcFTP</em> URL:</a></h2>
<p>Lynx recognizes the NcFTP-style ftp URL, e.g.,</p>
<pre>
<cite>ftpHost</cite>:<cite>fileSpecification</cite>
</pre>for example
<pre>
<code>
ftp.gnu.org:/pub/gnu
</code>
</pre>
<hr>
<h2><a name="internal_url">The <em>LYNXfoo</em> internal
URLs:</a></h2>
<p>Lynx 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 Lynx
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 doesn't work as expected when used outside of the
intended purpose, don't 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>(No, they won't do any harm. Yes, they work. But don't rely
on it.)
<p>If you must try one, the second is OK from the command
line:<br></p>
<pre>
<em>lynx LYNXKEYMAP:</em>
</pre>But within Lynx, use the '<em>K</em>' keystroke command.
Sometimes it may be convenient to use a private scheme with
'<em>g</em>'oto, as in:
<pre>
<em>g LYNXMESSAGES:</em>
<em>g LYNXCOMPILEOPTS:</em>
<em>g LYNXCFG:</em>
</pre>But again, there usually is a way in which those special
pages are meant to be reached that is more convenient.
</body>
</html>