diff options
| author | Thomas E. Dickey <dickey@invisible-island.net> | 2011-06-11 12:12:46 -0400 |
|---|---|---|
| committer | Thomas E. Dickey <dickey@invisible-island.net> | 2011-06-11 12:12:46 -0400 |
| commit | 279010bc0791556e63b4951d83a2c45252142b80 (patch) | |
| tree | 2f0ca07764a555764bb1f5a628a3468e88bf0c59 /lynx_help/lynx_url_support.html | |
| parent | 0b30d0d375231ff07227872f2d1d25f005e43e98 (diff) | |
| download | lynx-snapshots-279010bc0791556e63b4951d83a2c45252142b80.tar.gz | |
snapshot of project "lynx", label v2_8_8dev_9a
Diffstat (limited to 'lynx_help/lynx_url_support.html')
| -rw-r--r-- | lynx_help/lynx_url_support.html | 652 |
1 files changed, 0 insertions, 652 deletions
diff --git a/lynx_help/lynx_url_support.html b/lynx_help/lynx_url_support.html deleted file mode 100644 index 45f461d9..00000000 --- a/lynx_help/lynx_url_support.html +++ /dev/null @@ -1,652 +0,0 @@ -<!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> |