cernrules.txt

一个可用于linux下的命令行音乐播放器

# 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 <[e-mail]>.
#
# 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