From c2ecaf87e462fd6600ce5ee6a29cb352de042714 Mon Sep 17 00:00:00 2001 From: Philip Wittamore Date: Wed, 24 Sep 2025 22:26:00 +0200 Subject: update --- lynx_help/lynx_url_support.html | 796 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 796 insertions(+) create mode 100644 lynx_help/lynx_url_support.html (limited to 'lynx_help/lynx_url_support.html') diff --git a/lynx_help/lynx_url_support.html b/lynx_help/lynx_url_support.html new file mode 100644 index 0000000..52ba2fb --- /dev/null +++ b/lynx_help/lynx_url_support.html @@ -0,0 +1,796 @@ + + + + + + URL Schemes Supported in Lynx + + + + + +
+

[http, https | + telnet, tn3270, rlogin | + gopher | file | ftp + | wais | news, nntp, snews | newspost, newsreply, snewspost, snewsreply + | mailto | finger | cso + | bibp | lynxexec, lynxprog | lynxcgi| NcFTP + | internal]

+
+ +

URL Schemes Supported in Lynx +

+ +

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

+ + + +

Lynx resolves partial or relative URLs in + documents with respect to the BASE if one was specified, + otherwise with respect to the document's absolute URL, using the + rules described in RFC1808:

+ + + +

and in subsequent drafts of the IETF:

+ + + +

When entering a URL on the command line to be used as the + startfile, or at the prompt for a + “g”oto entry, a partial host field can be + used and the scheme field can be omitted if the scheme and fully + qualified domain name can be constructed internally by using the + URL_DOMAIN_PREFIXES and URL_DOMAIN_SUFFIXES definitions in the + Lynx configuration file. See the explanation of + those definitions and their use in your lynx.cfg.

+ +

For example, wfbr will be treated as + http://www.wfbr.edu/, and wfbr/dir/lynx will be + treated as http://www.wfbr.edu/dir/lynx, but + gopher.wfbr.edu/11/_fileserv/_lynx will be treated as + gopher://gopher.wfbr.edu/11/_fileserv/_lynx.

+ +

For files or directories on the local host, a tilde + (~) is expanded to the path of the account's login + directory, e.g., ~/foo will be expanded to + file://localhost/your/login/directory/foo. The tilde + expansion is done homologously on Unix and VMS.

+ +

On VMS, Lynx also will expand any file or + directory spec recognizable to DCL into a valid URL, e.g., + [] will be expanded to + file://localhost/current/default/directory.

+ +

These expansions are SOLELY for startfile or + “g”oto entries! Any partial or relative URLs + within HTML documents are resolved according to the rules + specified in RFC1808 and subsequent IETF drafts.

+ +
+ +

The http and + https URLs:

+ +

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

+ + 
+      http://host:port/path?searchpart#fragment
+
+

where :port is optional and defaults to :80, + /path if present is a slash-separated series of symbolic + elements, and ?searchpart if present is the query for an + ISINDEX search or the content of a FORM with METHOD="GET". The + #fragment field if present indicates a location in the + document to seek for display, based on a NAME-ed anchor or an ID + attribute within the document, and is technically an instruction + rather than part of the URL. Lynx will treat ID + attributes as NAME-ed anchors for all tags in the BODY of a + document which can correspond to positions in the rendering of + the document.

+ +

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

+ +

Lynx relies for https support on external + libraries (OpenSSL or GnuTLS) whose capabilities have evolved + over time. In turn, those libraries may depend upon external + resources for verifying SSL certificates. For instance, + certification revocation may be provided via the Online + Certificate Status Protocol (OCSP) which is an external service. + Without this facility, Lynx may not warn about + websites using revoked SSL certificates.

+ +
+ +

The telnet, + tn3270, and rlogin URLs:

+ +

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

+ + 
+      telnet://user:password@host:port
+
+

The user and/or :password fields may be + omitted, and the @ should be omitted if neither is + present. The port defaults to :23 when omitted in the + URL.

+ +

A tn3270 or rlogin URL is specified + equivalently, and similarly spawns a tn3270 or rlogin session. + The actual behavior is dependent on the TCP-IP software installed + on the local and target hosts.

+ +

It is unwise to include the :password field except + for URLs which point to anonymous or other public access + accounts, and for most TCP-IP software you will be prompted for a + password whether or not one was included in the URL.

+ +
+ +

The gopher + URL:

+ +

The gopher URL takes the form:

+ + 
+      gopher://host:port/gopher-path
+
+

where :port is optional and defaults to :70, + and the /gopher-path is opaque (not fully equivalent to + the slash-separated series of symbolic elements of http paths) as + explained in RFC1738. Typically, the gopher-path consists of a + gophertype + indicating the file or service type (e.g., 0 or + I for plain text or an image, respectively, 7 + for a search, or 1 for a directory), followed by a + platform-specific selector. Any reserved characters in + the selector should be hex escaped (%hh), including + slashes, although hex escaping of slashes is not required by + Lynx in gopher URLs.

+ +

Lynx does not overtly support the gopher+ + protocol, and does not represent itself as gopher+ capable when + communicating with gopher servers. Lynx might + transmit any (hex-escaped-tab-separated) extended gopher+ fields + in a URL if an author included them in a document, but is likely + to mishandle what the gopher server returns in such cases, and + would not generate and transmit them itself. For pre-formed URLs + to submit gopher searches, it may be better to use a ? + rather than hex-escaped tab (%09) as the separator for + the searchpart in the selector, e.g.:
+ gopher://gopher.wfbr.edu/77/_shell/search.shell%20/_shell/walker?lynx* + Lynx will handle the %09 if you use + that instead of ?, but other WWW clients may mishandle + it.

+ +

For the gophertype which signifies HTML (h), + if the selector begins with GET%20/ + Lynx will convert the gopher URL to an http URL, + e.g.:

+ + 
+gopher://www.wfbr.edu:80/hGET%20/
+
+

will become:

+ + 
+http://www.wfbr.edu/
+
+

The port field will be retained if it is not :80, and + will default to :70 if it was defaulted originally. + These conventions were adopted during development of the + University of Minnesota gopher software to facilitate the + offering of links to MIME-capable http servers in the listings + returned by gopher servers, but should be considered Lynxisms and + UMN Gopherisms.

+ +
+ +

The file URL:

+ +

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

+ + 
+file://localhost/path
+
+

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

+ +

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

+ + 
+      file://localhost/~/foo   will be converted to:
+      file://localhost/your/login/directory/foo
+
+

The latter feature is a Lynxism, is done homologously on Unix + and VMS, and should be used ONLY in local documents intended for + Lynx.

+ +

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

+ + 
+      file://localhost/www_root/directory/filename.suffix
+
+

should be used for: + www_root:[directory]filename.suffix
+ If you are unsure how to specify a file URL in local documents on + VMS, invoke Lynx with the desired file or + directory as the startfile using any spec acceptable to + DCL, and then use the showinfo command (=) to + see the file URL which Lynx created for it.

+ +
+ +

The ftp URL:

+ +

The ftp URL has the general format:

+ + 
+      ftp://host:port/path;type=[D,I, or A]
+      ftp://username@host:port/path;type=[D,I, or A]
+
+

The default port is :21 and the default + username is anonymous. If username is + included, Lynx will prompt you for the password. + For anonymous ftp, Lynx uses your + personal_mail_address (user@host) as the + password if it has been defined via the + “o”ptions menu. Otherwise, + Lynx uses the dummy password WWWUser. + (A password can also be embedded in the URL, by replacing + username with username:password. This is + strongly discouraged for “real” passwords that must + be kept secret, since URLs with the completely unencrypted + password may show up on the screen, in HISTORY and LIST + pages etc., and may even become visible to remote sites for + example through Referer headers.) Do not include the @ + if neither username nor :password is + included.

+ +

The ;type= parameter can be used with value + D, I, or A to force handling of the + URL as, respectively, a directory listing, binary file, or ASCII + file. The Lynx ftp gateway normally determines + this itself, but the parameter can be used if the internal + procedure draws an incorrect inference about the nature of the + ftp URL.

+ +

The /path is treated according to RFC1738 for VMS and + VM/CMS ftp servers. The lead slash (/) is treated purely + as a separator, not as a designator for the root, and the + path string if present is treated as in or under the + login directory. For VMS ftp servers, if you wish to have the + first element treated as a device rather than file or + subdirectory name, begin it with a hex-escaped slash + (%2f), e.g.:

+ + 
+      ftp://user@myhost/%2fsys$common/syshlp
+
+

can be used for a listing of sys$common:[syshlp]
+ Also, on VM/CMS ftp servers, if the path string begins + with vmsysu%3a it receives special handling as an SFS + path, e.g.:

+ + 
+      ftp://ubvm.cc.buffalo.edu/vmsysu%3alistserv.webshare
+
+

For Unix and Unix-emulation ftp servers, RFC1738 is not + respected and the lead slash is treated as the root, i.e., the + /path is handled equivalently to that in file URLs. The + distinction is irrelevant for anonymous ftp, but matters when + using ftp for non-anonymous accounts. If you are using ftp with a + Unix server and do wish to get a listing of the login directory + or have the path string treated as a file or path under + the login directory, include a tilde (~) as for file URLs, e.g.:

+ + 
+      ftp://user@myhost/~
+
+ +
+ +

The wais URL:

+ +

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

+ + 
+      wais://host:port/database
+      wais://host:port/database?wais_query
+      wais://host:port/database/wais_type/wais_path
+
+

where :port defaults to :210

+ +

Direct wais support is built into Lynx for + VMS, and can be compiled into Lynx on Unix.

+ +

If only a database is indicated in the URL, + Lynx returns an ISINDEX cover page for searching + that database, and will submit your search with the + wais_query appended. Lynx will convert + the server's reply into a hit list with URLs that include the + wais_type and wais_path for retrieving items + from the hit list.

+ +
+ +

The news, + nntp, and snews URLs:

+ +

The news and nntp URLs are handled by Lynx as + specified in RFC1738, but for compatibility with other clients, + Lynx allows inclusion of host and port fields in + news URLs, which properly should be used only in nntp + and snews URLs. If not included in news URLs, + Lynx will use the nntp server pointed to by the + NNTPSERVER environment variable or configuration symbol (see + lynx.cfg), with default port :119. A host field must be + included in nntp URLs, and the port field is optional with the + same default.

+ +

If the URL requires authentication, Lynx will + prompt you for the username and password. These are cached during + a session, for reuse on the same host. If $HOME/.newsauth exists, + Lynx initializes its cache from this file. The + .newsauth file contents are one line per entry: hostname, + password and username (in that order) separated by a space.

+ +

The formats are:

+ + 
+      news:newsgroup (retrieves list of messages in newsgroup)
+      news:messageID (retrieves the message)
+      news:* (retrieves list of all available newsgroups)
+      nntp://host:port/newsgroup
+      nntp://host:port/messageID
+      nntp://host:port/*
+
+

(snews same as nntp, but the default port is + :563)

+ +

The messageID is the message's unique identifier, + consisting of an identification string and the host of origin for + the message (ident_string@origin_host).

+ +

Lynx also supports wildcarding via an + asterisk for listings of news hierarchies or sub-hierarchies, + e.g.:

+ + 
+      news:comp.infosystems.*
+      nntp://host:port/comp.infosystems.*
+
+

(snews same as nntp, but the default port is + :563)
+ This is not in RFC1738 and may not be supported by all other + clients.

+ +

Lynx allows you both to reply to the + author of a news message via email, and, if news posting has been + enabled, to send a followup message to the newsgroup + (see newspost, newsreply, snewspost, + snewsreply).

+ +

Lynx converts any strings in news messages + which appear to be a URL with a supported scheme into a link for + accessing that URL.

+ +

Lynx also supports the newsgroup and message + number URL scheme:

+ + 
+      news:newsgroup/startNo-endNo (lists message range in newsgroup)
+      news:newsgroup/messageNo     (retrieves the message by number)
+      nntp://host:port/newsgroup/startNo-endNo
+      nntp://host:port/newsgroup/messageNo
+
+

(snews same as nntp, but the default port is + :563)
+ Use of this scheme is not recommended, because the message + numbers are specific to each nntp server, unlike the unique + identifiers for news messages.

+ +
+ +

The + newspost, newsreply, snewspost, and + snewsreply URLs:

+ +

When Lynx receives group listings or articles + via news, nntp or snews URLs, it also + checks whether the nntp server supports posting from the + Lynx user's site, and if so, includes links for + posting new messages to that server, or for posting followups + (replies) to previously posted messages. RFC1738, and IETF URL + drafts through this release of Lynx, do not + include any schemes for posting to news groups. + Lynx has long supported newspost and newreply + URL schemes for posting new messages or sending followups, + respectively, to standard nntp servers, with default port + :119. Lynx now also supports homologous + snewspost and snewsreply URLs for use with SSL capable nntp + servers.

+ +

The formats are:

+ + 
+      newspost://host:port/newsgroup(s)  (post a new message)
+      newsreply://host:port/newsgroup(s) (post a followup message)
+
+

(snewspost and snewsreply have the same formats, but the + default port is :563)

+ +

If the host field is omitted, it defaults to that pointed to + by the NNTPSERVER configuration or environmental variable. + Inclusion of at least one newsgroup in the URL is required, and + additional groups can be specified as a comma-separated list. + Wildcarding of newsgroup names is not supported for these URLs. + For newsreply and snewsreply URLs, if an external editor has been + defined via the Options Menu, the user is offered an + option to include the currently displayed document, which + presumably is a news article with a followup link that + was activated, and if confirmed, each line of that document is + prefixed with a right-angle-bracket. The user is expected to edit + such an inclusion so that only the passages relevant to the + followup message are retained.

+ +

These URLs can be used as command line startfiles (in which + case, Lynx will exit after posting the message, + and the newreply or snewsreply URLs degrade to newspost or + snewpost URLs, respectively). They also can be used as HREF + attribute values in any HTML document homologously to mailto URLs, with the qualification that they + presently are supported only by Lynx.

+ +
+ +

The mailto + URL:

+ +

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:

+ + 
+      mailto:user@host
+
+

The description of the mailto URL in RFC1738 has been + interpreted by some as allowing only a single recipient, but + Lynx invented the mailto URL, has always + supported a series of user@host addresses as a comma-separated + list, and still does. For compatibility with Explorer, + Lynx also accepts a semi-colon-separated + list.

+ +

For compatibility with Netscape, Lynx parses + any ?subject=The%20Subject appended to the URL, trims + the URL at the ?, and uses the value as the default + Subject: for the message or FORM content mailing. This is not + recommended practice. The preferred way to indicate the default + Subject: for a LINK or Anchor with a mailto HREF, or a FORM with + a mailto ACTION, is via a TITLE attribute with the subject string + as its value, e.g.:

+ + 
+      <LINK REV="made"
+            HREF="mailto:me@myhost,her@herhost" TITLE="The Subject">
+
+      <A HREF="mailto:user@host" TITLE="The Subject">...</A>
+
+      <FORM METHOD="post" ENCTYPE="text/plain"
+            ACTION="mailto:WebMaster@host" TITLE="The Subject">
+       ...
+      </FORM>
+
+

Note that a TITLE attribute for FORM is now included in the + HTML specifications. Some clients use a SUBJECT attribute for + this purpose in FORM tags, and Lynx recognizes + that as a synonym for TITLE.

+ +

Lynx also will process any + to=address(es), cc=address(es), + keywords=word_list and/or body=message fields + in ?searchpart tack-ons to mailto URLs. The to + and/or cc values can be single addresses, or comma- or + semi-colon-separated lists of addresses. All addresses, and any + body values, will be offered for approval by the user + before proceeding with a mailing. Any other name=value pairs in + the ?searchpart will be ignored. Also, if the mailto URL + is the ACTION for a FORM, any body in a + ?searchpart tack-on will be ignored, because the body of + the mailing must be constructed solely from the the FORM's + content. Lynx expects multiple name=value pairs + in a ?searchpart tack-on to be separated by ampersands, + as in the original Netscape implementation, and in an equally + ill-advised IETF draft of that implementation (draft-hoffman-mailto-url-03.txt). + These should be represented as entities (&amp;) in + the HTML markup. This functionality is generally desired, but the + IETF backward compatibility principal normally would lead to a + new scheme being used (e.g., mail:, or smtp:), + rather than breaking mailto: implementations.

+ +

If ENCTYPE="text/plain" is specified for a FORM with + a mailto ACTION, Lynx will not hex escape the + name=value pairs of the FORM's content, and will use physical + newlines instead of “&” or + “;” to separate the pairs, so that the + content will be readable directly. Otherwise, + Lynx will mail the content with the default:

+ + 
+      ENCTYPE="application/x-www-form-urlencoded" (“&” separates pairs)
+
+

or:

+ + 
+      ENCTYPE="application/sgml-form-urlencoded" (“;” separates pairs)
+
+

if the latter was indicated.

+ +

Note that when mailing FORM content Lynx + wraps any lines longer than 78 characters, to avoid buffer + overflows in mail software and to ensure reliable transmission + across gateways. If the ENCTYPE was not text/plain, any + script which decodes the mailed content should ignore the + physical newlines and recognize only hex escaped newline + characters as intended to be present in the decoded content.

+ +

If the mailto URL is not the ACTION for a FORM, and if an + external editor has been defined via the Options Menu, + the user is offered an option to include the currently displayed + document. If this option is accepted, each line of that document + is prefixed with a right-angle-bracket, and the prefixed + inclusion should be trimmed by the user to just those passages + relevant to the message which will be sent.

+ +
+ +

The finger + URL:

+ +

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:

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

Activating a finger URL will send a request to the finger + server via port 79 on the host specified. You can include + :79 in the URL, but no other value is allowed. The + /w or /%2fw is used to request a full report + for finger servers which support it, and is not case sensitive + (i.e., can be /W or /%2fW). Any strings in the + report which appear to be a URL with a supported scheme will be + converted into a link for accessing that URL.

+ +

An alternative way to access finger servers is via gopher URLs + with port 79 and the plain text (0) gophertype + specified:
+ gopher://host:79/0
+ Lynx will handle such URLs equivalently to overt + finger URLs, including creation of links for any strings which + appear to be supported URLs.

+ +
+ +

The cso URL:

+ +

The cso URL is intended to provide a gateway to CSO/PH (QI) + servers. The requests are made on port 105 by default + (:105), with the following overt cso URL format:

+ + 
+      cso://host
+
+

You also can use a gopher URL format with port 105 and the CSO + (2) gophertype specified:

+ + 
+      gopher://host:105/2
+
+

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.

+ +
+ +

The bibp URL:

+ +

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.

+ +

The lynxexec and + lynxprog URLs:

+ +

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

+ + 
+      lynxexec:dir/date/size foo:[blah] (VMS)
+      lynxexec:ls -l /foo/blah          (Unix)
+      lynxprog:news
+
+

(Note, however, that restrictions on acceptable commands or + utilities may be imposed by the system administrator.)

+ +

You optionally can include //localhost/ in the URL, + between the scheme field and the command, but that is always + implied. The lynxexec and lynxprog URLs differ only in that with + lynxexec you are prompted to enter RETURN before + Lynx clears the screen and restores the + previously displayed document, so that you can read any screen + output generated by the spawned command, whereas no such pause is + imposed upon exit from the utility invoked via lynxprog.

+ +

These are Lynxisms and should be used only in local documents + intended solely for Lynx.

+ +
+ +

The lynxcgi URL:

+ +

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:

+ + 
+      lynxcgi://localhost/path_to_CGI_script
+
+

where //localhost 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 + userdefs.h and lynx.cfg, qv.

+ +

This is a Lynxism and should be used only in local documents + intended solely for Lynx, or for limited local + testing of CGI scripts without an http server.

+ +
+ +

The NcFTP + URL:

+ +

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

+ + 
+        ftpHost:fileSpecification
+
+

for example

+ + 
+
+        ftp.gnu.org:/pub/gnu
+
+
+ +
+ +

The LYNXfoo + internal URLs:

+ +

Lynx uses a variety of private URL schemes + for communication among its internal modules. They start with + uppercase letters LYNX by convention, although, as + input, URL schemes are recognized in a case-insensitive + manner.

+ +

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

+ + + +

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

+ + 
+      Return to your <A HREF="LYNXHIST:0">Startfile</A>
+      Review your <A HREF="LYNXKEYMAP:">Keymap</A>
+
+

(No, they will not do any harm. Yes, they work. But do not + rely on it.)

+ +

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

+ + 
+      lynx LYNXKEYMAP:
+
+

But within Lynx, use the + “K” keystroke command. Sometimes it may be + convenient to use a private scheme with + “g”oto, as in:

+ + 
+      g LYNXMESSAGES:
+      g LYNXCOMPILEOPTS:
+      g LYNXCFG:
+
+

But again, there usually is a way in which those special pages + are meant to be reached that is more convenient.

+ + -- cgit v1.2.3