diff options
Diffstat (limited to 'lynx_help/lynx_url_support.html')
| -rw-r--r-- | lynx_help/lynx_url_support.html | 785 |
1 files changed, 785 insertions, 0 deletions
diff --git a/lynx_help/lynx_url_support.html b/lynx_help/lynx_url_support.html new file mode 100644 index 0000000..78849c2 --- /dev/null +++ b/lynx_help/lynx_url_support.html @@ -0,0 +1,785 @@ +<!-- $LynxId: lynx_url_support.html,v 1.36 2017/04/28 16:47:05 tom Exp $ --> +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> + +<html> +<head> + <meta name="generator" content= + "HTML Tidy for Linux (vers 25 March 2009), 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"> + <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> |