From f06f1fc3d95167ec780cb0963548f2afdd548b20 Mon Sep 17 00:00:00 2001 From: "Thomas E. Dickey" Date: Sat, 11 Jun 2011 13:06:08 -0400 Subject: snapshot of project "lynx", label v2-8-8dev_8m --- lynx_help/lynx_url_support.html | 652 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 652 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 00000000..45f461d9 --- /dev/null +++ b/lynx_help/lynx_url_support.html @@ -0,0 +1,652 @@ + + + +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. +

+ +

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 won't do any harm. Yes, they work. But don't 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 1.4.1-2-gfad0