1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
|
<!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@sig.net">
</HEAD>
<BODY>
<blockquote>
<em>[</em><a href="#http">http, https</a> <em>|</em>
<a href="#telnet">telnet, tn3270, rlogin</a> <em>|</em>
<a href="#gopher">gopher</a> <em>|</em>
<a href="#file">file</a> <em>|</em>
<a href="#ftp">ftp</a> <em>|</em>
<a href="#wais">wais</a> <em>|</em>
<a href="#news">news, nntp, snews</a> <em>|</em>
<a href="#newspost">newspost, newsreply, snewspost, snewsreply</a> <em>|</em>
<a href="#mailto">mailto</a> <em>|</em>
<a href="#finger">finger</a> <em>|</em>
<a href="#cso">cso</a> <em>|</em>
<a href="#bibp">bibp</a> <em>|</em>
<a href="#exec">lynxexec, lynxprog</a> <em>|</em>
<a href="#cgi">lynxcgi</a><em>|</em>
<a href="#internal">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">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>.
Patches for support of https URLs and the CONNECT procedure are available
for qualified recipients via <a
href="http://www.trill-home.com/lynx.html">Lynx links</a>. 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.
<HR>
<H2><a name="telnet"
>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">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">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">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">file</a> URLs, e.g.:
<pre>
<em>ftp://user@myhost/~</em>
</pre>
<HR>
<H2><a name="wais">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"
>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. Patches for support of snews URLs are available to qualified
recipients via <a href="http://www.trill-home.com/lynx.html">Lynx links</a>
but cannot be included in the general distribution (sorry, see <a
href="#http">http and https</a>).
<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">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"
>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, but the latter requires patches for built
in SSL support, or use of a daemon which handles the secure communications
on behalf of Lynx.
<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 newgroup 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 presumeably 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">mailto</a> URLs, with the qualification that they presently
are supported only by Lynx.
<HR>
<H2><a name="mailto">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">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">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">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">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">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 recognised;
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.
<p>On VMS, you are advised to use the threaded OSU http server, available
from <a href="ftp://osu.edu"
>ftp://osu.edu</a> 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.
<HR>
<H2><a name="internal">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>
|