File Manager - BorneoXploit

Editing: lynx_url_support.html

<!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>
 [<a href="#http_url">http, https</a> |
 <a href="#telnet_url">telnet, tn3270, rlogin</a> |
 <a href="#gopher_url">gopher</a> | <a href=
 "#file_url">file</a> | <a href="#ftp_url">ftp</a>
 | <a href="#wais_url">wais</a> | <a href=
 "#news_url">news, nntp, snews</a> | <a href=
 "#newspost_url">newspost, newsreply, snewspost, snewsreply</a>
 | <a href="#mailto_url">mailto</a> | <a href=
 "#finger_url">finger</a> | <a href="#cso_url">cso</a>
 | <a href="#bibp_url">bibp</a> | <a href=
 "#exec_url">lynxexec, lynxprog</a> | <a href=
 "#cgi_url">lynxcgi</a>| <a href="#ncftp_url">NcFTP</a>
 | <a href="#internal_url">internal</a>]
 </blockquote>

<h1>URL Schemes Supported in Lynx
 </h1>

Lynx handles a number of URL types, that are
 enumerated below. For more details about URLs (Uniform Resource
 Locators) see RFC1738:

<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>

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:

<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 IETF:

<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>

When entering a URL on the command line to be used as the
 startfile, or at the prompt for a
 &ldquo;g&rdquo;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
 &ldquo;g&rdquo;oto entries! Any partial or relative URLs
 within HTML documents are resolved according to the rules
 specified in RFC1808 and subsequent IETF drafts.

<hr>

<h2><a name="http_url" id="http_url">The http and
 https URLs:</a></h2>

Lynx handles http URLs exactly as specified
 in RFC1738. The format is:

<pre>
 http://host:port/path?searchpart#fragment
</pre>
 where :port is optional and defaults to :80,
 /path if present is a slash-separated series of symbolic
 elements, and ?searchpart if present is the query for an
 ISINDEX search or the content of a FORM with METHOD="GET". The
 #fragment 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.

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

Lynx 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, Lynx may not warn about
 websites using revoked SSL certificates.

<hr>

<h2><a name="telnet_url" id="telnet_url">The telnet,
 tn3270, and rlogin URLs:</a></h2>

A telnet URL generally results in
 Lynx spawning a telnet session.
 Lynx implements the complete telnet URL scheme,
 i.e.:

<pre>
 telnet://user:password@host:port
</pre>
 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.

<hr>

<h2><a name="gopher_url" id="gopher_url">The gopher
 URL:</a></h2>

The gopher URL takes the form:

<pre>
 gopher://host:port/gopher-path
</pre>
 where :port is optional and defaults to :70,
 and the /gopher-path 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">gophertype</a>
 indicating the file or service type (e.g., 0 or
 I for plain text or an image, respectively, 7
 for a search, or 1 for a directory), followed by a
 platform-specific selector. Any reserved characters in
 the selector should be hex escaped (%hh), including
 slashes, although hex escaping of slashes is not required by
 Lynx in gopher URLs.

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.:

<pre>
gopher://www.wfbr.edu:80/hGET%20/
</pre>
 will become:

<pre>
http://www.wfbr.edu/
</pre>
 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 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>

The file URL is used to retrieve files or generate a directory
 listing on the local host. The host field can be
 localhost or a domain name for the local host:

<pre>
file://localhost/path
</pre>
 If you do not use localhost or a domain name for the
 local host, Lynx will substitute ftp://
 for file:// and treat it as an ftp URL.

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

<pre>
 file://localhost/~/foo will be converted to:
 file://localhost/your/login/directory/foo
</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.

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

<pre>
 file://localhost/www_root/directory/filename.suffix
</pre>
 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 acceptable to
 DCL, and then use the showinfo command (=) to
 see the file URL which Lynx created for it.

<hr>

The ftp URL has the general format:

<pre>
 ftp://host:port/path;type=[D,I, or A]
 ftp://username@host:port/path;type=[D,I, or A]
</pre>
 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
 &ldquo;o&rdquo;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 &ldquo;real&rdquo; 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.:

<pre>
 ftp://user@myhost/%2fsys$common/syshlp
</pre>
 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.:

<pre>
 ftp://ubvm.cc.buffalo.edu/vmsysu%3alistserv.webshare
</pre>
 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 <a href=
 "#file_url">file</a> URLs, e.g.:

<pre>
 ftp://user@myhost/~
</pre>

<hr>

The wais URL is used to retrieve resources using the Wide Area
 Information System protocol. The format is:

<pre>
 wais://host:port/database
 wais://host:port/database?wais_query
 wais://host:port/database/wais_type/wais_path
</pre>
 where :port defaults to :210

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.

<hr>

<h2><a name="news_url" id="news_url">The news,
 nntp, and snews URLs:</a></h2>

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 only 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 :119. A host field must be
 included in nntp URLs, and the port field is optional with the
 same default.

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:

<pre>
 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/*
</pre>
 (snews same as nntp, but the default port is
 :563)

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.:

<pre>
 news:comp.infosystems.*
 nntp://host:port/comp.infosystems.*
</pre>
 (snews same as nntp, but the default port is
 :563) 
 This is not in RFC1738 and may not be supported by all other
 clients.

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 <a href="#newspost_url">newspost, newsreply, snewspost,
 snewsreply</a>).

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:

<pre>
 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
</pre>
 (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.

<hr>

<h2><a name="newspost_url" id="newspost_url">The
 newspost, newsreply, snewspost, and
 snewsreply URLs:</a></h2>

When Lynx receives group listings or articles
 via news, nntp or snews 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
 :119. Lynx now also supports homologous
 snewspost and snewsreply URLs for use with SSL capable nntp
 servers.

The formats are:

<pre>
 newspost://host:port/newsgroup(s) (post a new message)
 newsreply://host:port/newsgroup(s) (post a followup message)
</pre>
 (snewspost and snewsreply have the same formats, but the
 default port is :563)

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 <a href=
 "#mailto_url">mailto</a> URLs, with the qualification that they
 presently are supported only by Lynx.

<hr>

<h2><a name="mailto_url" id="mailto_url">The mailto
 URL:</a></h2>

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:

<pre>
 mailto:user@host
</pre>
 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.:

<pre>
 &lt;LINK REV="made"
 HREF="mailto:me@myhost,her@herhost" TITLE="The Subject"&gt;

&lt;A HREF="mailto:user@host" TITLE="The Subject"&gt;...&lt;/A&gt;

&lt;FORM METHOD="post" ENCTYPE="text/plain"
 ACTION="mailto:WebMaster@host" TITLE="The Subject"&gt;
 ...
 &lt;/FORM&gt;
</pre>
 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 (<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 (&amp;amp;) 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 &ldquo;&amp;&rdquo; or
 &ldquo;;&rdquo; to separate the pairs, so that the
 content will be readable directly. Otherwise,
 Lynx will mail the content with the default:

<pre>
 ENCTYPE="application/x-www-form-urlencoded" (&ldquo;&amp;&rdquo; separates pairs)
</pre>
 or:

<pre>
 ENCTYPE="application/sgml-form-urlencoded" (&ldquo;;&rdquo; separates pairs)
</pre>
 if the latter was indicated.

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.

<hr>

<h2><a name="finger_url" id="finger_url">The finger
 URL:</a></h2>

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:

<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>
 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.

<hr>

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:

<pre>
 cso://host
</pre>
 You also can use a gopher URL format with port 105 and the CSO
 (2) gophertype specified:

<pre>
 gopher://host:105/2
</pre>
 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.

<hr>

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.

<h2><a name="exec_url" id="exec_url">The lynxexec and
 lynxprog URLs:</a></h2>

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.:

<pre>
 lynxexec:dir/date/size foo:[blah] (VMS)
 lynxexec:ls -l /foo/blah (Unix)
 lynxprog:news
</pre>
 (Note, however, that restrictions on acceptable commands or
 utilities may be imposed by the system administrator.)

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.

<hr>

<h2><a name="cgi_url" id="cgi_url">The lynxcgi URL:</a></h2>

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:

<pre>
 lynxcgi://localhost/path_to_CGI_script
</pre>
 where //localhost is optional and always implied; the
 full path should be specified, as &ldquo;~&rdquo; 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
 userdefs.h and lynx.cfg, qv.

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.

<hr>

<h2><a name="ncftp_url" id="ncftp_url">The NcFTP
 URL:</a></h2>

Lynx recognizes the NcFTP-style ftp URL,
 e.g.,

<pre>
 <cite>ftpHost</cite>:<cite>fileSpecification</cite>
</pre>
 for example

<hr>

<h2><a name="internal_url" id="internal_url">The LYNXfoo
 internal URLs:</a></h2>

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.

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

<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 does not work as expected when used outside of the
 intended purpose, do not expect anyone to "fix" it.</li>
 </ul>

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

<pre>
 Return to your &lt;A HREF="LYNXHIST:0"&gt;Startfile&lt;/A&gt;
 Review your &lt;A HREF="LYNXKEYMAP:"&gt;Keymap&lt;/A&gt;
</pre>
 (No, they will not do any harm. Yes, they work. But do not
 rely on it.)

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

<pre>
 lynx LYNXKEYMAP:
</pre>
 But within Lynx, use the
 &ldquo;K&rdquo; keystroke command. Sometimes it may be
 convenient to use a private scheme with
 &ldquo;g&rdquo;oto, as in:

<pre>
 g LYNXMESSAGES:
 g LYNXCOMPILEOPTS:
 g LYNXCFG:
</pre>
 But again, there usually is a way in which those special pages
 are meant to be reached that is more convenient.
</body>
</html>

Cancel