diff options
| author | Thomas E. Dickey <dickey@invisible-island.net> | 2011-06-11 13:06:08 -0400 |
|---|---|---|
| committer | Thomas E. Dickey <dickey@invisible-island.net> | 2011-06-11 13:06:08 -0400 |
| commit | f06f1fc3d95167ec780cb0963548f2afdd548b20 (patch) | |
| tree | 6c12f0dea0a3c860994a46c37d7f32336d39d7db /lynx_help/lynx_url_support.html | |
| parent | 279010bc0791556e63b4951d83a2c45252142b80 (diff) | |
| download | lynx-snapshots-f06f1fc3d95167ec780cb0963548f2afdd548b20.tar.gz | |
snapshot of project "lynx", label v2-8-8dev_8m
Diffstat (limited to 'lynx_help/lynx_url_support.html')
| -rw-r--r-- | lynx_help/lynx_url_support.html | 652 |
1 files changed, 652 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..45f461d9 --- /dev/null +++ b/lynx_help/lynx_url_support.html @@ -0,0 +1,652 @@ +<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 3.0//EN"> +<HTML> +<HEAD> +<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=iso-8859-1"> +</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> + +Lynx handles a number of URL types, that are enumerated below. For +more details about URLs (Uniform Resource Locators) see <em>RFC1738</em>: +<ul> +<li><a href="http://www.w3.org/Addressing/rfc1738.txt" +>http://www.w3.org/Addressing/rfc1738.txt</a> +<li><a href="ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt" +>ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt</a> +</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>: +<ul> +<li><a href="http://www.w3.org/Addressing/rfc1808.txt" +>http://www.w3.org/Addressing/rfc1808.txt</a> +<li><a href="ftp://ftp.rfc-editor.org/in-notes/rfc1808.txt" +>ftp://ftp.rfc-editor.org/in-notes/rfc1808.txt</a> +</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> +</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>. 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>. 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. 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>. 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. +<HR> + +<H2><a name="http_url">The <em>http</em> and <em>https</em> URLs:</a></H2> + +Lynx handles http URLs exactly as specified in RFC1738. The format +is: +<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>. +<HR> + +<H2><a name="telnet_url" +>The <em>telnet</em>, <em>tn3270</em>, and <em>rlogin</em> URLs:</a></H2> + +A <em>telnet</em> URL generally results in Lynx spawning a telnet +session. Lynx implements the complete telnet URL scheme, i.e.: +<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>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>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. +<HR> + +<H2><a name="gopher_url">The <em>gopher</em> URL:</a></H2> + +The gopher URL takes the form: +<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>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> +<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> + +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> +<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.: +<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.: +<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> + +The ftp URL has the general format: +<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>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>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.:<BR> +<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.: +<pre> + <em>ftp://user@myhost/~</em> +</pre> +<HR> + +<H2><a name="wais_url">The <em>wais</em> URL:</a></H2> + +The wais URL is used to retrieve resources using the Wide Area Information +System protocol. The format is: +<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>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. +<HR> + +<H2><a name="news_url" +>The <em>news</em>, <em>nntp</em>, and <em>snews</em> 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 <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>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>The formats are:<BR> +<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>Lynx also supports wildcarding via an asterisk for listings of news +hierarchies or sub-hierarchies, e.g.: +<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>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>Lynx also supports the newsgroup and message number URL scheme:<BR> +<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> + +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>The formats are: +<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>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">The <em>mailto</em> 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> + <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>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.: +<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>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>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: +<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>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. +<HR> + +<H2><a name="finger_url">The <em>finger</em> 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> + +<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>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. +<HR> + +<H2><a name="cso_url">The <em>cso</em> URL:</a></H2> + +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> +<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: +<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. +<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. + +<H2><a name="exec_url">The <em>lynxexec</em> and <em>lynxprog</em> 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> + <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>These are Lynxisms and should be used only in local documents intended +solely for Lynx. +<HR> + +<H2><a name="cgi_url">The <em>lynxcgi</em> 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> + <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. +<HR> + +<H2><a name="ncftp_url">The <em>NcFTP</em> URL:</a></H2> + +Lynx recognizes the NcFTP-style ftp URL, e.g., +<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> + +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> +As you discover what they are, and are tempted to use them externally in +documents, you should <em>resist</em> that temptation: +<UL><LI>There already is too much browser-specific markup around... +<LI>The schemes, or their meanings, may change between Lynx versions. +<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>If it doesn't work as expected when used outside of the intended + purpose, don't expect anyone to "fix" it. +</UL> + +<p>For example, tempting though it might be, do not use these: +<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> +<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> |