Edit File: cernrules.txt
# This files contains examples and an explanation for the RULESFILE / RULE # feature. # # Rules for Lynx are experimental. They provide a rudimentary capability # for URL rejection and substitution based on string matching. # Most users and most installations will not need this feature, it is here # in case you find it useful. Note that this may change or go away in # future releases of Lynx; if you find it useful, consider describing your # use of it in a message to <lynx-dev@nongnu.org>. # # Syntax: # ======= # Summary of common forms: # # Fail URL1 # Map URL1 URL2 [CONDITION] # Pass URL1 [URL2] [CONDITION] # Redirect URL1 URL2 [CONDITION] # RedirectPerm URL1 URL2 [CONDITION] # UseProxy URL1 PROXYURL [CONDITION] # UseProxy URL1 "none" [CONDITION] # # Alert URL1 MESSAGE [CONDITION] # AlwaysAlert URL1 MESSAGE [CONDITION] # UserMsg URL1 MESSAGE [CONDITION] # InfoMsg URL1 MESSAGE [CONDITION] # Progress URL1 MESSAGE [CONDITION] # # As you may have guessed, comments are introduced by a '#' character. # Rules have the general form # Operator Operand1 [Operand2] [CONDITION] # with words separated by whitespace. Words containing space can be quoted # with "double quotes". Although normally this should not be necessary # necessary for URLs, it has to be used for MESSAGE Operands in Alert etc. # See below for an explanation of the optional CONDITION. # # Recognized operators are # # Fail URL1 # Reject access to this URL, stop processing further rules. # # Map URL1 URL2 # Change the current URL to URL2, then continue processing. # # Pass URL1 [URL2] # Accept this URL and stop processing further rules; if URL2 # is given, apply this as the last mapping. # See the next item for reasons why you generally don't want to "pass" # a changed URL. # # RedirectTemp URL1 URL2 # RedirectPerm URL1 URL2 # Redirect [STATUS] URL1 URL2 # Stop processing further rules and redirect to URL2, just as if lynx had # received a HTTP redirection with URL2 as the new location. This means that # URL2 is subject to any applicable permission checking, if it passes a new # request will be issued (which may result in a new round of rules checking, # with a new "current URL") or the new URL might be taken from the cache, and, # after successful loading, lynx's idea of what the loaded document's URL is # will be fully updated. All this does not happen if you just "pass" a changed # URL (or let it fall through), so this is generally the preferred way for # substituting URLs. # If the RedirectPerm variant is used, or if the optional word is supplied and # is either "permanent" or "301", act as if lynx had received a permanent # redirection (with HTTP status 301). In most cases this will not make a # noticeable difference. Lynx may cache the location in a special way for 301 # redirections, so that the redirection is followed immediately the next time # the same original URL is accessed, without re-checking of rules. Therefore # the permanent variant should never be used if the desired outcome of rules # processing depends on variable conditions (see CONDITIONS below) or on # setting a special flag (see next item). # # PermitRedirection URL1 # Mark following redirection as permitted, and continue processing. Some # redirection locations are normally not allowed, because permitting them in a # response from an arbitrary remote server would open a security hole, and # others are not allowed if certain restrictions options are in effect. Among # redirection locations normally always forbidden are lynxprog: and lynxexec: # schemes. With "default" anonymous restrictions in effect, many URL schemes # are disallowed if the user would not be allowed to use them with 'g'oto. # This rule allows to override the permission checking if rules processing ends # with a Redirect (including the RedirectPerm or RedirectTemp forms). It is # ignored otherwise, in particular, it does not influence acceptance if rules # processing ends with a "Pass" and a real redirection is received in the # subsequent HTTP request. If redirections are chained, it only applies to the # redirection that ends the same rules cycle. Note that the new URL is still # subject to other permission checks that are not specific to redirections; but # using this rule may still weaken the expected effect of -anonymous, # -validate, -realm, and other restriction options, including TRUSTED_EXEC and # similar in lynx.cfg, so be careful where you redirect to if restrictions are # important! # # UseProxy URL1 PROXYURL # Stop processing further rules, and force access through the proxy given by # PROXYURL. PROXYURL should have the same form as required for foo_proxy # environment variables and lynx.cfg options, i.e., (unless you are trying to # do something unusual) "http://some.proxy-server.dom:port/". This rule # overrides any use of a proxy (or external gateway) that might otherwise apply # because of environment variables or lynx.cfg options, it also overrides any # "no_proxy" settings. # # UseProxy URL1 none # Mark request as NOT using any proxy (or external gateway), and continue # processing(!). For a request marked this way, any subsequent UseProxy # rule with a PROXYURL will be ignored, and any use of a proxy (or external # gateway) that might otherwise apply because of environment variables or # lynx.cfg options will be overridden. Note that the marking will not # survive a Redirect rule (since that will result, if successful, in a # new request). # # Alert URL1 MESSAGE # AlwaysAlert URL1 MESSAGE # UserMsg URL1 MESSAGE # InfoMsg URL1 MESSAGE # Progress URL1 MESSAGE # These produce various kinds of statusline messages, differing in whether # a pause is enforced and in its duration, immediately when the rule is # applied. AlwaysAlert shows the message text even in non-interactive mode # (-dump, -source, etc.). Rule processing continues after the message is # shown. As usual, these rules only apply if URL1 matches. MESSAGE is # the text to be displayed, it can contain one occurrence of "%s" which # will be replaced by the current URL, literal '%' characters should be # doubled as "%%". # # Rules are processed sequentially first to last for each request, a rule # applies if the current URL matches URL1. The current URL is initally the # URL for the resource the user is trying to access, but may change as the # result of applied Map rules. case-sensitive (!) string comparison is used, # in addition URL1 can contain one '*' which is interpreted as a wildcard # matching 0 or more characters. So if for example # "http://example.com/dir/doc.html" is requested, it would match any of # the following: # Pass http:* # Pass http://example.com/*.html # Pass http://example.com/* # Pass http://example* # Pass http://*/doc.html # but not: # Pass http://example/* # Pass http://Example.COM/dir/doc.html # Pass http://Example.COM/* # # If a URL2 is given and also contains a '*', that character will be # replaced by whatever matched in URL1. Processing stops with the # first matching "Fail" or "Pass" or when the end of the rules is reached. # If the end is reached without a "Fail" or "Pass", the URL is allowed # (equivalent to a final "Pass *"). # # The requested URL will have been transformed to Lynx's normal # representation. This means that local file resources should be # expected in the form "file://localhost/<path using slash separators>", # not in the machine's native representation for filenames. # # Anyone with experience configuring the venerable CERN httpd server will # recognize some of the syntax - in fact, the code implementing rules goes # back to a common ancestor. But note the differences: all URLs and URL- # patterns here have to be given as absolute URLs, even for local files. # (Absolute URLs don't imply proxying.) # # CONDITIONS # ---------- # All rules mentioned can be followed by an optional CONDITION, which can # be used to further restrict when the rule should be applied (in addition # to the match on URL1). A CONDITION takes one of the forms # "if" CONDITIONFLAG # "unless" CONDITIONFLAG # and currently two condition flags are recognized: # "userspecified" (or abbreviated "userspec") # "redirected" # To explain these, first some terms need to be defined. A "request" # is... # # A user action (like following a link, or entering a 'g'oto URL) can either be # rejected immediately (for example, because of restrictions in effect, or # because of invalid input), or can generate a "request". For the purpose of # this discussion, a "request" is the sequence of processing done by lynx, # which might ultimately lead to an actual network request and loading and # display of data; a request can also result in rejection (for example, some # restrictions are checked at this stage), or in a redirection. A redirection # in turn can be rejected (which makes the request fail), or can automatically # generate a new request. A "request chain" is the sequence of one or more # requests triggered by the same user event that are chained together by # redirections. # For each request, some URL schemes are handled (or rejected) specially, see # Limitation 1 below, the others are passed to the generic access code. Rules # processing occurs at the beginning of the generic access code, before a # request is dispatched to the scheme-specific protocol module (but after # checking whether the request can be satisfied by re-displaying an already # cached document). # With these definitions, the meaning of the possible CONDITIONFLAGS: # # if redirected # The rule applies if the current request results from a redirection; # whether that was a real HTTP redirection or one generated by a rule # in the previous request makes no difference. In other words, the # condition is true if the current request is not the first one in the # request chain. # # if userspecified # The rule applies if the initial URL of the request chain was specified # by the user. Lynx marks a request as "user specified" for URLs that # come from 'g'oto prompts, as well as for following links in a bookmark # or Jump file and some other special (lynx-generated) pages that may # contain URLs that were typed in by the user. # Note that this is not a property of the request, but of the whole request # chain (based on where the first request's URL came from). The current # URL may differ from what the user typed # - because of initial fixups, including conversion of Guess-URLs and file # paths to full URLs, # - because of Map rules applied, and/or # - because of a previous redirection. # So to make reasonably sure a suspicious or potentially dangerous URL has # been entered by the user, i.e. is not a link or external redirection # location that cannot be trusted, a combination of "userspecified" and # "redirected" flags should be used, for example # Fail URL1 unless userspecified # Fail URL1 if redirected # ... # # CAVEAT # ====== # First, to squash any false expectations, an example for what NOT TO DO. # It might be expected that a rule like # Fail file://localhost/etc/passwd # <- DON'T RELY ON THIS # could be used to prevent access to the file "/etc/passwd". This might # fool a naive user, but the more sophisticated user could still gain # access, by experimenting with other forms like (@@@ untested) # "file://<machine's domain name>/etc/passwd" or "/etc//passwd" # or "/etc/p%61asswd" or "/etc/passwd?" or "/etc/passwd#X" and so on. # There are many URL forms for accessing the same resource, and Lynx # just doesn't guarantee that URLs for the same resource will look the # same way. # # The same reservation applies to any attempts to block access to unwanted # sites and so on. This isn't the right place for implementing it. # (Lynx has a number of mechanisms documented elsewhere to restrict access, # see the INSTALLATION file, lynx.cfg, lynx -help, lynx -restrictions.) # # Some more useful applications: # # 1. Disabling URLs by access scheme # ---------------------------------- # Fail gopher:* # Fail finger:* # Fail lynxcgi:* # Fail LYNXIMGMAP:* # This should work (but no guarantees) because Lynx canonicalizes # the case of recognized access schemes and does not interpret # %-escaping in the scheme part (@@@ always?) # # Note that for many access schemes Lynx already has mechanisms to # restrict access (see lynx.cfg, -help, -restrictions, etc.), others # have to be specifically enabled. Those mechanisms should be used # in preference. # Note especially Limitation 1 below. # This can be used for the remaining cases, or in addition by the # more paranoid. Note that disabling "file:*" will also make many # of the special pages generated by lynx as temporary files (INFO, # history, ...) inaccessible, on the other hand it doesn't prevent # _writing_ of various temp files - probably not what you want. # # You could also direct access for a scheme to a brief text explaining # why it's not available: # Redirect news:* http://localhost/texts/newsserver-is-broken.html # # 2. Preventing accidental access # ------------------------------- # If there is a page or site you don't want to access for whatever # reason (say there's a link to it that crashes Lynx [don't forget to # report a bug], or if that starts sending you a 5 Mb file you don't # want, or you just don't like the people...), you can prevent yourself # from accidentally accessing it: # Fail http://bad.site.com/* # # 3. Compressed files # ------------------- # You have downloaded a bunch of HTML documents, and compressed them # to save space. Then you discover that links between the files don't # work, because they all use the names of the uncompressed files. The # following kind of rule will alow you to navigate, invisibly accessing # the compressed files: # Map file://localhost/somedir/*.html file://localhost/somedir/*.html.gz # or, perhaps better: # Redirect file://localhost/somedir/*.html file://localhost/somedir/*.html.gz # # 4. Use local copies # ------------------- # You have downloaded a tree of HTML documents, but there are many links # between them that still point to the remote location. You want to access # the local copies instead, after all that's why you downloaded them. You # could start editing the HTML, but the following might be simpler: # Map http://remote.com/docs/*.html file://localhost/home/me/docs/*.html # Or even combine this with compressing the files: # Map http://remote.com/docs/*.html file://localhost/home/me/docs/*.html.gz # # Again, replacing the "Map" with "Redirect" is probably better - it will # allow you to see the _real_ location on the lynx INFO screen or in the # HISTORY list, will avoid duplicates in the cache if the same document is # loaded with two different URLs, and may allow you to 'e'dit the local # from within lynx if you feel like it. # # 5. Broken links etc. # -------------------- # A user has moved from http://www.siteA.com/~jdoe to http://siteB.org/john, # or http://www.provider.com/company/ has moved to their own server # http://www.company.com, but there are still links to the old location # all over the place; they now are broken or lead to a stupid "this page # has moved, please update your bookmarks. Refresh in 5 seconds" page # which you're tired of seeing. This will not fix your bookmarks, and # it will let you see the outdated URLs for longer (Limitation 3 below), # but for a quick fix: # Redirect http://www.siteA.com/~jdoe/* http://siteB.org/john/* # Redirect http://www.provider.com/company/* http://www.company.com/* # # You could use "Map" instead of "Redirect", but this would let you see the # outdated URLs for longer and even bookmark them, and you are likely to # create invalid links if not all documents from a site are mapped # (Limitation 3). # # 6. DNS troubles # --------------- # A special case of broken links. If a site is inaccessible because the # name cannot be resolved (your or their name server is broken, or the # name registry once again made a mistake, or they really didn't pay in # time...) but you still somehow know the address; or if name lookups are # just too slow: # Map http://www.somesite.com/* http://10.1.2.3/* # (You could do the equivalent more cleanly by adding an entry to the hosts # file, if you have access to it.) # # Or, if a name resolves to several addresses of which one is down, and the # DNS hasn't caught up: # Map http://www.w3.org/* http://www12.w3.org/* # # Note that this can break access to some name-based virtually hosted sites. # # In this case use of "Map" is probably preferred over "Redirect", as long # as the URL on the left side contains the real and preferred hostname or # the problem is only temporary. # # 7. Avoid redirections # --------------------- # Some sites have a habit to provide links that don't go to the destination # directly but always force redirection via some intermediate URL. The # delay imposed by this, especially for users with slower connections and # for overloaded servers, can be avoided if the intermediate URLs always # follow some simple pattern: we can then anticipate the redirect that will # inevitably follow and generate it internally. For example, # Redirect http://lwn.net/cgi-bin/vr/* http://* # # Warning: The page authors may not like this circumvention. Often the # redirection is wanted by them to track access, sometimes in connection # with cookies. Some sites may employ mechanisms that defeat the shortcut. # It is your responsibility to decide whether use of this feature is # acceptable. (But note that the same effect can be achieved anyway for # any link by editing the URL, e.g. with the ELGOTO ('E') key in Lynx, so # a shortcut like this does not create some new kind of intrusion.) # # 8. Detailed proxy selection # --------------------------- # Basic use for this one should be obvious, if you have a need for it. # It simply allows selecting use (or non-use) of proxies on a more detailed # level than the traditional <scheme>_proxy and no_proxy variables, as well # as using different proxies for different sites. # For example, to request access through an anonymizing proxy for all pages # on a "suspicious" site: # UseProxy http://suspicious.site/* http://anonymyzing.proxy.dom/ # (as long as all URLs really have a matching form, not some alternative # like <http://suspicious.site:80/> or <http://SuSpIcIoUs.site/>!) # # To access some site through a local squid proxy, running on the same host # as lynx, except for some image types (say because you rarely access images # with lynx anyway, and if you do, you don't want them cached by the proxy): # UseProxy http://some.site/*.gif none # UseProxy http://some.site/*.jpg none # UseProxy http://some.site/* http://localhost:3128/ # Note that order is important here. # # To exempt a local address from all proxying: # UseProxy http://local.site/* none # # Note however that for some purposes the "no_proxy" setting may be better # suited than "UseProxy ... none", because of its different matching logic # (see comments in lynx.cfg). # # 9. Invent your own scheme # ------------------------- # Suppose you want to teach lynx to handle a completely new URL scheme. # If what's required for the new scheme is already available in lynx in # _some_ way, this may be possible with some inventive use of rules. # As an example, let's assume you want to introduce a simple "man:" scheme # for showing manual pages, so (for a Unix-like system, at least) "man:lynx" # would display the same help information as the "man lynx" command and so # on (we ignore section numbers etc. for simplicity here). # First, since lynx doesn't know anything about a "man:" scheme, it will # normally reject any such URLs at an early stage. However, a trick exists # to bypass that hurdle: define a man_proxy environment variable *outside of # lynx, before starting lynx* (it won't work in lynx.cfg), the actual value # is unimportant and won't actually be used. For example, in your shell: # export man_proxy=X # # If you already have some kind of HTTP-accessible man gateway available, # the task then probably just amounts to transforming the URL into the right # form. For one such gateway (in this case, a CGI script running on the # local machine), the rule # Redirect man:* http://localhost/cgi-bin/dwww?type=runman&location=*/ # or, alternatively, # UseProxy man:* none # Map man:* http://localhost/cgi-bin/dwww?type=runman&location=*/ # does it, for other setups the right-hand side just has to be modified # appropriately. The "UseProxy" is to make sure the bogus man_proxy gets # ignored. # # If no CGI-like access is available, you might want to invoke your system's # man command directly for a man: URL. Here is some discussion of how this # could be done, and why ultimately you may not want to do it; this is also # an opportunity to show examples for how some of the rules and conditions # can be used that haven't been discussed in detail elsewhere. # Lynx provides the lynxexec: (and the similar lynxprog:) scheme for running # (nearly) arbitrary commands locally. At the heart of employing it for # man: would be a rule like this: # Redirect man:* "lynxexec:/usr/bin/man *" # (It is a peculiarity of this scheme that the literal space and quoting # are necessary here. Also note that Map cannot be used here instead of # Redirect, since lynxexec, as a special kind of URL, needs to be handled # "early" in a request.) # Of course, execution of arbitrary commands is a potentially dangerous # thing. lynxexec has to be specifically enabled at compile time and in # lynx.cfg (or with command line options), and there are various levels # of control, too much to go into here. It is assumed in the following that # lynxexec has been enabled to the degree necessary (allow /usr/bin/man # execution) but hopefully not too much. # What needs to be prevented is that allowing local execution of the man # command might unintentionally open up unwanted execution of other commands, # possibly by some trick that could be exploited. For example, redirecting # man:* as above, the URL "man:lynx;rm -r *" could result in the command # "man lynx;rm -r *" executed by the system, with obvious disastrous results. # (This particular example won't actually work, for several reasons; but # for the purpose of discussion let's assume it did, there may be similar # ones that do.) # Because of such dangers, redirection to a lynxexec: is normally never # accepted by lynx. We need at least a PermitRedirection rule to override # this protective limitation: # PermitRedirection man:* # Redirect man:* "lynxexec:/usr/bin/man *" # But now we have potentially opened up local execution more than is # acceptable via the man: scheme, so this needs to be examined. # There are two aspects to security here: (1) restricting the user, and (2) # protecting the user. The first could also be phrased as protecting the # system from the user; the second as preventing lynx (and the system) from # doing things the user doesn't really want. Aspect (1) is very important # for setups providing anonymous guest accounts and similarly restricted # environments. (Otherwise shell access is normally allowed, and trying to # protect the system in lynx would be rather pointless.) As far as access # to some URLs is concerned, the difference can be characterized in terms of # which sources of URLs are trusted enough to allow access: for (1), only # links occurring in a limited number of documents are trusted enough for # some (or all) URLs, user input at 'g'oto prompts and the like is not (if # not completely disabled). For (2) and assuming a user with normal shell # privileges, the user may be trusted enough to accept any URL explicitly # entered, but URLs from arbitrary external sources are not - someone might # try to use them to trick the user (by following an innocent-looking link) # or lynx (by following a redirection) into doing something undesirable. # # In the following we are concerned with (2); it is assumed that providers # of anonymous accounts would not want to follow this path, and would have # no need for additional schemes that imply local execution anyway. (For # one thing, with the man example they would have to carefully check that # users cannot break out of the man command to a local shell prompt.) # # Getting back to the example, it was already mentioned that lynx does not # allow redirections to lynxexec. In fact this continues to be disallowed # for real redirection received from HTTP servers. But we have introduced # a new man: scheme, and the lynx code that does the redirection checking # doesn't know anything about special considerations for man: URLs, so # an external HTTP server might send a redirection message with "Location: # man:<something>", which lynx would allow, and which would in turn be # redirected by our rule to "lynxexec:/usr/bin/man <something>". Unless # we are 100% sure that either this can never happen or that the lynxexec # URL resulting from this can have no harmful effect, this needs to be # prevented. It can be done by checking for the "redirected" condition, # either by putting something like (the first line is of course optional) # Alert man:* "Redirection to man: not allowed" if redirected # Fail man:* if redirected # somewhere before the Redirect rule, or, reversing the logic, by adding # a condition to the redirection rules, i.e. they become # PermitRedirection man:* unless redirected # Redirect man:* "lynxexec:/usr/bin/man *" unless redirected # (actually, putting the condition on either one of the rules would be # sufficient). The second variant assumes that the attempted access to # man: via redirection will ultimately fail because there is no other way # to handle such URLs. # # The above should take care of rejecting man: URLs from redirections, but # what about regular links in HTML (like <A HREF="man:...">)? As long as # it can be assumed that the user will always inspect each and every link # before following it, and never follow a link that can have harmful effect, # no further restrictions are necessary. But this is a very big assumption, # unrealistic except perhaps in some single-user setups where the user is # is identical with the rule writer. So normally most links have to be # regarded as suspect, and only URLs entered by the user can be accepted: # Alert man:* "Redirection to man: not allowed" if redirected # Fail man:* if redirected # Alert man:* "Link to man: not allowed" unless userspecified # Fail man:* unless userspecified # # With these restrictions we have limited the ways our new man: scheme can # be used rather severely, to the point where its usefulness is questionable. # In addition to 'g'oto prompts, it may work in Jump files; also, should # links to man:<something> appear in HTML text, the user could retype them # manually or use the ELGOTO ('E') command with some trivial editing (like # adding a space) to "confirm" the URL. Even if the precautions outlined # above are followed: THIS TEXT DOES NOT IMPLY ANY PROMISE THAT, BY FOLLOWING # THE EXAMPLES, LYNX WILL BE SAFE. On the other hand, some of the precautions # *may* not be necessary: it is possible that careful use of TRUSTED_EXEC # options in lynx.cfg could offer enough protection while making the new # scheme more useful. # # If all this seems a bit too scary, that's intentional; it should be noted # that these considerations are not in general necessary for "harmless" URL # schemes, but appropriate for this "extreme" example. One last remark # regarding the hypothetical man scheme: instead of implementing it through # "lynxexec:" or "lynxprog:", it would be somewhat safer to use "lynxcgi:" # instead if it is supported. A simple lynxcgi script would have to write # the man page to stdout (either converted to text/html or as plain text, # preceded by an appropriate Content-Type header line), and all necessary # checking for special shell characters would be done within the script - # lynx does not use the system() function to run the script. # # Other Limitations # ================= # First, see CAVEAT above. There are other limitations: # # 1. Applicable URL schemes # ------------------------- # Rules processing does not apply to all URL schemes. Some are # handled differently from the generic access code, therefore rules # for such URLs will never be "seen". This limitation applies at # least to lynxexec:, lynxprog:, mailto:, LYNXHIST:, LYNXMESSAGES:, # LYNXCFG:, and LYNXCOMPILEOPTS: URLs. You shouldn't be tempted # to try to redirect most of these schemes anyway, but this also # makes it impossible to disable them with "Fail" rules. # # Also, a scheme has to be known to Lynx in order to get as far as # applying rules - you cannot just define your own new foobar: scheme # and then map it to something here, but see Application 9, above, # for a workaround. # # 2. No re-checking # ----------------- # When a URL is mapped to a different one, the new URL is not checked # again for compliance with most restrictions established by -anonymous, # -restrictions, lynx.cfg and so on. This can be regarded as a feature: # it allows specific exceptions. Of course it means that users for # whom any restrictions must be enforced cannot have write access to a # personal rules file, but that should be obvious anyway! # This limitation does not applies if "Redirect" is used, in that case # the new URL will always be re-examined. # # 3. Mappings are invisible # ------------------------- # Changing the URL with "Map" or "Pass" rules will in general not be # visible to the user, because it happens at a late stage of processing # a request (similar to directing a request through a proxy). One # can think of two kinds of URL for every resource: a "Document URL" as # the user sees it (on INFO page, history list, status line, etc.), and # a "physical URL" used for the actual access. Rules change only the # physical URL. This is different from the effect of HTTP redirection. # Often this is bad, sometimes it may be desirable. # # Changing the URL can create broken links if a document has relative URLs, # since they are taken to be relative to the "Document URL" (if no BASE tag # is present) when the HTML is parsed. # # This limitation does not apply if "Redirect" is used - the new location # will be visible to the user, and will be used by lynx for resolving # relative URLs within the document. # # 4. Interaction with proxying # ---------------------------- # Rules processing is done after most other access checks, but before # proxy (and gateway) settings are examined. A "Fail" rule works # as expected, but when the URL has been mapped to a different one, # the subsequent proxy checking can get confused. If it decides that # access is through a proxy or gateway, it will generally use the # original URL to construct the "physical" URL, effectively overriding # the mapping rules. If the mapping is to a different access scheme # or hostname, proxy checking could also be fooled to use a proxy when # it shouldn't, to not use one when it should, or (if different proxies # are used for different schemes) to use the wrong proxy. So "just # don't do that"; in some cases setting the no_proxy variable will help. # Example 3 happens to work nicely if there is a http_proxy but no # ftp_proxy. # # This limitation does not come into play if a "UseProxy" rule is applied, # in either of its two forms: with a PROXYURL, proxying is fully under # the control of the rules author, and with "none", subsequent proxy # and gateway checking is completely disabled. It is therefore a good # idea to combine any "Map" and "Pass" rules that might result in passing # the changed URL with explicit "UseProxy" rules, if the rules file is # expected to be used together with proxying; or else always use "Redirect" # instead of simple passing. # # 5. Case-sensitive matching # -------------------------- # The matching logic is generic string-based. It doesn't know anything # about URL syntax, and so it cannot know in which parts of a URL case # matters and where it doesn't. As a result, all comparisons are case- # sensitive. If (a limited number of) case variations of a URL need # to be dealt with, several rules can be used instead of one. # In particular, this makes "UseProxy ... none" in some ways more limited # than a no_proxy setting. # # 6. Redirection differences # -------------------------- # For some URLs lynx does never check after a request whether a redirection # occurs; that makes the "Redirect" rule useless for such URLs (in addition # to those mentioned under limitation 1.). Some of them are some gopher # types, telnet: and similar in most situations, newspost: and similar, # lynxcgi:, and some other private types. Trying to redirect these will # make access fail. You probable don't want to change such URLs anyway, # but if you feel you must, try using "Map" and "Pass" instead. # # The -noredir command line option only applies for real HTTP redirection # responses, Redirect rules are still applied. Also for certain other # command line options (-mime_header, -head) and command keys (HEAD) lynx # shows the redirection message (or part of it) in case of a real HTTP # redirection, instead of following the redirection. Here, too, a Redirect # rule remains effective (there is no redirection message to show, after all). # # 7. URLs required # ---------------- # Full absolute URLs (modulo possible "*" matching wildcards) are required # in rules. Strings like "www.somewhere.com" or "/some/dir/some.file" or # "www.somewhere.com/some/dir/some.file" are not URLs. Lynx may accept # them as user input, as abbreviated forms for URLs; but by the time the # rules get checked, those have been converted to full URLs, if they can # be recognized. This also means that rules cannot influence which strings # typed at a 'g'oto prompt are recognized for URLs - rules processing kicks # in later.
Back to File Manager