From e087f6d44e87f489fcb3056e86319ebba4218156 Mon Sep 17 00:00:00 2001 From: "Thomas E. Dickey" Date: Mon, 2 Sep 1996 19:39:24 -0400 Subject: snapshot of project "lynx", label v2_6 --- lynx_help/lynx_url_support.html | 493 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 493 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..8c0ed4f6 --- /dev/null +++ b/lynx_help/lynx_url_support.html @@ -0,0 +1,493 @@ + + + +URL Schemes Supported in Lynx + + + + + +[http, https | +telnet, tn3270, rlogin | +gopher | +file | +ftp | +wais | +news, nntp, snews | +mailto | +finger | +cso | +lynxexec, lynxprog | +lynxcgi| +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: +

+ +

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

+ +

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. Patches for support of https URLs and the CONNECT +procedure are available for qualified recipients via links in the +Lynx Enhanced +Pages. US Export laws and associated red tape pose severe +impediments to inclusion of this support in the general distributions +of freeware WWW clients such as Lynx. Sorry. +

+ +

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://username:password@host:port/path;type=[D,I, or A]
+ +

The default port is :21 and the default username +is anonymous. If username is included but not +:password, Lynx will prompt you for the password. This is +recommended, as otherwise the URL will have it completely unencrypted. +Do not include the @ if neither username nor +:password is included. 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. + +

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 direct wais support is not available, Lynx uses +the W3C wais gateway. + +

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 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. +Patches for support of snews URLs are available to qualified recipients via +links in the Lynx Enhanced Pages but cannot be included in the general +distribution (sorry, see http and https). +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. + +

For news URLs, Lynx allows you both to reply to the author +of a message via email, and, if news posting has been enabled, to send +a followup message to the newsgroup. Only email replies to the +author are permitted via nntp URLs. + +

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 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 has been proposed but not included +in any HTML specifications or drafts, and should be considered a Lynxism +until/unless it is. Some clients use a SUBJECT attribute for this purpose +in FORM tags, and Lynx recognizes that as a synonym for TITLE. + +

If ENCTYPE="text/plain" is specified for a FORM with a mailto +ACTION, Lynx will not hex escape the name=value pairs, 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. +

+ +

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 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:
+ly +nxcgi://localhost/path_to_CGI_script
+where //localhost/ is optional and always implied. +The output of the script must be text/html and is rendered and displayed +by Lynx. (Note that restrictions on acceptable paths can be imposed +by the system administrator.) + +

This is a Lynxism and should be used only in local documents intended +solely for Lynx. + +

On VMS, you are advised to use the threaded OSU http server, available +from ftp://osu.edu as freeware, if your site does not already have an http +server. It can be installed as a purely local script server, and is far +more efficient and comprehensive than any code which might be incorporated +within Lynx. +

+ +

The LYNXfoo internal URLs:

+ +Lynx uses a variety of internal URL schemes as structured stream +objects for communication among its display modules. If you discover +what they are, and are tempted to use them externally in documents, +find the self-restraint to 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>
+(Yes, they'll work. No, they won't do any harm. But...) + +

If you must try one, the second is OK from the command line:
+lynx LYNXKEYMAP:
+But within Lynx, use the 'K' keystroke command. + + -- cgit 1.4.1-2-gfad0