diff options
| author | Thomas E. Dickey <dickey@invisible-island.net> | 2012-02-20 02:08:17 -0500 |
|---|---|---|
| committer | Thomas E. Dickey <dickey@invisible-island.net> | 2012-02-20 02:08:17 -0500 |
| commit | bc0fa578036583231edb567b328b4f69ce6860fe (patch) | |
| tree | 99b322070bf62270218a0d80257a1f50bbefe147 /lynx_help/lynx_url_support.html | |
| parent | bb5fd6e44e480f571bcb713788cc50eea44095e5 (diff) | |
| download | lynx-snapshots-bc0fa578036583231edb567b328b4f69ce6860fe.tar.gz | |
snapshot of project "lynx", label v2-8-8dev_11
Diffstat (limited to 'lynx_help/lynx_url_support.html')
| -rw-r--r-- | lynx_help/lynx_url_support.html | 700 |
1 files changed, 700 insertions, 0 deletions
diff --git a/lynx_help/lynx_url_support.html b/lynx_help/lynx_url_support.html new file mode 100644 index 00000000..390c0153 --- /dev/null +++ b/lynx_help/lynx_url_support.html @@ -0,0 +1,700 @@ +<!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> |