From 8346d0774d2d1e076038db27f65f1d082a460f16 Mon Sep 17 00:00:00 2001
From: Pixel <Pixel>
Date: Thu, 20 Sep 2001 23:27:01 +0000
Subject: Initial revision

---
 ABOUT-NLS            |  226 ++
 AUTHORS              |    2 +
 COPYING              |  340 ++
 COPYING.LIB          |  481 +++
 ChangeLog            |    1 +
 INSTALL              |  182 +
 Makefile.am          |    5 +
 NEWS                 |    0
 README               |    0
 acconfig.h           |   31 +
 autogen.sh           |   61 +
 config.guess         | 1183 ++++++
 config.sub           | 1268 +++++++
 configure.in         |  107 +
 doc/Makefile.am      |    1 +
 doc/rfc1866.txt      | 4315 ++++++++++++++++++++++
 doc/rfc2616.txt      | 9859 ++++++++++++++++++++++++++++++++++++++++++++++++++
 doc/rfc2812.txt      | 3531 ++++++++++++++++++
 include/Action.h     |   57 +
 include/Confirm.h    |   33 +
 include/Exceptions.h |   86 +
 include/Form.h       |   41 +
 include/Handle.h     |   51 +
 include/HttpServ.h   |   44 +
 include/Input.h      |   26 +
 include/Makefile.am  |    2 +
 include/Menu.h       |   35 +
 include/Message.h    |   32 +
 include/Output.h     |   26 +
 include/Socket.h     |   55 +
 include/String.h     |   89 +
 include/Table.h      |   36 +
 include/Variables.h  |   46 +
 include/template.h   |    8 +
 install-sh           |  251 ++
 lib/Action.cc        |   87 +
 lib/Confirm.cc       |   26 +
 lib/Exceptions.cc    |   88 +
 lib/Form.cc          |   56 +
 lib/Handle.cc        |  110 +
 lib/HttpServ.cc      |  297 ++
 lib/Input.cc         |   32 +
 lib/Makefile.am      |   12 +
 lib/Menu.cc          |   26 +
 lib/Message.cc       |   21 +
 lib/Output.cc        |   32 +
 lib/Socket.cc        |  140 +
 lib/String.cc        |  291 ++
 lib/Table.cc         |   41 +
 lib/Variables.cc     |   55 +
 lib/checkargs.c      |   85 +
 lib/datecalc.c       |   84 +
 ltconfig             | 3114 ++++++++++++++++
 ltmain.sh            | 4024 ++++++++++++++++++++
 missing              |  190 +
 mkinstalldirs        |   40 +
 po/ChangeLog         |    1 +
 po/Makefile.in.in    |  248 ++
 po/POTFILES.in       |   30 +
 po/stamp-cat-id      |    1 +
 src/Main.cc          |   80 +
 src/Makefile.am      |   14 +
 src/datas/grain.png  |  Bin 0 -> 9579 bytes
 src/datas/style.css  |   13 +
 src/misc.cc          |   66 +
 stamp-h.in           |    1 +
 66 files changed, 31816 insertions(+)
 create mode 100644 ABOUT-NLS
 create mode 100644 AUTHORS
 create mode 100644 COPYING
 create mode 100644 COPYING.LIB
 create mode 100644 ChangeLog
 create mode 100644 INSTALL
 create mode 100644 Makefile.am
 create mode 100644 NEWS
 create mode 100644 README
 create mode 100644 acconfig.h
 create mode 100755 autogen.sh
 create mode 100755 config.guess
 create mode 100755 config.sub
 create mode 100644 configure.in
 create mode 100644 doc/Makefile.am
 create mode 100644 doc/rfc1866.txt
 create mode 100644 doc/rfc2616.txt
 create mode 100644 doc/rfc2812.txt
 create mode 100644 include/Action.h
 create mode 100644 include/Confirm.h
 create mode 100644 include/Exceptions.h
 create mode 100644 include/Form.h
 create mode 100644 include/Handle.h
 create mode 100644 include/HttpServ.h
 create mode 100644 include/Input.h
 create mode 100644 include/Makefile.am
 create mode 100644 include/Menu.h
 create mode 100644 include/Message.h
 create mode 100644 include/Output.h
 create mode 100644 include/Socket.h
 create mode 100644 include/String.h
 create mode 100644 include/Table.h
 create mode 100644 include/Variables.h
 create mode 100644 include/template.h
 create mode 100755 install-sh
 create mode 100644 lib/Action.cc
 create mode 100644 lib/Confirm.cc
 create mode 100644 lib/Exceptions.cc
 create mode 100644 lib/Form.cc
 create mode 100644 lib/Handle.cc
 create mode 100644 lib/HttpServ.cc
 create mode 100644 lib/Input.cc
 create mode 100644 lib/Makefile.am
 create mode 100644 lib/Menu.cc
 create mode 100644 lib/Message.cc
 create mode 100644 lib/Output.cc
 create mode 100644 lib/Socket.cc
 create mode 100644 lib/String.cc
 create mode 100644 lib/Table.cc
 create mode 100644 lib/Variables.cc
 create mode 100644 lib/checkargs.c
 create mode 100644 lib/datecalc.c
 create mode 100755 ltconfig
 create mode 100644 ltmain.sh
 create mode 100755 missing
 create mode 100755 mkinstalldirs
 create mode 100644 po/ChangeLog
 create mode 100644 po/Makefile.in.in
 create mode 100644 po/POTFILES.in
 create mode 100644 po/stamp-cat-id
 create mode 100644 src/Main.cc
 create mode 100644 src/Makefile.am
 create mode 100644 src/datas/grain.png
 create mode 100644 src/datas/style.css
 create mode 100644 src/misc.cc
 create mode 100644 stamp-h.in

diff --git a/ABOUT-NLS b/ABOUT-NLS
new file mode 100644
index 0000000..28d38c7
--- /dev/null
+++ b/ABOUT-NLS
@@ -0,0 +1,226 @@
+Notes on the Free Translation Project
+*************************************
+
+   Free software is going international!  The Free Translation Project
+is a way to get maintainers of free software, translators, and users all
+together, so that will gradually become able to speak many languages.
+A few packages already provide translations for their messages.
+
+   If you found this `ABOUT-NLS' file inside a distribution, you may
+assume that the distributed package does use GNU `gettext' internally,
+itself available at your nearest GNU archive site.  But you do *not*
+need to install GNU `gettext' prior to configuring, installing or using
+this package with messages translated.
+
+   Installers will find here some useful hints.  These notes also
+explain how users should proceed for getting the programs to use the
+available translations.  They tell how people wanting to contribute and
+work at translations should contact the appropriate team.
+
+   When reporting bugs in the `intl/' directory or bugs which may be
+related to internationalization, you should tell about the version of
+`gettext' which is used.  The information can be found in the
+`intl/VERSION' file, in internationalized packages.
+
+One advise in advance
+=====================
+
+   If you want to exploit the full power of internationalization, you
+should configure it using
+
+     ./configure --with-included-gettext
+
+to force usage of internationalizing routines provided within this
+package, despite the existence of internationalizing capabilities in the
+operating system where this package is being installed.  So far, only
+the `gettext' implementation in the GNU C library version 2 provides as
+many features (such as locale alias or message inheritance) as the
+implementation here.  It is also not possible to offer this additional
+functionality on top of a `catgets' implementation.  Future versions of
+GNU `gettext' will very likely convey even more functionality.  So it
+might be a good idea to change to GNU `gettext' as soon as possible.
+
+   So you need not provide this option if you are using GNU libc 2 or
+you have installed a recent copy of the GNU gettext package with the
+included `libintl'.
+
+INSTALL Matters
+===============
+
+   Some packages are "localizable" when properly installed; the
+programs they contain can be made to speak your own native language.
+Most such packages use GNU `gettext'.  Other packages have their own
+ways to internationalization, predating GNU `gettext'.
+
+   By default, this package will be installed to allow translation of
+messages.  It will automatically detect whether the system provides
+usable `catgets' (if using this is selected by the installer) or
+`gettext' functions.  If neither is available, the GNU `gettext' own
+library will be used.  This library is wholly contained within this
+package, usually in the `intl/' subdirectory, so prior installation of
+the GNU `gettext' package is *not* required.  Installers may use
+special options at configuration time for changing the default
+behaviour.  The commands:
+
+     ./configure --with-included-gettext
+     ./configure --with-catgets
+     ./configure --disable-nls
+
+will respectively bypass any pre-existing `catgets' or `gettext' to use
+the internationalizing routines provided within this package, enable
+the use of the `catgets' functions (if found on the locale system), or
+else, *totally* disable translation of messages.
+
+   When you already have GNU `gettext' installed on your system and run
+configure without an option for your new package, `configure' will
+probably detect the previously built and installed `libintl.a' file and
+will decide to use this.  This might be not what is desirable.  You
+should use the more recent version of the GNU `gettext' library.  I.e.
+if the file `intl/VERSION' shows that the library which comes with this
+package is more recent, you should use
+
+     ./configure --with-included-gettext
+
+to prevent auto-detection.
+
+   By default the configuration process will not test for the `catgets'
+function and therefore they will not be used.  The reasons are already
+given above: the emulation on top of `catgets' cannot provide all the
+extensions provided by the GNU `gettext' library.  If you nevertheless
+want to use the `catgets' functions use
+
+     ./configure --with-catgets
+
+to enable the test for `catgets' (this causes no harm if `catgets' is
+not available on your system).  If you really select this option we
+would like to hear about the reasons because we cannot think of any
+good one ourself.
+
+   Internationalized packages have usually many `po/LL.po' files, where
+LL gives an ISO 639 two-letter code identifying the language.  Unless
+translations have been forbidden at `configure' time by using the
+`--disable-nls' switch, all available translations are installed
+together with the package.  However, the environment variable `LINGUAS'
+may be set, prior to configuration, to limit the installed set.
+`LINGUAS' should then contain a space separated list of two-letter
+codes, stating which languages are allowed.
+
+Using This Package
+==================
+
+   As a user, if your language has been installed for this package, you
+only have to set the `LANG' environment variable to the appropriate
+ISO 639 `LL' two-letter code prior to using the programs in the
+package.  For example, let's suppose that you speak German.  At the
+shell prompt, merely execute `setenv LANG de' (in `csh'),
+`export LANG; LANG=de' (in `sh') or `export LANG=de' (in `bash').  This
+can be done from your `.login' or `.profile' file, once and for all.
+
+   An operating system might already offer message localization for
+many of its programs, while other programs have been installed locally
+with the full capabilities of GNU `gettext'.  Just using `gettext'
+extended syntax for `LANG' would break proper localization of already
+available operating system programs.  In this case, users should set
+both `LANGUAGE' and `LANG' variables in their environment, as programs
+using GNU `gettext' give preference to `LANGUAGE'.  For example, some
+Swedish users would rather read translations in German than English for
+when Swedish is not available.  This is easily accomplished by setting
+`LANGUAGE' to `sv:de' while leaving `LANG' to `sv'.
+
+Translating Teams
+=================
+
+   For the Free Translation Project to be a success, we need interested
+people who like their own language and write it well, and who are also
+able to synergize with other translators speaking the same language.
+Each translation team has its own mailing list, courtesy of Linux
+International.  You may reach your translation team at the address
+`LL@li.org', replacing LL by the two-letter ISO 639 code for your
+language.  Language codes are *not* the same as the country codes given
+in ISO 3166.  The following translation teams exist, as of December
+1997:
+
+     Chinese `zh', Czech `cs', Danish `da', Dutch `nl', English `en',
+     Esperanto `eo', Finnish `fi', French `fr', German `de', Hungarian
+     `hu', Irish `ga', Italian `it', Indonesian `id', Japanese `ja',
+     Korean `ko', Latin `la', Norwegian `no', Persian `fa', Polish
+     `pl', Portuguese `pt', Russian `ru', Slovenian `sl', Spanish `es',
+     Swedish `sv', and Turkish `tr'.
+
+For example, you may reach the Chinese translation team by writing to
+`zh@li.org'.
+
+   If you'd like to volunteer to *work* at translating messages, you
+should become a member of the translating team for your own language.
+The subscribing address is *not* the same as the list itself, it has
+`-request' appended.  For example, speakers of Swedish can send a
+message to `sv-request@li.org', having this message body:
+
+     subscribe
+
+   Keep in mind that team members are expected to participate
+*actively* in translations, or at solving translational difficulties,
+rather than merely lurking around.  If your team does not exist yet and
+you want to start one, or if you are unsure about what to do or how to
+get started, please write to `translation@iro.umontreal.ca' to reach the
+coordinator for all translator teams.
+
+   The English team is special.  It works at improving and uniformizing
+the terminology in use.  Proven linguistic skill are praised more than
+programming skill, here.
+
+Available Packages
+==================
+
+   Languages are not equally supported in all packages.  The following
+matrix shows the current state of internationalization, as of December
+1997.  The matrix shows, in regard of each package, for which languages
+PO files have been submitted to translation coordination.
+
+     Ready PO files    cs da de en es fi fr it ja ko nl no pl pt ru sl sv
+                     .----------------------------------------------------.
+     bash            |       []          []          []                   |  3
+     bison           |       []          []          []                   |  3
+     clisp           |       [] [] []    []                               |  4
+     cpio            |       []    []    []       [] []    []             |  6
+     diffutils       |       []    []    []                []          [] |  5
+     enscript        |       []    [] [] []          []             []    |  6
+     fileutils       | []    []    []    []       [] []    [] []    [] [] | 10
+     findutils       |       []    []    [] []    [] []    []    []    [] |  9
+     flex            |             []    []       []                   [] |  4
+     gcal            |       []          []          []    []          [] |  5
+     gettext         |    [] []    []    []       [] [] [] [] []    [] [] | 12
+     grep            |       []    []    []       [] [] [] []    [] [] [] | 10
+     hello           |    [] []    []    []       [] [] [] [] []    [] [] | 11
+     id-utils        |       []          []                []             |  3
+     indent          |    [] []                   []       []    []       |  5
+     libc            |       []    []    []       [] []    []          [] |  7
+     m4              |       []          []    []    []          []    [] |  6
+     make            |       []    []    []       [] []    []             |  6
+     music           |                   []                []             |  2
+     ptx             |       []    []    []          [] [] [] []       [] |  8
+     recode          |    [] []    []    []          []    [] []    [] [] |  9
+     sh-utils        |       []    []    []          [] [] [] []       [] |  8
+     sharutils       | []    []    []    []          []                [] |  6
+     tar             | []    []          [] []    [] [] [] [] []    [] [] | 11
+     texinfo         | []    []          []                               |  3
+     textutils       | []    []    []    []       [] [] [] []          [] |  9
+     wdiff           | []    []    []    []          [] [] []          [] |  8
+                     `----------------------------------------------------'
+       17 languages    cs da de en es fi fr it ja ko nl no pl pt ru sl sv
+       27 packages      6  4 25  1 18  1 26  2  1 12 20  9 19  7  4  7 17  179
+
+   Some counters in the preceding matrix are higher than the number of
+visible blocks let us expect.  This is because a few extra PO files are
+used for implementing regional variants of languages, or language
+dialects.
+
+   For a PO file in the matrix above to be effective, the package to
+which it applies should also have been internationalized and
+distributed as such by its maintainer.  There might be an observable
+lag between the mere existence a PO file and its wide availability in a
+distribution.
+
+   If December 1997 seems to be old, you may fetch a more recent copy
+of this `ABOUT-NLS' file on most GNU archive sites.
+
diff --git a/AUTHORS b/AUTHORS
new file mode 100644
index 0000000..0c9a4b9
--- /dev/null
+++ b/AUTHORS
@@ -0,0 +1,2 @@
+Nicolas NOBLE aka Pixel <Pixel@nobis-crew.org>
+
diff --git a/COPYING b/COPYING
new file mode 100644
index 0000000..d60c31a
--- /dev/null
+++ b/COPYING
@@ -0,0 +1,340 @@
+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+	    How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) year  name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/COPYING.LIB b/COPYING.LIB
new file mode 100644
index 0000000..eb685a5
--- /dev/null
+++ b/COPYING.LIB
@@ -0,0 +1,481 @@
+		  GNU LIBRARY GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1991 Free Software Foundation, Inc.
+                    675 Mass Ave, Cambridge, MA 02139, USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the library GPL.  It is
+ numbered 2 because it goes with version 2 of the ordinary GPL.]
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+  This license, the Library General Public License, applies to some
+specially designated Free Software Foundation software, and to any
+other libraries whose authors decide to use it.  You can use it for
+your libraries, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if
+you distribute copies of the library, or if you modify it.
+
+  For example, if you distribute copies of the library, whether gratis
+or for a fee, you must give the recipients all the rights that we gave
+you.  You must make sure that they, too, receive or can get the source
+code.  If you link a program with the library, you must provide
+complete object files to the recipients so that they can relink them
+with the library, after making changes to the library and recompiling
+it.  And you must show them these terms so they know their rights.
+
+  Our method of protecting your rights has two steps: (1) copyright
+the library, and (2) offer you this license which gives you legal
+permission to copy, distribute and/or modify the library.
+
+  Also, for each distributor's protection, we want to make certain
+that everyone understands that there is no warranty for this free
+library.  If the library is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original
+version, so that any problems introduced by others will not reflect on
+the original authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that companies distributing free
+software will individually obtain patent licenses, thus in effect
+transforming the program into proprietary software.  To prevent this,
+we have made it clear that any patent must be licensed for everyone's
+free use or not licensed at all.
+
+  Most GNU software, including some libraries, is covered by the ordinary
+GNU General Public License, which was designed for utility programs.  This
+license, the GNU Library General Public License, applies to certain
+designated libraries.  This license is quite different from the ordinary
+one; be sure to read it in full, and don't assume that anything in it is
+the same as in the ordinary license.
+
+  The reason we have a separate public license for some libraries is that
+they blur the distinction we usually make between modifying or adding to a
+program and simply using it.  Linking a program with a library, without
+changing the library, is in some sense simply using the library, and is
+analogous to running a utility program or application program.  However, in
+a textual and legal sense, the linked executable is a combined work, a
+derivative of the original library, and the ordinary General Public License
+treats it as such.
+
+  Because of this blurred distinction, using the ordinary General
+Public License for libraries did not effectively promote software
+sharing, because most developers did not use the libraries.  We
+concluded that weaker conditions might promote sharing better.
+
+  However, unrestricted linking of non-free programs would deprive the
+users of those programs of all benefit from the free status of the
+libraries themselves.  This Library General Public License is intended to
+permit developers of non-free programs to use free libraries, while
+preserving your freedom as a user of such programs to change the free
+libraries that are incorporated in them.  (We have not seen how to achieve
+this as regards changes in header files, but we have achieved it as regards
+changes in the actual functions of the Library.)  The hope is that this
+will lead to faster development of free libraries.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.  Pay close attention to the difference between a
+"work based on the library" and a "work that uses the library".  The
+former contains code derived from the library, while the latter only
+works together with the library.
+
+  Note that it is possible for a library to be covered by the ordinary
+General Public License rather than by this special one.
+
+		  GNU LIBRARY GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License Agreement applies to any software library which
+contains a notice placed by the copyright holder or other authorized
+party saying it may be distributed under the terms of this Library
+General Public License (also called "this License").  Each licensee is
+addressed as "you".
+
+  A "library" means a collection of software functions and/or data
+prepared so as to be conveniently linked with application programs
+(which use some of those functions and data) to form executables.
+
+  The "Library", below, refers to any such software library or work
+which has been distributed under these terms.  A "work based on the
+Library" means either the Library or any derivative work under
+copyright law: that is to say, a work containing the Library or a
+portion of it, either verbatim or with modifications and/or translated
+straightforwardly into another language.  (Hereinafter, translation is
+included without limitation in the term "modification".)
+
+  "Source code" for a work means the preferred form of the work for
+making modifications to it.  For a library, complete source code means
+all the source code for all modules it contains, plus any associated
+interface definition files, plus the scripts used to control compilation
+and installation of the library.
+
+  Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running a program using the Library is not restricted, and output from
+such a program is covered only if its contents constitute a work based
+on the Library (independent of the use of the Library in a tool for
+writing it).  Whether that is true depends on what the Library does
+and what the program that uses the Library does.
+  
+  1. You may copy and distribute verbatim copies of the Library's
+complete source code as you receive it, in any medium, provided that
+you conspicuously and appropriately publish on each copy an
+appropriate copyright notice and disclaimer of warranty; keep intact
+all the notices that refer to this License and to the absence of any
+warranty; and distribute a copy of this License along with the
+Library.
+
+  You may charge a fee for the physical act of transferring a copy,
+and you may at your option offer warranty protection in exchange for a
+fee.
+
+  2. You may modify your copy or copies of the Library or any portion
+of it, thus forming a work based on the Library, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) The modified work must itself be a software library.
+
+    b) You must cause the files modified to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    c) You must cause the whole of the work to be licensed at no
+    charge to all third parties under the terms of this License.
+
+    d) If a facility in the modified Library refers to a function or a
+    table of data to be supplied by an application program that uses
+    the facility, other than as an argument passed when the facility
+    is invoked, then you must make a good faith effort to ensure that,
+    in the event an application does not supply such function or
+    table, the facility still operates, and performs whatever part of
+    its purpose remains meaningful.
+
+    (For example, a function in a library to compute square roots has
+    a purpose that is entirely well-defined independent of the
+    application.  Therefore, Subsection 2d requires that any
+    application-supplied function or table used by this function must
+    be optional: if the application does not supply it, the square
+    root function must still compute square roots.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Library,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Library, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote
+it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Library.
+
+In addition, mere aggregation of another work not based on the Library
+with the Library (or with a work based on the Library) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may opt to apply the terms of the ordinary GNU General Public
+License instead of this License to a given copy of the Library.  To do
+this, you must alter all the notices that refer to this License, so
+that they refer to the ordinary GNU General Public License, version 2,
+instead of to this License.  (If a newer version than version 2 of the
+ordinary GNU General Public License has appeared, then you can specify
+that version instead if you wish.)  Do not make any other change in
+these notices.
+
+  Once this change is made in a given copy, it is irreversible for
+that copy, so the ordinary GNU General Public License applies to all
+subsequent copies and derivative works made from that copy.
+
+  This option is useful when you wish to copy part of the code of
+the Library into a program that is not a library.
+
+  4. You may copy and distribute the Library (or a portion or
+derivative of it, under Section 2) in object code or executable form
+under the terms of Sections 1 and 2 above provided that you accompany
+it with the complete corresponding machine-readable source code, which
+must be distributed under the terms of Sections 1 and 2 above on a
+medium customarily used for software interchange.
+
+  If distribution of object code is made by offering access to copy
+from a designated place, then offering equivalent access to copy the
+source code from the same place satisfies the requirement to
+distribute the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  5. A program that contains no derivative of any portion of the
+Library, but is designed to work with the Library by being compiled or
+linked with it, is called a "work that uses the Library".  Such a
+work, in isolation, is not a derivative work of the Library, and
+therefore falls outside the scope of this License.
+
+  However, linking a "work that uses the Library" with the Library
+creates an executable that is a derivative of the Library (because it
+contains portions of the Library), rather than a "work that uses the
+library".  The executable is therefore covered by this License.
+Section 6 states terms for distribution of such executables.
+
+  When a "work that uses the Library" uses material from a header file
+that is part of the Library, the object code for the work may be a
+derivative work of the Library even though the source code is not.
+Whether this is true is especially significant if the work can be
+linked without the Library, or if the work is itself a library.  The
+threshold for this to be true is not precisely defined by law.
+
+  If such an object file uses only numerical parameters, data
+structure layouts and accessors, and small macros and small inline
+functions (ten lines or less in length), then the use of the object
+file is unrestricted, regardless of whether it is legally a derivative
+work.  (Executables containing this object code plus portions of the
+Library will still fall under Section 6.)
+
+  Otherwise, if the work is a derivative of the Library, you may
+distribute the object code for the work under the terms of Section 6.
+Any executables containing that work also fall under Section 6,
+whether or not they are linked directly with the Library itself.
+
+  6. As an exception to the Sections above, you may also compile or
+link a "work that uses the Library" with the Library to produce a
+work containing portions of the Library, and distribute that work
+under terms of your choice, provided that the terms permit
+modification of the work for the customer's own use and reverse
+engineering for debugging such modifications.
+
+  You must give prominent notice with each copy of the work that the
+Library is used in it and that the Library and its use are covered by
+this License.  You must supply a copy of this License.  If the work
+during execution displays copyright notices, you must include the
+copyright notice for the Library among them, as well as a reference
+directing the user to the copy of this License.  Also, you must do one
+of these things:
+
+    a) Accompany the work with the complete corresponding
+    machine-readable source code for the Library including whatever
+    changes were used in the work (which must be distributed under
+    Sections 1 and 2 above); and, if the work is an executable linked
+    with the Library, with the complete machine-readable "work that
+    uses the Library", as object code and/or source code, so that the
+    user can modify the Library and then relink to produce a modified
+    executable containing the modified Library.  (It is understood
+    that the user who changes the contents of definitions files in the
+    Library will not necessarily be able to recompile the application
+    to use the modified definitions.)
+
+    b) Accompany the work with a written offer, valid for at
+    least three years, to give the same user the materials
+    specified in Subsection 6a, above, for a charge no more
+    than the cost of performing this distribution.
+
+    c) If distribution of the work is made by offering access to copy
+    from a designated place, offer equivalent access to copy the above
+    specified materials from the same place.
+
+    d) Verify that the user has already received a copy of these
+    materials or that you have already sent this user a copy.
+
+  For an executable, the required form of the "work that uses the
+Library" must include any data and utility programs needed for
+reproducing the executable from it.  However, as a special exception,
+the source code distributed need not include anything that is normally
+distributed (in either source or binary form) with the major
+components (compiler, kernel, and so on) of the operating system on
+which the executable runs, unless that component itself accompanies
+the executable.
+
+  It may happen that this requirement contradicts the license
+restrictions of other proprietary libraries that do not normally
+accompany the operating system.  Such a contradiction means you cannot
+use both them and the Library together in an executable that you
+distribute.
+
+  7. You may place library facilities that are a work based on the
+Library side-by-side in a single library together with other library
+facilities not covered by this License, and distribute such a combined
+library, provided that the separate distribution of the work based on
+the Library and of the other library facilities is otherwise
+permitted, and provided that you do these two things:
+
+    a) Accompany the combined library with a copy of the same work
+    based on the Library, uncombined with any other library
+    facilities.  This must be distributed under the terms of the
+    Sections above.
+
+    b) Give prominent notice with the combined library of the fact
+    that part of it is a work based on the Library, and explaining
+    where to find the accompanying uncombined form of the same work.
+
+  8. You may not copy, modify, sublicense, link with, or distribute
+the Library except as expressly provided under this License.  Any
+attempt otherwise to copy, modify, sublicense, link with, or
+distribute the Library is void, and will automatically terminate your
+rights under this License.  However, parties who have received copies,
+or rights, from you under this License will not have their licenses
+terminated so long as such parties remain in full compliance.
+
+  9. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Library or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Library (or any work based on the
+Library), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Library or works based on it.
+
+  10. Each time you redistribute the Library (or any work based on the
+Library), the recipient automatically receives a license from the
+original licensor to copy, distribute, link with or modify the Library
+subject to these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  11. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Library at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Library by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Library.
+
+If any portion of this section is held invalid or unenforceable under any
+particular circumstance, the balance of the section is intended to apply,
+and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  12. If the distribution and/or use of the Library is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Library under this License may add
+an explicit geographical distribution limitation excluding those countries,
+so that distribution is permitted only in or among countries not thus
+excluded.  In such case, this License incorporates the limitation as if
+written in the body of this License.
+
+  13. The Free Software Foundation may publish revised and/or new
+versions of the Library General Public License from time to time.
+Such new versions will be similar in spirit to the present version,
+but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Library
+specifies a version number of this License which applies to it and
+"any later version", you have the option of following the terms and
+conditions either of that version or of any later version published by
+the Free Software Foundation.  If the Library does not specify a
+license version number, you may choose any version ever published by
+the Free Software Foundation.
+
+  14. If you wish to incorporate parts of the Library into other free
+programs whose distribution conditions are incompatible with these,
+write to the author to ask for permission.  For software which is
+copyrighted by the Free Software Foundation, write to the Free
+Software Foundation; we sometimes make exceptions for this.  Our
+decision will be guided by the two goals of preserving the free status
+of all derivatives of our free software and of promoting the sharing
+and reuse of software generally.
+
+			    NO WARRANTY
+
+  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
+WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
+OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
+KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
+LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
+THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
+AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
+FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
+RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
+FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
+SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+     Appendix: How to Apply These Terms to Your New Libraries
+
+  If you develop a new library, and you want it to be of the greatest
+possible use to the public, we recommend making it free software that
+everyone can redistribute and change.  You can do so by permitting
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+
+  To apply these terms, attach the following notices to the library.  It is
+safest to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the library's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This library is free software; you can redistribute it and/or
+    modify it under the terms of the GNU Library General Public
+    License as published by the Free Software Foundation; either
+    version 2 of the License, or (at your option) any later version.
+
+    This library is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+    Library General Public License for more details.
+
+    You should have received a copy of the GNU Library General Public
+    License along with this library; if not, write to the Free
+    Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+Also add information on how to contact you by electronic and paper mail.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the
+  library `Frob' (a library for tweaking knobs) written by James Random Hacker.
+
+  <signature of Ty Coon>, 1 April 1990
+  Ty Coon, President of Vice
+
+That's all there is to it!
diff --git a/ChangeLog b/ChangeLog
new file mode 100644
index 0000000..09de061
--- /dev/null
+++ b/ChangeLog
@@ -0,0 +1 @@
+First release.
\ No newline at end of file
diff --git a/INSTALL b/INSTALL
new file mode 100644
index 0000000..b42a17a
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,182 @@
+Basic Installation
+==================
+
+   These are generic installation instructions.
+
+   The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation.  It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions.  Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, a file
+`config.cache' that saves the results of its tests to speed up
+reconfiguring, and a file `config.log' containing compiler output
+(useful mainly for debugging `configure').
+
+   If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release.  If at some point `config.cache'
+contains results you don't want to keep, you may remove or edit it.
+
+   The file `configure.in' is used to create `configure' by a program
+called `autoconf'.  You only need `configure.in' if you want to change
+it or regenerate `configure' using a newer version of `autoconf'.
+
+The simplest way to compile this package is:
+
+  1. `cd' to the directory containing the package's source code and type
+     `./configure' to configure the package for your system.  If you're
+     using `csh' on an old version of System V, you might need to type
+     `sh ./configure' instead to prevent `csh' from trying to execute
+     `configure' itself.
+
+     Running `configure' takes awhile.  While running, it prints some
+     messages telling which features it is checking for.
+
+  2. Type `make' to compile the package.
+
+  3. Optionally, type `make check' to run any self-tests that come with
+     the package.
+
+  4. Type `make install' to install the programs and any data files and
+     documentation.
+
+  5. You can remove the program binaries and object files from the
+     source code directory by typing `make clean'.  To also remove the
+     files that `configure' created (so you can compile the package for
+     a different kind of computer), type `make distclean'.  There is
+     also a `make maintainer-clean' target, but that is intended mainly
+     for the package's developers.  If you use it, you may have to get
+     all sorts of other programs in order to regenerate files that came
+     with the distribution.
+
+Compilers and Options
+=====================
+
+   Some systems require unusual options for compilation or linking that
+the `configure' script does not know about.  You can give `configure'
+initial values for variables by setting them in the environment.  Using
+a Bourne-compatible shell, you can do that on the command line like
+this:
+     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
+
+Or on systems that have the `env' program, you can do it like this:
+     env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
+
+Compiling For Multiple Architectures
+====================================
+
+   You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory.  To do this, you must use a version of `make' that
+supports the `VPATH' variable, such as GNU `make'.  `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script.  `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'.
+
+   If you have to use a `make' that does not supports the `VPATH'
+variable, you have to compile the package for one architecture at a time
+in the source code directory.  After you have installed the package for
+one architecture, use `make distclean' before reconfiguring for another
+architecture.
+
+Installation Names
+==================
+
+   By default, `make install' will install the package's files in
+`/usr/local/bin', `/usr/local/man', etc.  You can specify an
+installation prefix other than `/usr/local' by giving `configure' the
+option `--prefix=PATH'.
+
+   You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files.  If you
+give `configure' the option `--exec-prefix=PATH', the package will use
+PATH as the prefix for installing programs and libraries.
+Documentation and other data files will still use the regular prefix.
+
+   In addition, if you use an unusual directory layout you can give
+options like `--bindir=PATH' to specify different values for particular
+kinds of files.  Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them.
+
+   If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+Optional Features
+=================
+
+   Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System).  The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+   For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+Specifying the System Type
+==========================
+
+   There may be some features `configure' can not figure out
+automatically, but needs to determine by the type of host the package
+will run on.  Usually `configure' can figure that out, but if it prints
+a message saying it can not guess the host type, give it the
+`--host=TYPE' option.  TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name with three fields:
+     CPU-COMPANY-SYSTEM
+
+See the file `config.sub' for the possible values of each field.  If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the host type.
+
+   If you are building compiler tools for cross-compiling, you can also
+use the `--target=TYPE' option to select the type of system they will
+produce code for and the `--build=TYPE' option to select the type of
+system on which you are compiling the package.
+
+Sharing Defaults
+================
+
+   If you want to set default values for `configure' scripts to share,
+you can create a site shell script called `config.site' that gives
+default values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists.  Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Operation Controls
+==================
+
+   `configure' recognizes the following options to control how it
+operates.
+
+`--cache-file=FILE'
+     Use and save the results of the tests in FILE instead of
+     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
+     debugging `configure'.
+
+`--help'
+     Print a summary of the options to `configure', and exit.
+
+`--quiet'
+`--silent'
+`-q'
+     Do not print messages saying which checks are being made.  To
+     suppress all normal output, redirect it to `/dev/null' (any error
+     messages will still be shown).
+
+`--srcdir=DIR'
+     Look for the package's source code in directory DIR.  Usually
+     `configure' can determine that directory automatically.
+
+`--version'
+     Print the version of Autoconf used to generate the `configure'
+     script, and exit.
+
+`configure' also accepts some other, not widely useful, options.
diff --git a/Makefile.am b/Makefile.am
new file mode 100644
index 0000000..3ba0f71
--- /dev/null
+++ b/Makefile.am
@@ -0,0 +1,5 @@
+localedir = $(datadir)/locale
+
+SUBDIRS = lib include doc po intl src
+AM_CFLAGS = -Wall -Wstrict-prototypes -g
+INCLUDES = -I. -I$(includedir) -I../include
diff --git a/NEWS b/NEWS
new file mode 100644
index 0000000..e69de29
diff --git a/README b/README
new file mode 100644
index 0000000..e69de29
diff --git a/acconfig.h b/acconfig.h
new file mode 100644
index 0000000..a03aca1
--- /dev/null
+++ b/acconfig.h
@@ -0,0 +1,31 @@
+#undef HAVE_LIBINTL_H
+
+/* Define to 1 if NLS is requested.  */
+#undef ENABLE_NLS
+
+/* Define as 1 if you have catgets and don't want to use GNU gettext.  */
+#undef HAVE_CATGETS
+
+/* Define as 1 if you have gettext and don't want to use GNU gettext.  */
+#undef HAVE_GETTEXT
+
+/* Define if your locale.h file contains LC_MESSAGES.  */
+#undef HAVE_LC_MESSAGES
+
+/* Define as 1 if you have the stpcpy function.  */
+#undef HAVE_STPCPY
+
+#if ENABLE_NLS
+# ifndef HAVE_LIBINTL_H
+#  define HAVE_LIBINTL_H 1
+# endif
+# include <libintl.h>
+# define _(Text) gettext (Text)
+#else
+# define bindtextdomain(Domain, Directory)
+# define textdomain(Domain)
+# define _(Text) Text
+# define gettext(z) z
+#endif
+#define N_(Text) Text
+
diff --git a/autogen.sh b/autogen.sh
new file mode 100755
index 0000000..0849fa8
--- /dev/null
+++ b/autogen.sh
@@ -0,0 +1,61 @@
+#!/bin/sh
+# Run this to generate all the initial makefiles, etc.
+
+srcdir=`dirname $0`
+test -z "$srcdir" && srcdir=.
+
+ORIGDIR=`pwd`
+cd $srcdir
+PROJECT=Baltisot
+TEST_TYPE=-f
+FILE=src/Main.cc
+
+DIE=0
+
+(autoconf --version) < /dev/null > /dev/null 2>&1 || {
+	echo
+	echo "You must have autoconf installed to compile $PROJECT."
+	echo "Download the appropriate package for your distribution,"
+	echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/"
+	DIE=1
+}
+
+(automake --version) < /dev/null > /dev/null 2>&1 || {
+	echo
+	echo "You must have automake installed to compile $PROJECT."
+	echo "Get ftp://sourceware.cygnus.com/pub/automake/automake-1.4.tar.gz"
+	echo "(or a newer version if it is available)"
+	DIE=1
+}
+
+if test "$DIE" -eq 1; then
+	exit 1
+fi
+
+test $TEST_TYPE $FILE || {
+	echo "You must run this script in the top-level $PROJECT directory"
+	exit 1
+}
+
+if test -z "$*"; then
+	echo "I am going to run ./configure with no arguments - if you wish "
+        echo "to pass any to it, please specify them on the $0 command line."
+fi
+
+case $CC in
+*xlc | *xlc\ * | *lcc | *lcc\ *) am_opt=--include-deps;;
+esac
+
+aclocal $ACLOCAL_FLAGS
+
+# optionally feature autoheader
+(autoheader --version)  < /dev/null > /dev/null 2>&1 && autoheader
+
+automake -a $am_opt
+autoconf
+cd $ORIGDIR
+
+$srcdir/configure --enable-maintainer-mode "$@"
+
+echo 
+echo "Now type 'make' to compile $PROJECT."
diff --git a/config.guess b/config.guess
new file mode 100755
index 0000000..0ce538b
--- /dev/null
+++ b/config.guess
@@ -0,0 +1,1183 @@
+#! /bin/sh
+# Attempt to guess a canonical system name.
+#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000
+#   Free Software Foundation, Inc.
+#
+# This file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# Written by Per Bothner <bothner@cygnus.com>.
+# Please send patches to <config-patches@gnu.org>.
+#
+# This script attempts to guess a canonical system name similar to
+# config.sub.  If it succeeds, it prints the system name on stdout, and
+# exits with 0.  Otherwise, it exits with 1.
+#
+# The plan is that this can be called by configure scripts if you
+# don't specify an explicit system type (host/target name).
+#
+# Only a few systems have been added to this list; please add others
+# (but try to keep the structure clean).
+#
+
+# Use $HOST_CC if defined. $CC may point to a cross-compiler
+if test x"$CC_FOR_BUILD" = x; then
+  if test x"$HOST_CC" != x; then
+    CC_FOR_BUILD="$HOST_CC"
+  else
+    if test x"$CC" != x; then
+      CC_FOR_BUILD="$CC"
+    else
+      CC_FOR_BUILD=cc
+    fi
+  fi
+fi
+
+
+# This is needed to find uname on a Pyramid OSx when run in the BSD universe.
+# (ghazi@noc.rutgers.edu 8/24/94.)
+if (test -f /.attbin/uname) >/dev/null 2>&1 ; then
+	PATH=$PATH:/.attbin ; export PATH
+fi
+
+UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
+UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
+UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown
+UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
+
+dummy=dummy-$$
+trap 'rm -f $dummy.c $dummy.o $dummy; exit 1' 1 2 15
+
+# Note: order is significant - the case branches are not exclusive.
+
+case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
+    *:NetBSD:*:*)
+	# Netbsd (nbsd) targets should (where applicable) match one or
+	# more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*,
+	# *-*-netbsdecoff* and *-*-netbsd*.  For targets that recently
+	# switched to ELF, *-*-netbsd* would select the old
+	# object file format.  This provides both forward
+	# compatibility and a consistent mechanism for selecting the
+	# object file format.
+	# Determine the machine/vendor (is the vendor relevant).
+	case "${UNAME_MACHINE}" in
+	    amiga) machine=m68k-cbm ;;
+	    arm32) machine=arm-unknown ;;
+	    atari*) machine=m68k-atari ;;
+	    sun3*) machine=m68k-sun ;;
+	    mac68k) machine=m68k-apple ;;
+	    macppc) machine=powerpc-apple ;;
+	    hp3[0-9][05]) machine=m68k-hp ;;
+	    ibmrt|romp-ibm) machine=romp-ibm ;;
+	    *) machine=${UNAME_MACHINE}-unknown ;;
+	esac
+	# The Operating System including object format.
+	if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \
+		| grep __ELF__ >/dev/null
+	then
+	    # Once all utilities can be ECOFF (netbsdecoff) or a.out (netbsdaout).
+	    # Return netbsd for either.  FIX?
+	    os=netbsd
+	else
+	    os=netbsdelf
+	fi
+	# The OS release
+	release=`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
+	# Since CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM:
+	# contains redundant information, the shorter form:
+	# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
+	echo "${machine}-${os}${release}"
+	exit 0 ;;
+    alpha:OSF1:*:*)
+	if test $UNAME_RELEASE = "V4.0"; then
+		UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
+	fi
+	# A Vn.n version is a released version.
+	# A Tn.n version is a released field test version.
+	# A Xn.n version is an unreleased experimental baselevel.
+	# 1.2 uses "1.2" for uname -r.
+	cat <<EOF >$dummy.s
+	.data
+\$Lformat:
+	.byte 37,100,45,37,120,10,0	# "%d-%x\n"
+
+	.text
+	.globl main
+	.align 4
+	.ent main
+main:
+	.frame \$30,16,\$26,0
+	ldgp \$29,0(\$27)
+	.prologue 1
+	.long 0x47e03d80 # implver \$0
+	lda \$2,-1
+	.long 0x47e20c21 # amask \$2,\$1
+	lda \$16,\$Lformat
+	mov \$0,\$17
+	not \$1,\$18
+	jsr \$26,printf
+	ldgp \$29,0(\$26)
+	mov 0,\$16
+	jsr \$26,exit
+	.end main
+EOF
+	$CC_FOR_BUILD $dummy.s -o $dummy 2>/dev/null
+	if test "$?" = 0 ; then
+		case `./$dummy` in
+			0-0)
+				UNAME_MACHINE="alpha"
+				;;
+			1-0)
+				UNAME_MACHINE="alphaev5"
+				;;
+			1-1)
+				UNAME_MACHINE="alphaev56"
+				;;
+			1-101)
+				UNAME_MACHINE="alphapca56"
+				;;
+			2-303)
+				UNAME_MACHINE="alphaev6"
+				;;
+			2-307)
+				UNAME_MACHINE="alphaev67"
+				;;
+		esac
+	fi
+	rm -f $dummy.s $dummy
+	echo ${UNAME_MACHINE}-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[VTX]//' | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
+	exit 0 ;;
+    Alpha\ *:Windows_NT*:*)
+	# How do we know it's Interix rather than the generic POSIX subsystem?
+	# Should we change UNAME_MACHINE based on the output of uname instead
+	# of the specific Alpha model?
+	echo alpha-pc-interix
+	exit 0 ;;
+    21064:Windows_NT:50:3)
+	echo alpha-dec-winnt3.5
+	exit 0 ;;
+    Amiga*:UNIX_System_V:4.0:*)
+	echo m68k-cbm-sysv4
+	exit 0;;
+    amiga:OpenBSD:*:*)
+	echo m68k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    *:[Aa]miga[Oo][Ss]:*:*)
+	echo ${UNAME_MACHINE}-unknown-amigaos
+	exit 0 ;;
+    arc64:OpenBSD:*:*)
+	echo mips64el-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    arc:OpenBSD:*:*)
+	echo mipsel-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    hkmips:OpenBSD:*:*)
+	echo mips-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    pmax:OpenBSD:*:*)
+	echo mipsel-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    sgi:OpenBSD:*:*)
+	echo mips-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    wgrisc:OpenBSD:*:*)
+	echo mipsel-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    *:OS/390:*:*)
+	echo i370-ibm-openedition
+	exit 0 ;;
+    arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
+	echo arm-acorn-riscix${UNAME_RELEASE}
+	exit 0;;
+    SR2?01:HI-UX/MPP:*:*)
+	echo hppa1.1-hitachi-hiuxmpp
+	exit 0;;
+    Pyramid*:OSx*:*:* | MIS*:OSx*:*:* | MIS*:SMP_DC-OSx*:*:*)
+	# akee@wpdis03.wpafb.af.mil (Earle F. Ake) contributed MIS and NILE.
+	if test "`(/bin/universe) 2>/dev/null`" = att ; then
+		echo pyramid-pyramid-sysv3
+	else
+		echo pyramid-pyramid-bsd
+	fi
+	exit 0 ;;
+    NILE*:*:*:dcosx)
+	echo pyramid-pyramid-svr4
+	exit 0 ;;
+    sun4H:SunOS:5.*:*)
+	echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	exit 0 ;;
+    sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
+	echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	exit 0 ;;
+    i86pc:SunOS:5.*:*)
+	echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	exit 0 ;;
+    sun4*:SunOS:6*:*)
+	# According to config.sub, this is the proper way to canonicalize
+	# SunOS6.  Hard to guess exactly what SunOS6 will be like, but
+	# it's likely to be more like Solaris than SunOS4.
+	echo sparc-sun-solaris3`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	exit 0 ;;
+    sun4*:SunOS:*:*)
+	case "`/usr/bin/arch -k`" in
+	    Series*|S4*)
+		UNAME_RELEASE=`uname -v`
+		;;
+	esac
+	# Japanese Language versions have a version number like `4.1.3-JL'.
+	echo sparc-sun-sunos`echo ${UNAME_RELEASE}|sed -e 's/-/_/'`
+	exit 0 ;;
+    sun3*:SunOS:*:*)
+	echo m68k-sun-sunos${UNAME_RELEASE}
+	exit 0 ;;
+    sun*:*:4.2BSD:*)
+	UNAME_RELEASE=`(head -1 /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null`
+	test "x${UNAME_RELEASE}" = "x" && UNAME_RELEASE=3
+	case "`/bin/arch`" in
+	    sun3)
+		echo m68k-sun-sunos${UNAME_RELEASE}
+		;;
+	    sun4)
+		echo sparc-sun-sunos${UNAME_RELEASE}
+		;;
+	esac
+	exit 0 ;;
+    aushp:SunOS:*:*)
+	echo sparc-auspex-sunos${UNAME_RELEASE}
+	exit 0 ;;
+    atari*:OpenBSD:*:*)
+	echo m68k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    # The situation for MiNT is a little confusing.  The machine name
+    # can be virtually everything (everything which is not
+    # "atarist" or "atariste" at least should have a processor
+    # > m68000).  The system name ranges from "MiNT" over "FreeMiNT"
+    # to the lowercase version "mint" (or "freemint").  Finally
+    # the system name "TOS" denotes a system which is actually not
+    # MiNT.  But MiNT is downward compatible to TOS, so this should
+    # be no problem.
+    atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*)
+        echo m68k-atari-mint${UNAME_RELEASE}
+	exit 0 ;;
+    atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*)
+	echo m68k-atari-mint${UNAME_RELEASE}
+        exit 0 ;;
+    *falcon*:*MiNT:*:* | *falcon*:*mint:*:* | *falcon*:*TOS:*:*)
+        echo m68k-atari-mint${UNAME_RELEASE}
+	exit 0 ;;
+    milan*:*MiNT:*:* | milan*:*mint:*:* | *milan*:*TOS:*:*)
+        echo m68k-milan-mint${UNAME_RELEASE}
+        exit 0 ;;
+    hades*:*MiNT:*:* | hades*:*mint:*:* | *hades*:*TOS:*:*)
+        echo m68k-hades-mint${UNAME_RELEASE}
+        exit 0 ;;
+    *:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*)
+        echo m68k-unknown-mint${UNAME_RELEASE}
+        exit 0 ;;
+    sun3*:OpenBSD:*:*)
+	echo m68k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    mac68k:OpenBSD:*:*)
+	echo m68k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    mvme68k:OpenBSD:*:*)
+	echo m68k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    mvme88k:OpenBSD:*:*)
+	echo m88k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    powerpc:machten:*:*)
+	echo powerpc-apple-machten${UNAME_RELEASE}
+	exit 0 ;;
+    RISC*:Mach:*:*)
+	echo mips-dec-mach_bsd4.3
+	exit 0 ;;
+    RISC*:ULTRIX:*:*)
+	echo mips-dec-ultrix${UNAME_RELEASE}
+	exit 0 ;;
+    VAX*:ULTRIX*:*:*)
+	echo vax-dec-ultrix${UNAME_RELEASE}
+	exit 0 ;;
+    2020:CLIX:*:* | 2430:CLIX:*:*)
+	echo clipper-intergraph-clix${UNAME_RELEASE}
+	exit 0 ;;
+    mips:*:*:UMIPS | mips:*:*:RISCos)
+	sed 's/^	//' << EOF >$dummy.c
+#ifdef __cplusplus
+#include <stdio.h>  /* for printf() prototype */
+	int main (int argc, char *argv[]) {
+#else
+	int main (argc, argv) int argc; char *argv[]; {
+#endif
+	#if defined (host_mips) && defined (MIPSEB)
+	#if defined (SYSTYPE_SYSV)
+	  printf ("mips-mips-riscos%ssysv\n", argv[1]); exit (0);
+	#endif
+	#if defined (SYSTYPE_SVR4)
+	  printf ("mips-mips-riscos%ssvr4\n", argv[1]); exit (0);
+	#endif
+	#if defined (SYSTYPE_BSD43) || defined(SYSTYPE_BSD)
+	  printf ("mips-mips-riscos%sbsd\n", argv[1]); exit (0);
+	#endif
+	#endif
+	  exit (-1);
+	}
+EOF
+	$CC_FOR_BUILD $dummy.c -o $dummy \
+	  && ./$dummy `echo "${UNAME_RELEASE}" | sed -n 's/\([0-9]*\).*/\1/p'` \
+	  && rm $dummy.c $dummy && exit 0
+	rm -f $dummy.c $dummy
+	echo mips-mips-riscos${UNAME_RELEASE}
+	exit 0 ;;
+    Night_Hawk:Power_UNIX:*:*)
+	echo powerpc-harris-powerunix
+	exit 0 ;;
+    m88k:CX/UX:7*:*)
+	echo m88k-harris-cxux7
+	exit 0 ;;
+    m88k:*:4*:R4*)
+	echo m88k-motorola-sysv4
+	exit 0 ;;
+    m88k:*:3*:R3*)
+	echo m88k-motorola-sysv3
+	exit 0 ;;
+    AViiON:dgux:*:*)
+        # DG/UX returns AViiON for all architectures
+        UNAME_PROCESSOR=`/usr/bin/uname -p`
+	if [ $UNAME_PROCESSOR = mc88100 ] || [ $UNAME_PROCESSOR = mc88110 ]
+	then
+	    if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx ] || \
+	       [ ${TARGET_BINARY_INTERFACE}x = x ]
+	    then
+		echo m88k-dg-dgux${UNAME_RELEASE}
+	    else
+		echo m88k-dg-dguxbcs${UNAME_RELEASE}
+	    fi
+	else
+	    echo i586-dg-dgux${UNAME_RELEASE}
+	fi
+ 	exit 0 ;;
+    M88*:DolphinOS:*:*)	# DolphinOS (SVR3)
+	echo m88k-dolphin-sysv3
+	exit 0 ;;
+    M88*:*:R3*:*)
+	# Delta 88k system running SVR3
+	echo m88k-motorola-sysv3
+	exit 0 ;;
+    XD88*:*:*:*) # Tektronix XD88 system running UTekV (SVR3)
+	echo m88k-tektronix-sysv3
+	exit 0 ;;
+    Tek43[0-9][0-9]:UTek:*:*) # Tektronix 4300 system running UTek (BSD)
+	echo m68k-tektronix-bsd
+	exit 0 ;;
+    *:IRIX*:*:*)
+	echo mips-sgi-irix`echo ${UNAME_RELEASE}|sed -e 's/-/_/g'`
+	exit 0 ;;
+    ????????:AIX?:[12].1:2)   # AIX 2.2.1 or AIX 2.1.1 is RT/PC AIX.
+	echo romp-ibm-aix      # uname -m gives an 8 hex-code CPU id
+	exit 0 ;;              # Note that: echo "'`uname -s`'" gives 'AIX '
+    i?86:AIX:*:*)
+	echo i386-ibm-aix
+	exit 0 ;;
+    *:AIX:2:3)
+	if grep bos325 /usr/include/stdio.h >/dev/null 2>&1; then
+		sed 's/^		//' << EOF >$dummy.c
+		#include <sys/systemcfg.h>
+
+		main()
+			{
+			if (!__power_pc())
+				exit(1);
+			puts("powerpc-ibm-aix3.2.5");
+			exit(0);
+			}
+EOF
+		$CC_FOR_BUILD $dummy.c -o $dummy && ./$dummy && rm $dummy.c $dummy && exit 0
+		rm -f $dummy.c $dummy
+		echo rs6000-ibm-aix3.2.5
+	elif grep bos324 /usr/include/stdio.h >/dev/null 2>&1; then
+		echo rs6000-ibm-aix3.2.4
+	else
+		echo rs6000-ibm-aix3.2
+	fi
+	exit 0 ;;
+    *:AIX:*:4)
+	IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | head -1 | awk '{ print $1 }'`
+	if /usr/sbin/lsattr -EHl ${IBM_CPU_ID} | grep POWER >/dev/null 2>&1; then
+		IBM_ARCH=rs6000
+	else
+		IBM_ARCH=powerpc
+	fi
+	if [ -x /usr/bin/oslevel ] ; then
+		IBM_REV=`/usr/bin/oslevel`
+	else
+		IBM_REV=4.${UNAME_RELEASE}
+	fi
+	echo ${IBM_ARCH}-ibm-aix${IBM_REV}
+	exit 0 ;;
+    *:AIX:*:*)
+	echo rs6000-ibm-aix
+	exit 0 ;;
+    ibmrt:4.4BSD:*|romp-ibm:BSD:*)
+	echo romp-ibm-bsd4.4
+	exit 0 ;;
+    ibmrt:*BSD:*|romp-ibm:BSD:*)            # covers RT/PC BSD and
+	echo romp-ibm-bsd${UNAME_RELEASE}   # 4.3 with uname added to
+	exit 0 ;;                           # report: romp-ibm BSD 4.3
+    *:BOSX:*:*)
+	echo rs6000-bull-bosx
+	exit 0 ;;
+    DPX/2?00:B.O.S.:*:*)
+	echo m68k-bull-sysv3
+	exit 0 ;;
+    9000/[34]??:4.3bsd:1.*:*)
+	echo m68k-hp-bsd
+	exit 0 ;;
+    hp300:4.4BSD:*:* | 9000/[34]??:4.3bsd:2.*:*)
+	echo m68k-hp-bsd4.4
+	exit 0 ;;
+    9000/[34678]??:HP-UX:*:*)
+	case "${UNAME_MACHINE}" in
+	    9000/31? )            HP_ARCH=m68000 ;;
+	    9000/[34]?? )         HP_ARCH=m68k ;;
+	    9000/[678][0-9][0-9])
+              sed 's/^              //' << EOF >$dummy.c
+
+              #define _HPUX_SOURCE
+              #include <stdlib.h>
+              #include <unistd.h>
+
+              int main ()
+              {
+              #if defined(_SC_KERNEL_BITS)
+                  long bits = sysconf(_SC_KERNEL_BITS);
+              #endif
+                  long cpu  = sysconf (_SC_CPU_VERSION);
+
+                  switch (cpu)
+              	{
+              	case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
+              	case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
+              	case CPU_PA_RISC2_0:
+              #if defined(_SC_KERNEL_BITS)
+              	    switch (bits)
+              		{
+              		case 64: puts ("hppa2.0w"); break;
+              		case 32: puts ("hppa2.0n"); break;
+              		default: puts ("hppa2.0"); break;
+              		} break;
+              #else  /* !defined(_SC_KERNEL_BITS) */
+              	    puts ("hppa2.0"); break;
+              #endif
+              	default: puts ("hppa1.0"); break;
+              	}
+                  exit (0);
+              }
+EOF
+	(CCOPTS= $CC_FOR_BUILD $dummy.c -o $dummy 2>/dev/null ) && HP_ARCH=`./$dummy`
+	rm -f $dummy.c $dummy
+	esac
+	HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
+	echo ${HP_ARCH}-hp-hpux${HPUX_REV}
+	exit 0 ;;
+    3050*:HI-UX:*:*)
+	sed 's/^	//' << EOF >$dummy.c
+	#include <unistd.h>
+	int
+	main ()
+	{
+	  long cpu = sysconf (_SC_CPU_VERSION);
+	  /* The order matters, because CPU_IS_HP_MC68K erroneously returns
+	     true for CPU_PA_RISC1_0.  CPU_IS_PA_RISC returns correct
+	     results, however.  */
+	  if (CPU_IS_PA_RISC (cpu))
+	    {
+	      switch (cpu)
+		{
+		  case CPU_PA_RISC1_0: puts ("hppa1.0-hitachi-hiuxwe2"); break;
+		  case CPU_PA_RISC1_1: puts ("hppa1.1-hitachi-hiuxwe2"); break;
+		  case CPU_PA_RISC2_0: puts ("hppa2.0-hitachi-hiuxwe2"); break;
+		  default: puts ("hppa-hitachi-hiuxwe2"); break;
+		}
+	    }
+	  else if (CPU_IS_HP_MC68K (cpu))
+	    puts ("m68k-hitachi-hiuxwe2");
+	  else puts ("unknown-hitachi-hiuxwe2");
+	  exit (0);
+	}
+EOF
+	$CC_FOR_BUILD $dummy.c -o $dummy && ./$dummy && rm $dummy.c $dummy && exit 0
+	rm -f $dummy.c $dummy
+	echo unknown-hitachi-hiuxwe2
+	exit 0 ;;
+    9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:* )
+	echo hppa1.1-hp-bsd
+	exit 0 ;;
+    9000/8??:4.3bsd:*:*)
+	echo hppa1.0-hp-bsd
+	exit 0 ;;
+    *9??*:MPE/iX:*:*)
+	echo hppa1.0-hp-mpeix
+	exit 0 ;;
+    hp7??:OSF1:*:* | hp8?[79]:OSF1:*:* )
+	echo hppa1.1-hp-osf
+	exit 0 ;;
+    hp8??:OSF1:*:*)
+	echo hppa1.0-hp-osf
+	exit 0 ;;
+    i?86:OSF1:*:*)
+	if [ -x /usr/sbin/sysversion ] ; then
+	    echo ${UNAME_MACHINE}-unknown-osf1mk
+	else
+	    echo ${UNAME_MACHINE}-unknown-osf1
+	fi
+	exit 0 ;;
+    parisc*:Lites*:*:*)
+	echo hppa1.1-hp-lites
+	exit 0 ;;
+    hppa*:OpenBSD:*:*)
+	echo hppa-unknown-openbsd
+	exit 0 ;;
+    C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
+	echo c1-convex-bsd
+        exit 0 ;;
+    C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*)
+	if getsysinfo -f scalar_acc
+	then echo c32-convex-bsd
+	else echo c2-convex-bsd
+	fi
+        exit 0 ;;
+    C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*)
+	echo c34-convex-bsd
+        exit 0 ;;
+    C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*)
+	echo c38-convex-bsd
+        exit 0 ;;
+    C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*)
+	echo c4-convex-bsd
+        exit 0 ;;
+    CRAY*X-MP:*:*:*)
+	echo xmp-cray-unicos
+        exit 0 ;;
+    CRAY*Y-MP:*:*:*)
+	echo ymp-cray-unicos${UNAME_RELEASE}
+	exit 0 ;;
+    CRAY*[A-Z]90:*:*:*)
+	echo ${UNAME_MACHINE}-cray-unicos${UNAME_RELEASE} \
+	| sed -e 's/CRAY.*\([A-Z]90\)/\1/' \
+	      -e y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/
+	exit 0 ;;
+    CRAY*TS:*:*:*)
+	echo t90-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
+	exit 0 ;;
+    CRAY*T3E:*:*:*)
+	echo alpha-cray-unicosmk${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
+	exit 0 ;;
+    CRAY*SV1:*:*:*)
+	echo sv1-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
+	exit 0 ;;
+    CRAY-2:*:*:*)
+	echo cray2-cray-unicos
+        exit 0 ;;
+    F300:UNIX_System_V:*:*)
+        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
+        FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
+        echo "f300-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
+        exit 0 ;;
+    F301:UNIX_System_V:*:*)
+       echo f301-fujitsu-uxpv`echo $UNAME_RELEASE | sed 's/ .*//'`
+       exit 0 ;;
+    hp300:OpenBSD:*:*)
+	echo m68k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
+    i?86:BSD/386:*:* | i?86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
+	echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE}
+	exit 0 ;;
+    sparc*:BSD/OS:*:*)
+	echo sparc-unknown-bsdi${UNAME_RELEASE}
+	exit 0 ;;
+    *:BSD/OS:*:*)
+	echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
+	exit 0 ;;
+    *:FreeBSD:*:*)
+	echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
+	exit 0 ;;
+    *:OpenBSD:*:*)
+	echo ${UNAME_MACHINE}-unknown-openbsd`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
+	exit 0 ;;
+    i*:CYGWIN*:*)
+	echo ${UNAME_MACHINE}-pc-cygwin
+	exit 0 ;;
+    i*:MINGW*:*)
+	echo ${UNAME_MACHINE}-pc-mingw32
+	exit 0 ;;
+    i*:Windows_NT*:* | Pentium*:Windows_NT*:*)
+	# How do we know it's Interix rather than the generic POSIX subsystem?
+	# It also conflicts with pre-2.0 versions of AT&T UWIN. Should we
+	# UNAME_MACHINE based on the output of uname instead of i386?
+	echo i386-pc-interix
+	exit 0 ;;
+    i*:UWIN*:*)
+	echo ${UNAME_MACHINE}-pc-uwin
+	exit 0 ;;
+    p*:CYGWIN*:*)
+	echo powerpcle-unknown-cygwin
+	exit 0 ;;
+    prep*:SunOS:5.*:*)
+	echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+	exit 0 ;;
+    *:GNU:*:*)
+	echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'`
+	exit 0 ;;
+    *:Linux:*:*)
+
+	# The BFD linker knows what the default object file format is, so
+	# first see if it will tell us. cd to the root directory to prevent
+	# problems with other programs or directories called `ld' in the path.
+	ld_help_string=`cd /; ld --help 2>&1`
+	ld_supported_emulations=`echo $ld_help_string \
+			 | sed -ne '/supported emulations:/!d
+				    s/[ 	][ 	]*/ /g
+				    s/.*supported emulations: *//
+				    s/ .*//
+				    p'`
+        case "$ld_supported_emulations" in
+	  *ia64)
+		echo "${UNAME_MACHINE}-unknown-linux"
+		exit 0
+		;;
+	  i?86linux)
+		echo "${UNAME_MACHINE}-pc-linux-gnuaout"
+		exit 0
+		;;
+	  elf_i?86)
+		echo "${UNAME_MACHINE}-pc-linux"
+		exit 0
+		;;
+	  i?86coff)
+		echo "${UNAME_MACHINE}-pc-linux-gnucoff"
+		exit 0
+		;;
+	  sparclinux)
+		echo "${UNAME_MACHINE}-unknown-linux-gnuaout"
+		exit 0
+		;;
+	  armlinux)
+		echo "${UNAME_MACHINE}-unknown-linux-gnuaout"
+		exit 0
+		;;
+	  elf32arm*)
+		echo "${UNAME_MACHINE}-unknown-linux-gnuoldld"
+		exit 0
+		;;
+	  armelf_linux*)
+		echo "${UNAME_MACHINE}-unknown-linux-gnu"
+		exit 0
+		;;
+	  m68klinux)
+		echo "${UNAME_MACHINE}-unknown-linux-gnuaout"
+		exit 0
+		;;
+	  elf32ppc | elf32ppclinux)
+		# Determine Lib Version
+		cat >$dummy.c <<EOF
+#include <features.h>
+#if defined(__GLIBC__)
+extern char __libc_version[];
+extern char __libc_release[];
+#endif
+main(argc, argv)
+     int argc;
+     char *argv[];
+{
+#if defined(__GLIBC__)
+  printf("%s %s\n", __libc_version, __libc_release);
+#else
+  printf("unkown\n");
+#endif
+  return 0;
+}
+EOF
+		LIBC=""
+		$CC_FOR_BUILD $dummy.c -o $dummy 2>/dev/null
+		if test "$?" = 0 ; then
+			./$dummy | grep 1\.99 > /dev/null
+			if test "$?" = 0 ; then
+				LIBC="libc1"
+			fi
+		fi
+		rm -f $dummy.c $dummy
+		echo powerpc-unknown-linux-gnu${LIBC}
+		exit 0
+		;;
+	esac
+
+	if test "${UNAME_MACHINE}" = "alpha" ; then
+		cat <<EOF >$dummy.s
+			.data
+		\$Lformat:
+			.byte 37,100,45,37,120,10,0	# "%d-%x\n"
+
+			.text
+			.globl main
+			.align 4
+			.ent main
+		main:
+			.frame \$30,16,\$26,0
+			ldgp \$29,0(\$27)
+			.prologue 1
+			.long 0x47e03d80 # implver \$0
+			lda \$2,-1
+			.long 0x47e20c21 # amask \$2,\$1
+			lda \$16,\$Lformat
+			mov \$0,\$17
+			not \$1,\$18
+			jsr \$26,printf
+			ldgp \$29,0(\$26)
+			mov 0,\$16
+			jsr \$26,exit
+			.end main
+EOF
+		LIBC=""
+		$CC_FOR_BUILD $dummy.s -o $dummy 2>/dev/null
+		if test "$?" = 0 ; then
+			case `./$dummy` in
+			0-0)
+				UNAME_MACHINE="alpha"
+				;;
+			1-0)
+				UNAME_MACHINE="alphaev5"
+				;;
+			1-1)
+				UNAME_MACHINE="alphaev56"
+				;;
+			1-101)
+				UNAME_MACHINE="alphapca56"
+				;;
+			2-303)
+				UNAME_MACHINE="alphaev6"
+				;;
+			2-307)
+				UNAME_MACHINE="alphaev67"
+				;;
+			esac
+
+			objdump --private-headers $dummy | \
+			  grep ld.so.1 > /dev/null
+			if test "$?" = 0 ; then
+				LIBC="libc1"
+			fi
+		fi
+		rm -f $dummy.s $dummy
+		echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC} ; exit 0
+	elif test "${UNAME_MACHINE}" = "mips" ; then
+	  cat >$dummy.c <<EOF
+#ifdef __cplusplus
+#include <stdio.h>  /* for printf() prototype */
+	int main (int argc, char *argv[]) {
+#else
+	int main (argc, argv) int argc; char *argv[]; {
+#endif
+#ifdef __MIPSEB__
+  printf ("%s-unknown-linux-gnu\n", argv[1]);
+#endif
+#ifdef __MIPSEL__
+  printf ("%sel-unknown-linux-gnu\n", argv[1]);
+#endif
+  return 0;
+}
+EOF
+	  $CC_FOR_BUILD $dummy.c -o $dummy 2>/dev/null && ./$dummy "${UNAME_MACHINE}" && rm $dummy.c $dummy && exit 0
+	  rm -f $dummy.c $dummy
+	elif test "${UNAME_MACHINE}" = "s390"; then
+	  echo s390-ibm-linux && exit 0
+	else
+	  # Either a pre-BFD a.out linker (linux-gnuoldld)
+	  # or one that does not give us useful --help.
+	  # GCC wants to distinguish between linux-gnuoldld and linux-gnuaout.
+	  # If ld does not provide *any* "supported emulations:"
+	  # that means it is gnuoldld.
+	  echo "$ld_help_string" | grep >/dev/null 2>&1 "supported emulations:"
+	  test $? != 0 && echo "${UNAME_MACHINE}-pc-linux-gnuoldld" && exit 0
+
+	  case "${UNAME_MACHINE}" in
+	  i?86)
+	    VENDOR=pc;
+	    ;;
+	  *)
+	    VENDOR=unknown;
+	    ;;
+	  esac
+	  # Determine whether the default compiler is a.out or elf
+	  cat >$dummy.c <<EOF
+#include <features.h>
+#ifdef __cplusplus
+#include <stdio.h>  /* for printf() prototype */
+	int main (int argc, char *argv[]) {
+#else
+	int main (argc, argv) int argc; char *argv[]; {
+#endif
+#ifdef __ELF__
+# ifdef __GLIBC__
+#  if __GLIBC__ >= 2
+    printf ("%s-${VENDOR}-linux-gnu\n", argv[1]);
+#  else
+    printf ("%s-${VENDOR}-linux-gnulibc1\n", argv[1]);
+#  endif
+# else
+   printf ("%s-${VENDOR}-linux-gnulibc1\n", argv[1]);
+# endif
+#else
+  printf ("%s-${VENDOR}-linux-gnuaout\n", argv[1]);
+#endif
+  return 0;
+}
+EOF
+	  $CC_FOR_BUILD $dummy.c -o $dummy 2>/dev/null && ./$dummy "${UNAME_MACHINE}" && rm $dummy.c $dummy && exit 0
+	  rm -f $dummy.c $dummy
+	fi ;;
+# ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.  earlier versions
+# are messed up and put the nodename in both sysname and nodename.
+    i?86:DYNIX/ptx:4*:*)
+	echo i386-sequent-sysv4
+	exit 0 ;;
+    i?86:UNIX_SV:4.2MP:2.*)
+        # Unixware is an offshoot of SVR4, but it has its own version
+        # number series starting with 2...
+        # I am not positive that other SVR4 systems won't match this,
+	# I just have to hope.  -- rms.
+        # Use sysv4.2uw... so that sysv4* matches it.
+	echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION}
+	exit 0 ;;
+    i?86:*:4.*:* | i?86:SYSTEM_V:4.*:*)
+	UNAME_REL=`echo ${UNAME_RELEASE} | sed 's/\/MP$//'`
+	if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
+		echo ${UNAME_MACHINE}-univel-sysv${UNAME_REL}
+	else
+		echo ${UNAME_MACHINE}-pc-sysv${UNAME_REL}
+	fi
+	exit 0 ;;
+    i?86:*:5:7*)
+        # Fixed at (any) Pentium or better
+        UNAME_MACHINE=i586
+        if [ ${UNAME_SYSTEM} = "UnixWare" ] ; then
+	    echo ${UNAME_MACHINE}-sco-sysv${UNAME_RELEASE}uw${UNAME_VERSION}
+	else
+	    echo ${UNAME_MACHINE}-pc-sysv${UNAME_RELEASE}
+	fi
+	exit 0 ;;
+    i?86:*:3.2:*)
+	if test -f /usr/options/cb.name; then
+		UNAME_REL=`sed -n 's/.*Version //p' </usr/options/cb.name`
+		echo ${UNAME_MACHINE}-pc-isc$UNAME_REL
+	elif /bin/uname -X 2>/dev/null >/dev/null ; then
+		UNAME_REL=`(/bin/uname -X|egrep Release|sed -e 's/.*= //')`
+		(/bin/uname -X|egrep i80486 >/dev/null) && UNAME_MACHINE=i486
+		(/bin/uname -X|egrep '^Machine.*Pentium' >/dev/null) \
+			&& UNAME_MACHINE=i586
+		(/bin/uname -X|egrep '^Machine.*Pent ?II' >/dev/null) \
+			&& UNAME_MACHINE=i686
+		(/bin/uname -X|egrep '^Machine.*Pentium Pro' >/dev/null) \
+			&& UNAME_MACHINE=i686
+		echo ${UNAME_MACHINE}-pc-sco$UNAME_REL
+	else
+		echo ${UNAME_MACHINE}-pc-sysv32
+	fi
+	exit 0 ;;
+    i?86:*DOS:*:*)
+	echo ${UNAME_MACHINE}-pc-msdosdjgpp
+	exit 0 ;;
+    pc:*:*:*)
+	# Left here for compatibility:
+        # uname -m prints for DJGPP always 'pc', but it prints nothing about
+        # the processor, so we play safe by assuming i386.
+	echo i386-pc-msdosdjgpp
+        exit 0 ;;
+    Intel:Mach:3*:*)
+	echo i386-pc-mach3
+	exit 0 ;;
+    paragon:*:*:*)
+	echo i860-intel-osf1
+	exit 0 ;;
+    i860:*:4.*:*) # i860-SVR4
+	if grep Stardent /usr/include/sys/uadmin.h >/dev/null 2>&1 ; then
+	  echo i860-stardent-sysv${UNAME_RELEASE} # Stardent Vistra i860-SVR4
+	else # Add other i860-SVR4 vendors below as they are discovered.
+	  echo i860-unknown-sysv${UNAME_RELEASE}  # Unknown i860-SVR4
+	fi
+	exit 0 ;;
+    mini*:CTIX:SYS*5:*)
+	# "miniframe"
+	echo m68010-convergent-sysv
+	exit 0 ;;
+    M68*:*:R3V[567]*:*)
+	test -r /sysV68 && echo 'm68k-motorola-sysv' && exit 0 ;;
+    3[34]??:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 4850:*:4.0:3.0)
+	OS_REL=''
+	test -r /etc/.relid \
+	&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
+	/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
+	  && echo i486-ncr-sysv4.3${OS_REL} && exit 0
+	/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
+	  && echo i586-ncr-sysv4.3${OS_REL} && exit 0 ;;
+    3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
+        /bin/uname -p 2>/dev/null | grep 86 >/dev/null \
+          && echo i486-ncr-sysv4 && exit 0 ;;
+    m68*:LynxOS:2.*:*)
+	echo m68k-unknown-lynxos${UNAME_RELEASE}
+	exit 0 ;;
+    mc68030:UNIX_System_V:4.*:*)
+	echo m68k-atari-sysv4
+	exit 0 ;;
+    i?86:LynxOS:2.*:* | i?86:LynxOS:3.[01]*:*)
+	echo i386-unknown-lynxos${UNAME_RELEASE}
+	exit 0 ;;
+    TSUNAMI:LynxOS:2.*:*)
+	echo sparc-unknown-lynxos${UNAME_RELEASE}
+	exit 0 ;;
+    rs6000:LynxOS:2.*:* | PowerPC:LynxOS:2.*:*)
+	echo rs6000-unknown-lynxos${UNAME_RELEASE}
+	exit 0 ;;
+    SM[BE]S:UNIX_SV:*:*)
+	echo mips-dde-sysv${UNAME_RELEASE}
+	exit 0 ;;
+    RM*:ReliantUNIX-*:*:*)
+	echo mips-sni-sysv4
+	exit 0 ;;
+    RM*:SINIX-*:*:*)
+	echo mips-sni-sysv4
+	exit 0 ;;
+    *:SINIX-*:*:*)
+	if uname -p 2>/dev/null >/dev/null ; then
+		UNAME_MACHINE=`(uname -p) 2>/dev/null`
+		echo ${UNAME_MACHINE}-sni-sysv4
+	else
+		echo ns32k-sni-sysv
+	fi
+	exit 0 ;;
+    PENTIUM:CPunix:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort
+                           # says <Richard.M.Bartel@ccMail.Census.GOV>
+        echo i586-unisys-sysv4
+        exit 0 ;;
+    *:UNIX_System_V:4*:FTX*)
+	# From Gerald Hewes <hewes@openmarket.com>.
+	# How about differentiating between stratus architectures? -djm
+	echo hppa1.1-stratus-sysv4
+	exit 0 ;;
+    *:*:*:FTX*)
+	# From seanf@swdc.stratus.com.
+	echo i860-stratus-sysv4
+	exit 0 ;;
+    mc68*:A/UX:*:*)
+	echo m68k-apple-aux${UNAME_RELEASE}
+	exit 0 ;;
+    news*:NEWS-OS:*:6*)
+	echo mips-sony-newsos6
+	exit 0 ;;
+    R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*)
+	if [ -d /usr/nec ]; then
+	        echo mips-nec-sysv${UNAME_RELEASE}
+	else
+	        echo mips-unknown-sysv${UNAME_RELEASE}
+	fi
+        exit 0 ;;
+    BeBox:BeOS:*:*)	# BeOS running on hardware made by Be, PPC only.
+	echo powerpc-be-beos
+	exit 0 ;;
+    BeMac:BeOS:*:*)	# BeOS running on Mac or Mac clone, PPC only.
+	echo powerpc-apple-beos
+	exit 0 ;;
+    BePC:BeOS:*:*)	# BeOS running on Intel PC compatible.
+	echo i586-pc-beos
+	exit 0 ;;
+    SX-4:SUPER-UX:*:*)
+	echo sx4-nec-superux${UNAME_RELEASE}
+	exit 0 ;;
+    SX-5:SUPER-UX:*:*)
+	echo sx5-nec-superux${UNAME_RELEASE}
+	exit 0 ;;
+    Power*:Rhapsody:*:*)
+	echo powerpc-apple-rhapsody${UNAME_RELEASE}
+	exit 0 ;;
+    *:Rhapsody:*:*)
+	echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE}
+	exit 0 ;;
+    *:Darwin:*:*)
+	echo `uname -p`-apple-darwin${UNAME_RELEASE}
+	exit 0 ;;
+    *:procnto*:*:* | *:QNX:[0123456789]*:*)
+	if test "${UNAME_MACHINE}" = "x86pc"; then
+		UNAME_MACHINE=pc
+	fi
+	echo `uname -p`-${UNAME_MACHINE}-nto-qnx
+	exit 0 ;;
+    *:QNX:*:4*)
+	echo i386-pc-qnx
+	exit 0 ;;
+    NSR-W:NONSTOP_KERNEL:*:*)
+	echo nsr-tandem-nsk${UNAME_RELEASE}
+	exit 0 ;;
+    BS2000:POSIX*:*:*)
+	echo bs2000-siemens-sysv
+	exit 0 ;;
+    DS/*:UNIX_System_V:*:*)
+	echo ${UNAME_MACHINE}-${UNAME_SYSTEM}-${UNAME_RELEASE}
+	exit 0 ;;
+esac
+
+#echo '(No uname command or uname output not recognized.)' 1>&2
+#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2
+
+cat >$dummy.c <<EOF
+#ifdef _SEQUENT_
+# include <sys/types.h>
+# include <sys/utsname.h>
+#endif
+main ()
+{
+#if defined (sony)
+#if defined (MIPSEB)
+  /* BFD wants "bsd" instead of "newsos".  Perhaps BFD should be changed,
+     I don't know....  */
+  printf ("mips-sony-bsd\n"); exit (0);
+#else
+#include <sys/param.h>
+  printf ("m68k-sony-newsos%s\n",
+#ifdef NEWSOS4
+          "4"
+#else
+	  ""
+#endif
+         ); exit (0);
+#endif
+#endif
+
+#if defined (__arm) && defined (__acorn) && defined (__unix)
+  printf ("arm-acorn-riscix"); exit (0);
+#endif
+
+#if defined (hp300) && !defined (hpux)
+  printf ("m68k-hp-bsd\n"); exit (0);
+#endif
+
+#if defined (NeXT)
+#if !defined (__ARCHITECTURE__)
+#define __ARCHITECTURE__ "m68k"
+#endif
+  int version;
+  version=`(hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null`;
+  if (version < 4)
+    printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version);
+  else
+    printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version);
+  exit (0);
+#endif
+
+#if defined (MULTIMAX) || defined (n16)
+#if defined (UMAXV)
+  printf ("ns32k-encore-sysv\n"); exit (0);
+#else
+#if defined (CMU)
+  printf ("ns32k-encore-mach\n"); exit (0);
+#else
+  printf ("ns32k-encore-bsd\n"); exit (0);
+#endif
+#endif
+#endif
+
+#if defined (__386BSD__)
+  printf ("i386-pc-bsd\n"); exit (0);
+#endif
+
+#if defined (sequent)
+#if defined (i386)
+  printf ("i386-sequent-dynix\n"); exit (0);
+#endif
+#if defined (ns32000)
+  printf ("ns32k-sequent-dynix\n"); exit (0);
+#endif
+#endif
+
+#if defined (_SEQUENT_)
+    struct utsname un;
+
+    uname(&un);
+
+    if (strncmp(un.version, "V2", 2) == 0) {
+	printf ("i386-sequent-ptx2\n"); exit (0);
+    }
+    if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */
+	printf ("i386-sequent-ptx1\n"); exit (0);
+    }
+    printf ("i386-sequent-ptx\n"); exit (0);
+
+#endif
+
+#if defined (vax)
+#if !defined (ultrix)
+  printf ("vax-dec-bsd\n"); exit (0);
+#else
+  printf ("vax-dec-ultrix\n"); exit (0);
+#endif
+#endif
+
+#if defined (alliant) && defined (i860)
+  printf ("i860-alliant-bsd\n"); exit (0);
+#endif
+
+  exit (1);
+}
+EOF
+
+$CC_FOR_BUILD $dummy.c -o $dummy 2>/dev/null && ./$dummy && rm $dummy.c $dummy && exit 0
+rm -f $dummy.c $dummy
+
+# Apollos put the system type in the environment.
+
+test -d /usr/apollo && { echo ${ISP}-apollo-${SYSTYPE}; exit 0; }
+
+# Convex versions that predate uname can use getsysinfo(1)
+
+if [ -x /usr/convex/getsysinfo ]
+then
+    case `getsysinfo -f cpu_type` in
+    c1*)
+	echo c1-convex-bsd
+	exit 0 ;;
+    c2*)
+	if getsysinfo -f scalar_acc
+	then echo c32-convex-bsd
+	else echo c2-convex-bsd
+	fi
+	exit 0 ;;
+    c34*)
+	echo c34-convex-bsd
+	exit 0 ;;
+    c38*)
+	echo c38-convex-bsd
+	exit 0 ;;
+    c4*)
+	echo c4-convex-bsd
+	exit 0 ;;
+    esac
+fi
+
+#echo '(Unable to guess system type)' 1>&2
+
+exit 1
diff --git a/config.sub b/config.sub
new file mode 100755
index 0000000..c8e7785
--- /dev/null
+++ b/config.sub
@@ -0,0 +1,1268 @@
+#! /bin/sh
+# Configuration validation subroutine script, version 1.1.
+#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000
+#   Free Software Foundation, Inc.
+#
+# This file is (in principle) common to ALL GNU software.
+# The presence of a machine in this file suggests that SOME GNU software
+# can handle that machine.  It does not imply ALL GNU software can.
+#
+# This file is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
+
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# Written by Per Bothner <bothner@cygnus.com>.
+# Please send patches to <config-patches@gnu.org>.
+#
+# Configuration subroutine to validate and canonicalize a configuration type.
+# Supply the specified configuration type as an argument.
+# If it is invalid, we print an error message on stderr and exit with code 1.
+# Otherwise, we print the canonical config type on stdout and succeed.
+
+# This file is supposed to be the same for all GNU packages
+# and recognize all the CPU types, system types and aliases
+# that are meaningful with *any* GNU software.
+# Each package is responsible for reporting which valid configurations
+# it does not support.  The user should be able to distinguish
+# a failure to support a valid configuration from a meaningless
+# configuration.
+
+# The goal of this file is to map all the various variations of a given
+# machine specification into a single specification in the form:
+#	CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
+# or in some cases, the newer four-part form:
+#	CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
+# It is wrong to echo any other type of specification.
+
+if [ x$1 = x ]
+then
+	echo Configuration name missing. 1>&2
+	echo "Usage: $0 CPU-MFR-OPSYS" 1>&2
+	echo "or     $0 ALIAS" 1>&2
+	echo where ALIAS is a recognized configuration type. 1>&2
+	exit 1
+fi
+
+# First pass through any local machine types.
+case $1 in
+	*local*)
+		echo $1
+		exit 0
+		;;
+	*)
+	;;
+esac
+
+# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
+# Here we must recognize all the valid KERNEL-OS combinations.
+maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
+case $maybe_os in
+  nto-qnx* | linux-gnu*)
+    os=-$maybe_os
+    basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
+    ;;
+  *)
+    basic_machine=`echo $1 | sed 's/-[^-]*$//'`
+    if [ $basic_machine != $1 ]
+    then os=`echo $1 | sed 's/.*-/-/'`
+    else os=; fi
+    ;;
+esac
+
+### Let's recognize common machines as not being operating systems so
+### that things like config.sub decstation-3100 work.  We also
+### recognize some manufacturers as not being operating systems, so we
+### can provide default operating systems below.
+case $os in
+	-sun*os*)
+		# Prevent following clause from handling this invalid input.
+		;;
+	-dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \
+	-att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \
+	-unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \
+	-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
+	-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
+	-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
+	-apple)
+		os=
+		basic_machine=$1
+		;;
+	-sim | -cisco | -oki | -wec | -winbond)
+		os=
+		basic_machine=$1
+		;;
+	-scout)
+		;;
+	-wrs)
+		os=-vxworks
+		basic_machine=$1
+		;;
+	-hiux*)
+		os=-hiuxwe2
+		;;
+	-sco5)
+		os=-sco3.2v5
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco4)
+		os=-sco3.2v4
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco3.2.[4-9]*)
+		os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco3.2v[4-9]*)
+		# Don't forget version if it is 3.2v4 or newer.
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco*)
+		os=-sco3.2v2
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-udk*)
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-isc)
+		os=-isc2.2
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-clix*)
+		basic_machine=clipper-intergraph
+		;;
+	-isc*)
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-lynx*)
+		os=-lynxos
+		;;
+	-ptx*)
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'`
+		;;
+	-windowsnt*)
+		os=`echo $os | sed -e 's/windowsnt/winnt/'`
+		;;
+	-psos*)
+		os=-psos
+		;;
+	-mint | -mint[0-9]*)
+		basic_machine=m68k-atari
+		os=-mint
+		;;
+esac
+
+# Decode aliases for certain CPU-COMPANY combinations.
+case $basic_machine in
+	# Recognize the basic CPU types without company name.
+	# Some are omitted here because they have special meanings below.
+	tahoe | i860 | ia64 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \
+		| arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \
+		| 580 | i960 | h8300 \
+		| x86 | ppcbe | mipsbe | mipsle | shbe | shle | armbe | armle \
+		| hppa | hppa1.0 | hppa1.1 | hppa2.0 | hppa2.0w | hppa2.0n \
+		| hppa64 \
+		| alpha | alphaev[4-8] | alphaev56 | alphapca5[67] \
+		| alphaev6[78] \
+		| we32k | ns16k | clipper | i370 | sh | powerpc | powerpcle \
+		| 1750a | dsp16xx | pdp11 | mips16 | mips64 | mipsel | mips64el \
+		| mips64orion | mips64orionel | mipstx39 | mipstx39el \
+		| mips64vr4300 | mips64vr4300el | mips64vr4100 | mips64vr4100el \
+		| mips64vr5000 | miprs64vr5000el | mcore \
+		| sparc | sparclet | sparclite | sparc64 | sparcv9 | v850 | c4x \
+		| thumb | d10v | fr30 | avr)
+		basic_machine=$basic_machine-unknown
+		;;
+	m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | z8k | v70 | h8500 | w65 | pj | pjl)
+		;;
+
+	# We use `pc' rather than `unknown'
+	# because (1) that's what they normally are, and
+	# (2) the word "unknown" tends to confuse beginning users.
+	i[34567]86)
+	  basic_machine=$basic_machine-pc
+	  ;;
+	# Object if more than one company name word.
+	*-*-*)
+		echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
+		exit 1
+		;;
+	# Recognize the basic CPU types with company name.
+	# FIXME: clean up the formatting here.
+	vax-* | tahoe-* | i[34567]86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \
+	      | m88k-* | sparc-* | ns32k-* | fx80-* | arc-* | arm-* | c[123]* \
+	      | mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
+	      | power-* | none-* | 580-* | cray2-* | h8300-* | h8500-* | i960-* \
+	      | xmp-* | ymp-* \
+	      | x86-* | ppcbe-* | mipsbe-* | mipsle-* | shbe-* | shle-* | armbe-* | armle-* \
+	      | hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0-* | hppa2.0w-* \
+	      | hppa2.0n-* | hppa64-* \
+	      | alpha-* | alphaev[4-8]-* | alphaev56-* | alphapca5[67]-* \
+	      | alphaev6[78]-* \
+	      | we32k-* | cydra-* | ns16k-* | pn-* | np1-* | xps100-* \
+	      | clipper-* | orion-* \
+	      | sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \
+	      | sparc64-* | sparcv9-* | sparc86x-* | mips16-* | mips64-* | mipsel-* \
+	      | mips64el-* | mips64orion-* | mips64orionel-* \
+	      | mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* | mips64vr4300el-* \
+	      | mipstx39-* | mipstx39el-* | mcore-* \
+	      | f301-* | armv*-* | s390-* | sv1-* | t3e-* \
+	      | m88110-* | m680[01234]0-* | m683?2-* | m68360-* | z8k-* | d10v-* \
+	      | thumb-* | v850-* | d30v-* | tic30-* | c30-* | fr30-* \
+	      | bs2000-*)
+		;;
+	# Recognize the various machine names and aliases which stand
+	# for a CPU type and a company and sometimes even an OS.
+	386bsd)
+		basic_machine=i386-unknown
+		os=-bsd
+		;;
+	3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc)
+		basic_machine=m68000-att
+		;;
+	3b*)
+		basic_machine=we32k-att
+		;;
+	a29khif)
+		basic_machine=a29k-amd
+		os=-udi
+		;;
+	adobe68k)
+		basic_machine=m68010-adobe
+		os=-scout
+		;;
+	alliant | fx80)
+		basic_machine=fx80-alliant
+		;;
+	altos | altos3068)
+		basic_machine=m68k-altos
+		;;
+	am29k)
+		basic_machine=a29k-none
+		os=-bsd
+		;;
+	amdahl)
+		basic_machine=580-amdahl
+		os=-sysv
+		;;
+	amiga | amiga-*)
+		basic_machine=m68k-cbm
+		;;
+	amigaos | amigados)
+		basic_machine=m68k-cbm
+		os=-amigaos
+		;;
+	amigaunix | amix)
+		basic_machine=m68k-cbm
+		os=-sysv4
+		;;
+	apollo68)
+		basic_machine=m68k-apollo
+		os=-sysv
+		;;
+	apollo68bsd)
+		basic_machine=m68k-apollo
+		os=-bsd
+		;;
+	aux)
+		basic_machine=m68k-apple
+		os=-aux
+		;;
+	balance)
+		basic_machine=ns32k-sequent
+		os=-dynix
+		;;
+	convex-c1)
+		basic_machine=c1-convex
+		os=-bsd
+		;;
+	convex-c2)
+		basic_machine=c2-convex
+		os=-bsd
+		;;
+	convex-c32)
+		basic_machine=c32-convex
+		os=-bsd
+		;;
+	convex-c34)
+		basic_machine=c34-convex
+		os=-bsd
+		;;
+	convex-c38)
+		basic_machine=c38-convex
+		os=-bsd
+		;;
+	cray | ymp)
+		basic_machine=ymp-cray
+		os=-unicos
+		;;
+	cray2)
+		basic_machine=cray2-cray
+		os=-unicos
+		;;
+	[ctj]90-cray)
+		basic_machine=c90-cray
+		os=-unicos
+		;;
+	crds | unos)
+		basic_machine=m68k-crds
+		;;
+	da30 | da30-*)
+		basic_machine=m68k-da30
+		;;
+	decstation | decstation-3100 | pmax | pmax-* | pmin | dec3100 | decstatn)
+		basic_machine=mips-dec
+		;;
+	delta | 3300 | motorola-3300 | motorola-delta \
+	      | 3300-motorola | delta-motorola)
+		basic_machine=m68k-motorola
+		;;
+	delta88)
+		basic_machine=m88k-motorola
+		os=-sysv3
+		;;
+	dpx20 | dpx20-*)
+		basic_machine=rs6000-bull
+		os=-bosx
+		;;
+	dpx2* | dpx2*-bull)
+		basic_machine=m68k-bull
+		os=-sysv3
+		;;
+	ebmon29k)
+		basic_machine=a29k-amd
+		os=-ebmon
+		;;
+	elxsi)
+		basic_machine=elxsi-elxsi
+		os=-bsd
+		;;
+	encore | umax | mmax)
+		basic_machine=ns32k-encore
+		;;
+	es1800 | OSE68k | ose68k | ose | OSE)
+		basic_machine=m68k-ericsson
+		os=-ose
+		;;
+	fx2800)
+		basic_machine=i860-alliant
+		;;
+	genix)
+		basic_machine=ns32k-ns
+		;;
+	gmicro)
+		basic_machine=tron-gmicro
+		os=-sysv
+		;;
+	h3050r* | hiux*)
+		basic_machine=hppa1.1-hitachi
+		os=-hiuxwe2
+		;;
+	h8300hms)
+		basic_machine=h8300-hitachi
+		os=-hms
+		;;
+	h8300xray)
+		basic_machine=h8300-hitachi
+		os=-xray
+		;;
+	h8500hms)
+		basic_machine=h8500-hitachi
+		os=-hms
+		;;
+	harris)
+		basic_machine=m88k-harris
+		os=-sysv3
+		;;
+	hp300-*)
+		basic_machine=m68k-hp
+		;;
+	hp300bsd)
+		basic_machine=m68k-hp
+		os=-bsd
+		;;
+	hp300hpux)
+		basic_machine=m68k-hp
+		os=-hpux
+		;;
+	hp3k9[0-9][0-9] | hp9[0-9][0-9])
+		basic_machine=hppa1.0-hp
+		;;
+	hp9k2[0-9][0-9] | hp9k31[0-9])
+		basic_machine=m68000-hp
+		;;
+	hp9k3[2-9][0-9])
+		basic_machine=m68k-hp
+		;;
+	hp9k6[0-9][0-9] | hp6[0-9][0-9])
+		basic_machine=hppa1.0-hp
+		;;
+	hp9k7[0-79][0-9] | hp7[0-79][0-9])
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k78[0-9] | hp78[0-9])
+		# FIXME: really hppa2.0-hp
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893)
+		# FIXME: really hppa2.0-hp
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k8[0-9][13679] | hp8[0-9][13679])
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k8[0-9][0-9] | hp8[0-9][0-9])
+		basic_machine=hppa1.0-hp
+		;;
+	hppa-next)
+		os=-nextstep3
+		;;
+	hppaosf)
+		basic_machine=hppa1.1-hp
+		os=-osf
+		;;
+	hppro)
+		basic_machine=hppa1.1-hp
+		os=-proelf
+		;;
+	i370-ibm* | ibm*)
+		basic_machine=i370-ibm
+		;;
+# I'm not sure what "Sysv32" means.  Should this be sysv3.2?
+	i[34567]86v32)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-sysv32
+		;;
+	i[34567]86v4*)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-sysv4
+		;;
+	i[34567]86v)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-sysv
+		;;
+	i[34567]86sol2)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-solaris2
+		;;
+	i386mach)
+		basic_machine=i386-mach
+		os=-mach
+		;;
+	i386-vsta | vsta)
+		basic_machine=i386-unknown
+		os=-vsta
+		;;
+	i386-go32 | go32)
+		basic_machine=i386-unknown
+		os=-go32
+		;;
+	i386-mingw32 | mingw32)
+		basic_machine=i386-unknown
+		os=-mingw32
+		;;
+	iris | iris4d)
+		basic_machine=mips-sgi
+		case $os in
+		    -irix*)
+			;;
+		    *)
+			os=-irix4
+			;;
+		esac
+		;;
+	isi68 | isi)
+		basic_machine=m68k-isi
+		os=-sysv
+		;;
+	m88k-omron*)
+		basic_machine=m88k-omron
+		;;
+	magnum | m3230)
+		basic_machine=mips-mips
+		os=-sysv
+		;;
+	merlin)
+		basic_machine=ns32k-utek
+		os=-sysv
+		;;
+	miniframe)
+		basic_machine=m68000-convergent
+		;;
+	*mint | -mint[0-9]* | *MiNT | *MiNT[0-9]*)
+		basic_machine=m68k-atari
+		os=-mint
+		;;
+	mipsel*-linux*)
+		basic_machine=mipsel-unknown
+		os=-linux-gnu
+		;;
+	mips*-linux*)
+		basic_machine=mips-unknown
+		os=-linux-gnu
+		;;
+	mips3*-*)
+		basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`
+		;;
+	mips3*)
+		basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown
+		;;
+	mmix*)
+		basic_machine=mmix-knuth
+		os=-mmixware
+		;;
+	monitor)
+		basic_machine=m68k-rom68k
+		os=-coff
+		;;
+	msdos)
+		basic_machine=i386-unknown
+		os=-msdos
+		;;
+	mvs)
+		basic_machine=i370-ibm
+		os=-mvs
+		;;
+	ncr3000)
+		basic_machine=i486-ncr
+		os=-sysv4
+		;;
+	netbsd386)
+		basic_machine=i386-unknown
+		os=-netbsd
+		;;
+	netwinder)
+		basic_machine=armv4l-rebel
+		os=-linux
+		;;
+	news | news700 | news800 | news900)
+		basic_machine=m68k-sony
+		os=-newsos
+		;;
+	news1000)
+		basic_machine=m68030-sony
+		os=-newsos
+		;;
+	news-3600 | risc-news)
+		basic_machine=mips-sony
+		os=-newsos
+		;;
+	necv70)
+		basic_machine=v70-nec
+		os=-sysv
+		;;
+	next | m*-next )
+		basic_machine=m68k-next
+		case $os in
+		    -nextstep* )
+			;;
+		    -ns2*)
+		      os=-nextstep2
+			;;
+		    *)
+		      os=-nextstep3
+			;;
+		esac
+		;;
+	nh3000)
+		basic_machine=m68k-harris
+		os=-cxux
+		;;
+	nh[45]000)
+		basic_machine=m88k-harris
+		os=-cxux
+		;;
+	nindy960)
+		basic_machine=i960-intel
+		os=-nindy
+		;;
+	mon960)
+		basic_machine=i960-intel
+		os=-mon960
+		;;
+	np1)
+		basic_machine=np1-gould
+		;;
+	nsr-tandem)
+		basic_machine=nsr-tandem
+		;;
+	op50n-* | op60c-*)
+		basic_machine=hppa1.1-oki
+		os=-proelf
+		;;
+	OSE68000 | ose68000)
+		basic_machine=m68000-ericsson
+		os=-ose
+		;;
+	os68k)
+		basic_machine=m68k-none
+		os=-os68k
+		;;
+	pa-hitachi)
+		basic_machine=hppa1.1-hitachi
+		os=-hiuxwe2
+		;;
+	paragon)
+		basic_machine=i860-intel
+		os=-osf
+		;;
+	pbd)
+		basic_machine=sparc-tti
+		;;
+	pbb)
+		basic_machine=m68k-tti
+		;;
+        pc532 | pc532-*)
+		basic_machine=ns32k-pc532
+		;;
+	pentium | p5 | k5 | k6 | nexen)
+		basic_machine=i586-pc
+		;;
+	pentiumpro | p6 | 6x86)
+		basic_machine=i686-pc
+		;;
+	pentiumii | pentium2)
+		basic_machine=i786-pc
+		;;
+	pentium-* | p5-* | k5-* | k6-* | nexen-*)
+		basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	pentiumpro-* | p6-* | 6x86-*)
+		basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	pentiumii-* | pentium2-*)
+		basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	pn)
+		basic_machine=pn-gould
+		;;
+	power)	basic_machine=rs6000-ibm
+		;;
+	ppc)	basic_machine=powerpc-unknown
+	        ;;
+	ppc-*)	basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	ppcle | powerpclittle | ppc-le | powerpc-little)
+		basic_machine=powerpcle-unknown
+	        ;;
+	ppcle-* | powerpclittle-*)
+		basic_machine=powerpcle-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	ps2)
+		basic_machine=i386-ibm
+		;;
+	rom68k)
+		basic_machine=m68k-rom68k
+		os=-coff
+		;;
+	rm[46]00)
+		basic_machine=mips-siemens
+		;;
+	rtpc | rtpc-*)
+		basic_machine=romp-ibm
+		;;
+	sa29200)
+		basic_machine=a29k-amd
+		os=-udi
+		;;
+	sequent)
+		basic_machine=i386-sequent
+		;;
+	sh)
+		basic_machine=sh-hitachi
+		os=-hms
+		;;
+	sparclite-wrs)
+		basic_machine=sparclite-wrs
+		os=-vxworks
+		;;
+	sps7)
+		basic_machine=m68k-bull
+		os=-sysv2
+		;;
+	spur)
+		basic_machine=spur-unknown
+		;;
+	st2000)
+		basic_machine=m68k-tandem
+		;;
+	stratus)
+		basic_machine=i860-stratus
+		os=-sysv4
+		;;
+	sun2)
+		basic_machine=m68000-sun
+		;;
+	sun2os3)
+		basic_machine=m68000-sun
+		os=-sunos3
+		;;
+	sun2os4)
+		basic_machine=m68000-sun
+		os=-sunos4
+		;;
+	sun3os3)
+		basic_machine=m68k-sun
+		os=-sunos3
+		;;
+	sun3os4)
+		basic_machine=m68k-sun
+		os=-sunos4
+		;;
+	sun4os3)
+		basic_machine=sparc-sun
+		os=-sunos3
+		;;
+	sun4os4)
+		basic_machine=sparc-sun
+		os=-sunos4
+		;;
+	sun4sol2)
+		basic_machine=sparc-sun
+		os=-solaris2
+		;;
+	sun3 | sun3-*)
+		basic_machine=m68k-sun
+		;;
+	sun4)
+		basic_machine=sparc-sun
+		;;
+	sun386 | sun386i | roadrunner)
+		basic_machine=i386-sun
+		;;
+	sv1)
+		basic_machine=sv1-cray
+		os=-unicos
+		;;
+	symmetry)
+		basic_machine=i386-sequent
+		os=-dynix
+		;;
+	t3e)
+		basic_machine=t3e-cray
+		os=-unicos
+		;;
+	tx39)
+		basic_machine=mipstx39-unknown
+		;;
+	tx39el)
+		basic_machine=mipstx39el-unknown
+		;;
+	tower | tower-32)
+		basic_machine=m68k-ncr
+		;;
+	udi29k)
+		basic_machine=a29k-amd
+		os=-udi
+		;;
+	ultra3)
+		basic_machine=a29k-nyu
+		os=-sym1
+		;;
+	v810 | necv810)
+		basic_machine=v810-nec
+		os=-none
+		;;
+	vaxv)
+		basic_machine=vax-dec
+		os=-sysv
+		;;
+	vms)
+		basic_machine=vax-dec
+		os=-vms
+		;;
+	vpp*|vx|vx-*)
+               basic_machine=f301-fujitsu
+               ;;
+	vxworks960)
+		basic_machine=i960-wrs
+		os=-vxworks
+		;;
+	vxworks68)
+		basic_machine=m68k-wrs
+		os=-vxworks
+		;;
+	vxworks29k)
+		basic_machine=a29k-wrs
+		os=-vxworks
+		;;
+	w65*)
+		basic_machine=w65-wdc
+		os=-none
+		;;
+	w89k-*)
+		basic_machine=hppa1.1-winbond
+		os=-proelf
+		;;
+	xmp)
+		basic_machine=xmp-cray
+		os=-unicos
+		;;
+        xps | xps100)
+		basic_machine=xps100-honeywell
+		;;
+	z8k-*-coff)
+		basic_machine=z8k-unknown
+		os=-sim
+		;;
+	none)
+		basic_machine=none-none
+		os=-none
+		;;
+
+# Here we handle the default manufacturer of certain CPU types.  It is in
+# some cases the only manufacturer, in others, it is the most popular.
+	w89k)
+		basic_machine=hppa1.1-winbond
+		;;
+	op50n)
+		basic_machine=hppa1.1-oki
+		;;
+	op60c)
+		basic_machine=hppa1.1-oki
+		;;
+	mips)
+		if [ x$os = x-linux-gnu ]; then
+			basic_machine=mips-unknown
+		else
+			basic_machine=mips-mips
+		fi
+		;;
+	romp)
+		basic_machine=romp-ibm
+		;;
+	rs6000)
+		basic_machine=rs6000-ibm
+		;;
+	vax)
+		basic_machine=vax-dec
+		;;
+	pdp11)
+		basic_machine=pdp11-dec
+		;;
+	we32k)
+		basic_machine=we32k-att
+		;;
+	sparc | sparcv9)
+		basic_machine=sparc-sun
+		;;
+        cydra)
+		basic_machine=cydra-cydrome
+		;;
+	orion)
+		basic_machine=orion-highlevel
+		;;
+	orion105)
+		basic_machine=clipper-highlevel
+		;;
+	mac | mpw | mac-mpw)
+		basic_machine=m68k-apple
+		;;
+	pmac | pmac-mpw)
+		basic_machine=powerpc-apple
+		;;
+	c4x*)
+		basic_machine=c4x-none
+		os=-coff
+		;;
+	*)
+		echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
+		exit 1
+		;;
+esac
+
+# Here we canonicalize certain aliases for manufacturers.
+case $basic_machine in
+	*-digital*)
+		basic_machine=`echo $basic_machine | sed 's/digital.*/dec/'`
+		;;
+	*-commodore*)
+		basic_machine=`echo $basic_machine | sed 's/commodore.*/cbm/'`
+		;;
+	*)
+		;;
+esac
+
+# Decode manufacturer-specific aliases for certain operating systems.
+
+if [ x"$os" != x"" ]
+then
+case $os in
+        # First match some system type aliases
+        # that might get confused with valid system types.
+	# -solaris* is a basic system type, with this one exception.
+	-solaris1 | -solaris1.*)
+		os=`echo $os | sed -e 's|solaris1|sunos4|'`
+		;;
+	-solaris)
+		os=-solaris2
+		;;
+	-svr4*)
+		os=-sysv4
+		;;
+	-unixware*)
+		os=-sysv4.2uw
+		;;
+	-gnu/linux*)
+		os=`echo $os | sed -e 's|gnu/linux|linux-gnu|'`
+		;;
+	# First accept the basic system types.
+	# The portable systems comes first.
+	# Each alternative MUST END IN A *, to match a version number.
+	# -sysv* is not here because it comes later, after sysvr4.
+	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
+	      | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\
+	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
+	      | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \
+	      | -aos* \
+	      | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \
+	      | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \
+	      | -hiux* | -386bsd* | -netbsd* | -openbsd* | -freebsd* | -riscix* \
+	      | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
+	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
+	      | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
+	      | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
+	      | -mingw32* | -linux-gnu* | -uxpv* | -beos* | -mpeix* | -udk* \
+	      | -interix* | -uwin* | -rhapsody* | -darwin* | -opened* \
+	      | -openstep* | -oskit*)
+	# Remember, each alternative MUST END IN *, to match a version number.
+		;;
+	-qnx*)
+		case $basic_machine in
+		    x86-* | i[34567]86-*)
+			;;
+		    *)
+			os=-nto$os
+			;;
+		esac
+		;;
+	-nto*)
+		os=-nto-qnx
+		;;
+	-sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
+	      | -windows* | -osx | -abug | -netware* | -os9* | -beos* \
+	      | -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*)
+		;;
+	-mac*)
+		os=`echo $os | sed -e 's|mac|macos|'`
+		;;
+	-linux*)
+		os=`echo $os | sed -e 's|linux|linux-gnu|'`
+		;;
+	-sunos5*)
+		os=`echo $os | sed -e 's|sunos5|solaris2|'`
+		;;
+	-sunos6*)
+		os=`echo $os | sed -e 's|sunos6|solaris3|'`
+		;;
+	-opened*)
+		os=-openedition
+		;;
+	-wince*)
+		os=-wince
+		;;
+	-osfrose*)
+		os=-osfrose
+		;;
+	-osf*)
+		os=-osf
+		;;
+	-utek*)
+		os=-bsd
+		;;
+	-dynix*)
+		os=-bsd
+		;;
+	-acis*)
+		os=-aos
+		;;
+	-386bsd)
+		os=-bsd
+		;;
+	-ctix* | -uts*)
+		os=-sysv
+		;;
+	-ns2 )
+	        os=-nextstep2
+		;;
+	-nsk)
+		os=-nsk
+		;;
+	# Preserve the version number of sinix5.
+	-sinix5.*)
+		os=`echo $os | sed -e 's|sinix|sysv|'`
+		;;
+	-sinix*)
+		os=-sysv4
+		;;
+	-triton*)
+		os=-sysv3
+		;;
+	-oss*)
+		os=-sysv3
+		;;
+	-svr4)
+		os=-sysv4
+		;;
+	-svr3)
+		os=-sysv3
+		;;
+	-sysvr4)
+		os=-sysv4
+		;;
+	# This must come after -sysvr4.
+	-sysv*)
+		;;
+	-ose*)
+		os=-ose
+		;;
+	-es1800*)
+		os=-ose
+		;;
+	-xenix)
+		os=-xenix
+		;;
+        -*mint | -*MiNT)
+	        os=-mint
+		;;
+	-none)
+		;;
+	*)
+		# Get rid of the `-' at the beginning of $os.
+		os=`echo $os | sed 's/[^-]*-//'`
+		echo Invalid configuration \`$1\': system \`$os\' not recognized 1>&2
+		exit 1
+		;;
+esac
+else
+
+# Here we handle the default operating systems that come with various machines.
+# The value should be what the vendor currently ships out the door with their
+# machine or put another way, the most popular os provided with the machine.
+
+# Note that if you're going to try to match "-MANUFACTURER" here (say,
+# "-sun"), then you have to tell the case statement up towards the top
+# that MANUFACTURER isn't an operating system.  Otherwise, code above
+# will signal an error saying that MANUFACTURER isn't an operating
+# system, and we'll never get to this point.
+
+case $basic_machine in
+	*-acorn)
+		os=-riscix1.2
+		;;
+	arm*-rebel)
+		os=-linux
+		;;
+	arm*-semi)
+		os=-aout
+		;;
+        pdp11-*)
+		os=-none
+		;;
+	*-dec | vax-*)
+		os=-ultrix4.2
+		;;
+	m68*-apollo)
+		os=-domain
+		;;
+	i386-sun)
+		os=-sunos4.0.2
+		;;
+	m68000-sun)
+		os=-sunos3
+		# This also exists in the configure program, but was not the
+		# default.
+		# os=-sunos4
+		;;
+	m68*-cisco)
+		os=-aout
+		;;
+	mips*-cisco)
+		os=-elf
+		;;
+	mips*-*)
+		os=-elf
+		;;
+	*-tti)	# must be before sparc entry or we get the wrong os.
+		os=-sysv3
+		;;
+	sparc-* | *-sun)
+		os=-sunos4.1.1
+		;;
+	*-be)
+		os=-beos
+		;;
+	*-ibm)
+		os=-aix
+		;;
+	*-wec)
+		os=-proelf
+		;;
+	*-winbond)
+		os=-proelf
+		;;
+	*-oki)
+		os=-proelf
+		;;
+	*-hp)
+		os=-hpux
+		;;
+	*-hitachi)
+		os=-hiux
+		;;
+	i860-* | *-att | *-ncr | *-altos | *-motorola | *-convergent)
+		os=-sysv
+		;;
+	*-cbm)
+		os=-amigaos
+		;;
+	*-dg)
+		os=-dgux
+		;;
+	*-dolphin)
+		os=-sysv3
+		;;
+	m68k-ccur)
+		os=-rtu
+		;;
+	m88k-omron*)
+		os=-luna
+		;;
+	*-next )
+		os=-nextstep
+		;;
+	*-sequent)
+		os=-ptx
+		;;
+	*-crds)
+		os=-unos
+		;;
+	*-ns)
+		os=-genix
+		;;
+	i370-*)
+		os=-mvs
+		;;
+	*-next)
+		os=-nextstep3
+		;;
+        *-gould)
+		os=-sysv
+		;;
+        *-highlevel)
+		os=-bsd
+		;;
+	*-encore)
+		os=-bsd
+		;;
+        *-sgi)
+		os=-irix
+		;;
+        *-siemens)
+		os=-sysv4
+		;;
+	*-masscomp)
+		os=-rtu
+		;;
+	f301-fujitsu)
+		os=-uxpv
+		;;
+	*-rom68k)
+		os=-coff
+		;;
+	*-*bug)
+		os=-coff
+		;;
+	*-apple)
+		os=-macos
+		;;
+	*-atari*)
+		os=-mint
+		;;
+	*)
+		os=-none
+		;;
+esac
+fi
+
+# Here we handle the case where we know the os, and the CPU type, but not the
+# manufacturer.  We pick the logical manufacturer.
+vendor=unknown
+case $basic_machine in
+	*-unknown)
+		case $os in
+			-riscix*)
+				vendor=acorn
+				;;
+			-sunos*)
+				vendor=sun
+				;;
+			-aix*)
+				vendor=ibm
+				;;
+			-beos*)
+				vendor=be
+				;;
+			-hpux*)
+				vendor=hp
+				;;
+			-mpeix*)
+				vendor=hp
+				;;
+			-hiux*)
+				vendor=hitachi
+				;;
+			-unos*)
+				vendor=crds
+				;;
+			-dgux*)
+				vendor=dg
+				;;
+			-luna*)
+				vendor=omron
+				;;
+			-genix*)
+				vendor=ns
+				;;
+			-mvs* | -opened*)
+				vendor=ibm
+				;;
+			-ptx*)
+				vendor=sequent
+				;;
+			-vxsim* | -vxworks*)
+				vendor=wrs
+				;;
+			-aux*)
+				vendor=apple
+				;;
+			-hms*)
+				vendor=hitachi
+				;;
+			-mpw* | -macos*)
+				vendor=apple
+				;;
+			-*mint | -*MiNT)
+				vendor=atari
+				;;
+		esac
+		basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"`
+		;;
+esac
+
+echo $basic_machine$os
diff --git a/configure.in b/configure.in
new file mode 100644
index 0000000..c1be366
--- /dev/null
+++ b/configure.in
@@ -0,0 +1,107 @@
+dnl Process this file with autoconf to produce a configure script.
+AC_INIT(src/Main.cc)
+
+Baltisot_MAJOR_VERSION=1
+Baltisot_MINOR_VERSION=0
+Baltisot_MICRO_VERSION=0
+Baltisot_VERSION=$Baltisot_MAJOR_VERSION.$Baltisot_MINOR_VERSION.$Baltisot_MICRO_VERSION
+
+dnl set version info for Baltisot.so to package rev - $MAJOR + $MINOR : $MICRO : $MINOR
+Baltisot_VERSION_INFO=1:0:0
+
+AC_SUBST(Baltisot_MAJOR_VERSION)
+AC_SUBST(Baltisot_MINOR_VERSION)
+AC_SUBST(Baltisot_MICRO_VERSION)
+AC_SUBST(Baltisot_VERSION)
+AC_SUBST(Baltisot_VERSION_INFO)
+
+VERSION=$Baltisot_VERSION
+PACKAGE=Baltisot
+
+AM_INIT_AUTOMAKE($PACKAGE, $VERSION)
+
+AM_CONFIG_HEADER(config.h)
+
+AM_MAINTAINER_MODE
+
+dnl Checks for programs.
+AC_PROG_CXX
+AC_PROG_AWK
+AC_PROG_CC
+AC_PROG_CPP
+AC_PROG_INSTALL
+AC_PROG_LN_S
+AC_PROG_MAKE_SET
+AC_CANONICAL_HOST
+AM_PROG_LIBTOOL
+
+ALL_LINGUAS="fr de"
+AM_GNU_GETTEXT
+if test x$USE_INCLUDED_LIBINTL = xyes; then
+   LINK_SRC="$LINK_SRC intl/libgettext.h"
+   LINK_DST="$LINK_DST include/libintl.h"
+fi
+test "$MSGFMT"  = "no" && MSGFMT  ="$missing_dir/missing msgfmt"
+test "$GMSGFMT" = "no" && GMSGFMT ="$missing_dir/missing msgfmt"
+test "$XGETTEXT" = ":" && XGETTEXT="$missing_dir/missing xgettext"
+
+if test x$gt_cv_func_gettext_libintl = xyes; then
+   case "$LIBS" in
+   *-lintl*)   ;;
+   *)          LIBS="$LIBS -lintl";;
+   esac
+fi
+
+dnl Checks for header files.
+AC_HEADER_STDC
+AC_CHECK_HEADERS(libintl.h fcntl.h limits.h malloc.h strings.h unistd.h)
+
+dnl Checks for typedefs, structures, and compiler characteristics.
+AC_C_CONST
+AC_C_BIGENDIAN
+AC_C_INLINE
+AC_TYPE_SIZE_T
+
+dnl Checks for library functions.
+AC_FUNC_ALLOCA
+AC_FUNC_MMAP
+AC_CHECK_FUNCS(getcwd getwd putenv strdup)
+AC_SEARCH_LIBS(socket,socket)
+AC_SEARCH_LIBS(gethostbyname,nsl)
+
+AC_PATH_PROG(gmakepath, gmake)
+AC_PATH_PROG(unamepath, uname)
+if test "x$unamepath" = x; then
+  system="unknown"
+else
+  AC_MSG_CHECKING(system type)
+  system=`$unamepath -s`
+  AC_MSG_RESULT($system)
+fi
+
+AC_OUTPUT([
+  Makefile
+  include/Makefile
+  lib/Makefile
+  doc/Makefile
+  src/Makefile
+  po/Makefile.in
+  intl/Makefile
+])
+
+echo
+echo \-\-\= $PACKAGE $VERSION \=\-\-
+echo
+
+echo Build System .................... : $system
+echo Build Host ...................... : $host
+echo Install Prefix .................. : $prefix
+echo
+
+if test _"$gmakepath" = _; then
+  echo configure complete, now type \'make\'
+else
+  echo configure complete, now type \'gmake\'
+fi
+
+echo
diff --git a/doc/Makefile.am b/doc/Makefile.am
new file mode 100644
index 0000000..e32c61b
--- /dev/null
+++ b/doc/Makefile.am
@@ -0,0 +1 @@
+EXTRA_DIST = rfc1866.txt rfc2616.txt rfc2812.txt
diff --git a/doc/rfc1866.txt b/doc/rfc1866.txt
new file mode 100644
index 0000000..4367018
--- /dev/null
+++ b/doc/rfc1866.txt
@@ -0,0 +1,4315 @@
+
+
+
+
+
+
+Network Working Group                                    T. Berners-Lee
+Request for Comments: 1866                                      MIT/W3C
+Category: Standards Track                                   D. Connolly
+                                                          November 1995
+
+
+                    Hypertext Markup Language - 2.0
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Hypertext Markup Language (HTML) is a simple markup language used
+   to create hypertext documents that are platform independent. HTML
+   documents are SGML documents with generic semantics that are
+   appropriate for representing information from a wide range of
+   domains. HTML markup can represent hypertext news, mail,
+   documentation, and hypermedia; menus of options; database query
+   results; simple structured documents with in-lined graphics; and
+   hypertext views of existing bodies of information.
+
+   HTML has been in use by the World Wide Web (WWW) global information
+   initiative since 1990. This specification roughly corresponds to the
+   capabilities of HTML in common use prior to June 1994. HTML is an
+   application of ISO Standard 8879:1986 Information Processing Text and
+   Office Systems; Standard Generalized Markup Language (SGML).
+
+   The "text/html" Internet Media Type (RFC 1590) and MIME Content Type
+   (RFC 1521) is defined by this specification.
+
+Table of Contents
+
+    1.     Introduction ........................................... 2
+    1.1    Scope .................................................. 3
+    1.2    Conformance ............................................ 3
+    2.     Terms .................................................. 6
+    3.     HTML as an Application of SGML .........................10
+    3.1    SGML Documents .........................................10
+    3.2    HTML Lexical Syntax ................................... 12
+    3.3    HTML Public Text Identifiers .......................... 17
+    3.4    Example HTML Document ................................. 17
+    4.     HTML as an Internet Media Type ........................ 18
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 1]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    4.1    text/html media type .................................. 18
+    4.2    HTML Document Representation .......................... 19
+    5.     Document Structure .................................... 20
+    5.1    Document Element: HTML ................................ 21
+    5.2    Head: HEAD ............................................ 21
+    5.3    Body: BODY ............................................ 24
+    5.4    Headings: H1 ... H6 ................................... 24
+    5.5    Block Structuring Elements ............................ 25
+    5.6    List Elements ......................................... 28
+    5.7    Phrase Markup ......................................... 30
+    5.8    Line Break: BR ........................................ 34
+    5.9    Horizontal Rule: HR ................................... 34
+    5.10   Image: IMG ............................................ 34
+    6.     Characters, Words, and Paragraphs ..................... 35
+    6.1    The HTML Document Character Set ....................... 36
+    7.     Hyperlinks ............................................ 36
+    7.1    Accessing Resources ................................... 37
+    7.2    Activation of Hyperlinks .............................. 38
+    7.3    Simultaneous Presentation of Image Resources .......... 38
+    7.4    Fragment Identifiers .................................. 38
+    7.5    Queries and Indexes ................................... 39
+    7.6    Image Maps ............................................ 39
+    8.     Forms ................................................. 40
+    8.1    Form Elements ......................................... 40
+    8.2    Form Submission ....................................... 45
+    9.     HTML Public Text ...................................... 49
+    9.1    HTML DTD .............................................. 49
+    9.2    Strict HTML DTD ....................................... 61
+    9.3    Level 1 HTML DTD ...................................... 62
+    9.4    Strict Level 1 HTML DTD ............................... 63
+    9.5    SGML Declaration for HTML ............................. 64
+    9.6    Sample SGML Open Entity Catalog for HTML .............. 65
+    9.7    Character Entity Sets ................................. 66
+    10.    Security Considerations ............................... 69
+    11.    References ............................................ 69
+    12.    Acknowledgments ....................................... 71
+    12.1   Authors' Addresses .................................... 71
+    13.    The HTML Coded Character Set .......................... 72
+    14.    Proposed Entities ..................................... 75
+
+1. Introduction
+
+   The HyperText Markup Language (HTML) is a simple data format used to
+   create hypertext documents that are portable from one platform to
+   another. HTML documents are SGML documents with generic semantics
+   that are appropriate for representing information from a wide range
+   of domains.
+
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 2]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   As HTML is an application of SGML, this specification assumes a
+   working knowledge of [SGML].
+
+1.1. Scope
+
+   HTML has been in use by the World-Wide Web (WWW) global information
+   initiative since 1990. Previously, informal documentation on HTML has
+   been available from a number of sources on the Internet. This
+   specification brings together, clarifies, and formalizes a set of
+   features that roughly corresponds to the capabilities of HTML in
+   common use prior to June 1994. A number of new features to HTML are
+   being proposed and experimented in the Internet community.
+
+   This document thus defines a HTML 2.0 (to distinguish it from the
+   previous informal specifications). Future (generally upwardly
+   compatible) versions of HTML with new features will be released with
+   higher version numbers.
+
+   HTML is an application of ISO Standard 8879:1986, "Information
+   Processing Text and Office Systems; Standard Generalized Markup
+   Language" (SGML). The HTML Document Type Definition (DTD) is a formal
+   definition of the HTML syntax in terms of SGML.
+
+   This specification also defines HTML as an Internet Media
+   Type[IMEDIA] and MIME Content Type[MIME] called `text/html'. As such,
+   it defines the semantics of the HTML syntax and how that syntax
+   should be interpreted by user agents.
+
+1.2. Conformance
+
+   This specification governs the syntax of HTML documents and aspects
+   of the behavior of HTML user agents.
+
+1.2.1. Documents
+
+   A document is a conforming HTML document if:
+
+        * It is a conforming SGML document, and it conforms to the
+        HTML DTD (see 9.1, "HTML DTD").
+
+            NOTE - There are a number of syntactic idioms that
+            are not supported or are supported inconsistently in
+            some historical user agent implementations. These
+            idioms are identified in notes like this throughout
+            this specification.
+
+        * It conforms to the application conventions in this
+        specification. For example, the value of the HREF attribute
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 3]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        of the <A> element must conform to the URI syntax.
+
+        * Its document character set includes [ISO-8859-1] and
+        agrees with [ISO-10646]; that is, each code position listed
+        in 13, "The HTML Coded Character Set" is included, and each
+        code position in the document character set is mapped to the
+        same character as [ISO-10646] designates for that code
+        position.
+
+            NOTE - The document character set is somewhat
+            independent of the character encoding scheme used to
+            represent a document. For example, the `ISO-2022-JP'
+            character encoding scheme can be used for HTML
+            documents, since its repertoire is a subset of the
+            [ISO-10646] repertoire. The critical distinction is
+            that numeric character references agree with
+            [ISO-10646] regardless of how the document is
+            encoded.
+
+1.2.2. Feature Test Entities
+
+   The HTML DTD defines a standard HTML document type and several
+   variations, by way of feature test entities. Feature test entities
+   are declarations in the HTML DTD that control the inclusion or
+   exclusion of portions of the DTD.
+
+    HTML.Recommended
+            Certain features of the language are necessary for
+            compatibility with widespread usage, but they may
+            compromise the structural integrity of a document. This
+            feature test entity selects a more prescriptive document
+            type definition that eliminates those features. It is
+            set to `IGNORE' by default.
+
+            For example, in order to preserve the structure of a
+            document, an editing user agent may translate HTML
+            documents to the recommended subset, or it may require
+            that the documents be in the recommended subset for
+            import.
+
+    HTML.Deprecated
+            Certain features of the language are necessary for
+            compatibility with earlier versions of the
+            specification, but they tend to be used and implemented
+            inconsistently, and their use is deprecated. This
+            feature test entity enables a document type definition
+            that allows these features. It is set to `INCLUDE' by
+            default.
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 4]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+            Documents generated by translation software or editing
+            software should not contain deprecated idioms.
+
+1.2.3. User Agents
+
+   An HTML user agent conforms to this specification if:
+
+        * It parses the characters of an HTML document into data
+        characters and markup according to [SGML].
+
+            NOTE - In the interest of robustness and
+            extensibility, there are a number of widely deployed
+            conventions for handling non-conforming documents.
+            See 4.2.1, "Undeclared Markup Error Handling" for
+            details.
+
+        * It supports the `ISO-8859-1' character encoding scheme and
+        processes each character in the ISO Latin Alphabet No. 1 as
+        specified in 6.1, "The HTML Document Character Set".
+
+            NOTE - To support non-western writing systems, HTML
+            user agents are encouraged to support
+            `ISO-10646-UCS-2' or similar character encoding
+            schemes and as much of the character repertoire of
+            [ISO-10646] as is practical.
+
+        * It behaves identically for documents whose parsed token
+        sequences are identical.
+
+        For example, comments and the whitespace in tags disappear
+        during tokenization, and hence they do not influence the
+        behavior of conforming user agents.
+
+        * It allows the user to traverse (or at least attempt to
+        traverse, resources permitting) all hyperlinks from <A>
+        elements in an HTML document.
+
+   An HTML user agent is a level 2 user agent if, additionally:
+
+        * It allows the user to express all form field values
+        specified in an HTML document and to (attempt to) submit the
+        values as requests to information services.
+
+
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 5]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+2. Terms
+
+    absolute URI
+            a URI in absolute form; for example, as per [URL]
+
+    anchor
+            one of two ends of a hyperlink; typically, a phrase
+            marked as an <A> element.
+
+    base URI
+            an absolute URI used in combination with a relative URI
+            to determine another absolute URI.
+
+    character
+            An atom of information, for example a letter or a digit.
+            Graphic characters have associated glyphs, whereas
+            control characters have associated processing semantics.
+
+    character encoding
+    scheme
+            A function whose domain is the set of sequences of
+            octets, and whose range is the set of sequences of
+            characters from a character repertoire; that is, a
+            sequence of octets and a character encoding scheme
+            determines a sequence of characters.
+
+    character repertoire
+            A finite set of characters; e.g. the range of a coded
+            character set.
+
+    code position
+            An integer. A coded character set and a code position
+            from its domain determine a character.
+
+    coded character set
+            A function whose domain is a subset of the integers and
+            whose range is a character repertoire. That is, for some
+            set of integers (usually of the form {0, 1, 2, ..., N}
+            ), a coded character set and an integer in that set
+            determine a character. Conversely, a character and a
+            coded character set determine the character's code
+            position (or, in rare cases, a few code positions).
+
+    conforming HTML user
+    agent
+            A user agent that conforms to this specification in its
+            processing of the Internet Media Type `text/html'.
+
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 6]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    data character
+            Characters other than markup, which make up the content
+            of elements.
+
+    document character set
+            a coded character set whose range includes all
+            characters used in a document. Every SGML document has
+            exactly one document character set. Numeric character
+            references are resolved via the document character set.
+
+    DTD
+            document type definition. Rules that apply SGML to the
+            markup of documents of a particular type, including a
+            set of element and entity declarations. [SGML]
+
+    element
+            A component of the hierarchical structure defined by a
+            document type definition; it is identified in a document
+            instance by descriptive markup, usually a start-tag and
+            end-tag. [SGML]
+
+    end-tag
+            Descriptive markup that identifies the end of an
+            element. [SGML]
+
+    entity
+            data with an associated notation or interpretation; for
+            example, a sequence of octets associated with an
+            Internet Media Type. [SGML]
+
+    fragment identifier
+            the portion of an HREF attribute value following the `#'
+            character which modifies the presentation of the
+            destination of a hyperlink.
+
+    form data set
+            a sequence of name/value pairs; the names are given by
+            an HTML document and the values are given by a user.
+
+    HTML document
+            An SGML document conforming to this document type
+            definition.
+
+    hyperlink
+            a relationship between two anchors, called the head and
+            the tail. The link goes from the tail to the head. The
+            head and tail are also known as destination and source,
+            respectively.
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 7]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    markup
+            Syntactically delimited characters added to the data of
+            a document to represent its structure. There are four
+            different kinds of markup: descriptive markup (tags),
+            references, markup declarations, and processing
+            instructions. [SGML]
+
+    may
+            A document or user interface is conforming whether this
+            statement applies or not.
+
+    media type
+            an Internet Media Type, as per [IMEDIA].
+
+    message entity
+            a head and body. The head is a collection of name/value
+            fields, and the body is a sequence of octets. The head
+            defines the content type and content transfer encoding
+            of the body. [MIME]
+
+    minimally conforming
+    HTML user agent
+            A user agent that conforms to this specification except
+            for form processing. It may only process level 1 HTML
+            documents.
+
+    must
+            Documents or user agents in conflict with this statement
+            are not conforming.
+
+    numeric character
+    reference
+            markup that refers to a character by its code position
+            in the document character set.
+
+    SGML document
+            A sequence of characters organized physically as a set
+            of entities and logically into a hierarchy of elements.
+            An SGML document consists of data characters and markup;
+            the markup describes the structure of the information
+            and an instance of that structure. [SGML]
+
+    shall
+            If a document or user agent conflicts with this
+            statement, it does not conform to this specification.
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 8]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    should
+            If a document or user agent conflicts with this
+            statement, undesirable results may occur in practice
+            even though it conforms to this specification.
+
+    start-tag
+            Descriptive markup that identifies the start of an
+            element and specifies its generic identifier and
+            attributes. [SGML]
+
+    syntax-reference
+    character set
+            A coded character set whose range includes all
+            characters used for markup; e.g. name characters and
+            delimiter characters.
+
+    tag
+            Markup that delimits an element. A tag includes a name
+            which refers to an element declaration in the DTD, and
+            may include attributes. [SGML]
+
+    text entity
+            A finite sequence of characters. A text entity typically
+            takes the form of a sequence of octets with some
+            associated character encoding scheme, transmitted over
+            the network or stored in a file. [SGML]
+
+    typical
+            Typical processing is described for many elements. This
+            is not a mandatory part of the specification but is
+            given as guidance for designers and to help explain the
+            uses for which the elements were intended.
+
+    URI
+            A Uniform Resource Identifier is a formatted string that
+            serves as an identifier for a resource, typically on the
+            Internet. URIs are used in HTML to identify the anchors
+            of hyperlinks. URIs in common practice include Uniform
+            Resource Locators (URLs)[URL] and Relative URLs
+            [RELURL].
+
+    user agent
+            A component of a distributed system that presents an
+            interface and processes requests on behalf of a user;
+            for example, a www browser or a mail user agent.
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                     [Page 9]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    WWW
+            The World-Wide Web is a hypertext-based, distributed
+            information system created by researchers at CERN in
+            Switzerland. <URL:http://www.w3.org/>
+
+3. HTML as an Application of SGML
+
+   HTML is an application of ISO 8879:1986 -- Standard Generalized
+   Markup Language (SGML). SGML is a system for defining structured
+   document types and markup languages to represent instances of those
+   document types[SGML]. The public text -- DTD and SGML declaration --
+   of the HTML document type definition are provided in 9, "HTML Public
+   Text".
+
+   The term "HTML" refers to both the document type defined here and the
+   markup language for representing instances of this document type.
+
+3.1. SGML Documents
+
+   An HTML document is an SGML document; that is, a sequence of
+   characters organized physically into a set of entities, and logically
+   as a hierarchy of elements.
+
+   In the SGML specification, the first production of the SGML syntax
+   grammar separates an SGML document into three parts: an SGML
+   declaration, a prologue, and an instance. For the purposes of this
+   specification, the prologue is a DTD. This DTD describes another
+   grammar: the start symbol is given in the doctype declaration, the
+   terminals are data characters and tags, and the productions are
+   determined by the element declarations. The instance must conform to
+   the DTD, that is, it must be in the language defined by this grammar.
+
+   The SGML declaration determines the lexicon of the grammar. It
+   specifies the document character set, which determines a character
+   repertoire that contains all characters that occur in all text
+   entities in the document, and the code positions associated with
+   those characters.
+
+   The SGML declaration also specifies the syntax-reference character
+   set of the document, and a few other parameters that bind the
+   abstract syntax of SGML to a concrete syntax. This concrete syntax
+   determines how the sequence of characters of the document is mapped
+   to a sequence of terminals in the grammar of the prologue.
+
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 10]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   For example, consider the following document:
+
+    <!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
+    <title>Parsing Example</title>
+    <p>Some text. <em>&#42;wow&#42;</em></p>
+
+   An HTML user agent should use the SGML declaration that is given in
+   9.5, "SGML Declaration for HTML". According to its document character
+   set, `&#42;' refers to an asterisk character, `*'.
+
+   The instance above is regarded as the following sequence of
+   terminals:
+
+        1. start-tag: TITLE
+
+        2. data characters: "Parsing Example"
+
+        3. end-tag: TITLE
+
+        4. start-tag: P
+
+        5. data characters "Some text."
+
+        6. start-tag: EM
+
+        7. data characters: "*wow*"
+
+        8. end-tag: EM
+
+        9. end-tag: P
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 11]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   The start symbol of the DTD grammar is HTML, and the productions are
+   given in the public text identified by `-//IETF//DTD HTML 2.0//EN'
+   (9.1, "HTML DTD"). The terminals above parse as:
+
+       HTML
+        |
+        \-HEAD
+        |  |
+        |  \-TITLE
+        |      |
+        |      \-<TITLE>
+        |      |
+        |      \-"Parsing Example"
+        |      |
+        |      \-</TITLE>
+        |
+        \-BODY
+          |
+          \-P
+            |
+            \-<P>
+            |
+            \-"Some text. "
+            |
+            \-EM
+            |  |
+            |  \-<EM>
+            |  |
+            |  \-"*wow*"
+            |  |
+            |  \-</EM>
+            |
+            \-</P>
+
+   Some of the elements are delimited explicitly by tags, while the
+   boundaries of others are inferred. The <HTML> element contains a
+   <HEAD> element and a <BODY> element. The <HEAD> contains <TITLE>,
+   which is explicitly delimited by start- and end-tags.
+
+3.2. HTML Lexical Syntax
+
+   SGML specifies an abstract syntax and a reference concrete syntax.
+   Aside from certain quantities and capacities (e.g. the limit on the
+   length of a name), all HTML documents use the reference concrete
+   syntax. In particular, all markup characters are in the repertoire of
+   [ISO-646]. Data characters are drawn from the document character set
+   (see 6, "Characters, Words, and Paragraphs").
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 12]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   A complete discussion of SGML parsing, e.g. the mapping of a sequence
+   of characters to a sequence of tags and data, is left to the SGML
+   standard[SGML]. This section is only a summary.
+
+3.2.1. Data Characters
+
+   Any sequence of characters that do not constitute markup (see 9.6
+   "Delimiter Recognition" of [SGML]) are mapped directly to strings of
+   data characters. Some markup also maps to data character strings.
+   Numeric character references map to single-character strings, via the
+   document character set. Each reference to one of the general entities
+   defined in the HTML DTD maps to a single-character string.
+
+   For example,
+
+    abc&lt;def    => "abc","<","def"
+    abc&#60;def   => "abc","<","def"
+
+   The terminating semicolon on entity or numeric character references
+   is only necessary when the character following the reference would
+   otherwise be recognized as part of the name (see 9.4.5 "Reference
+   End" in [SGML]).
+
+    abc &lt def     => "abc ","<"," def"
+    abc &#60 def    => "abc ","<"," def"
+
+   An ampersand is only recognized as markup when it is followed by a
+   letter or a `#' and a digit:
+
+    abc & lt def    => "abc & lt def"
+    abc &# 60 def    => "abc &# 60 def"
+
+   A useful technique for translating plain text to HTML is to replace
+   each '<', '&', and '>' by an entity reference or numeric character
+   reference as follows:
+
+                     ENTITY      NUMERIC
+           CHARACTER REFERENCE   CHAR REF     CHARACTER DESCRIPTION
+           --------- ----------  -----------  ---------------------
+             &       &amp;       &#38;        Ampersand
+             <       &lt;        &#60;        Less than
+             >       &gt;        &#62;        Greater than
+
+        NOTE - There are SGML mechanisms, CDATA and RCDATA
+        declared content, that allow most `<', `>', and `&'
+        characters to be entered without the use of entity
+        references. Because these mechanisms tend to be used and
+        implemented inconsistently, and because they conflict
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 13]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        with techniques for reducing HTML to 7 bit ASCII for
+        transport, they are deprecated in this version of HTML.
+        See 5.5.2.1, "Example and Listing: XMP, LISTING".
+
+3.2.2. Tags
+
+   Tags delimit elements such as headings, paragraphs, lists, character
+   highlighting, and links. Most HTML elements are identified in a
+   document as a start-tag, which gives the element name and attributes,
+   followed by the content, followed by the end tag. Start-tags are
+   delimited by `<' and `>'; end tags are delimited by `</' and `>'. An
+   example is:
+
+   <H1>This is a Heading</H1>
+
+   Some elements only have a start-tag without an end-tag. For example,
+   to create a line break, use the `<BR>' tag.  Additionally, the end
+   tags of some other elements, such as Paragraph (`</P>'), List Item
+   (`</LI>'), Definition Term (`</DT>'), and Definition Description
+   (`</DD>') elements, may be omitted.
+
+   The content of an element is a sequence of data character strings and
+   nested elements. Some elements, such as anchors, cannot be nested.
+   Anchors and character highlighting may be put inside other
+   constructs. See the HTML DTD, 9.1, "HTML DTD" for full details.
+
+      NOTE - The SGML declaration for HTML specifies SHORTTAG YES, which
+      means that there are other valid syntaxes for tags, such as NET
+      tags, `<EM/.../'; empty start tags, `<>'; and empty end-tags,
+      `</>'. Until support for these idioms is widely deployed, their
+      use is strongly discouraged.
+
+3.2.3. Names
+
+   A name consists of a letter followed by letters, digits, periods, or
+   hyphens. The length of a name is limited to 72 characters by the
+   `NAMELEN' parameter in the SGML declaration for HTML, 9.5, "SGML
+   Declaration for HTML". Element and attribute names are not case
+   sensitive, but entity names are.  For example, `<BLOCKQUOTE>',
+   `<BlockQuote>', and `<blockquote>' are equivalent, whereas `&amp;' is
+   different from `&AMP;'.
+
+   In a start-tag, the element name must immediately follow the tag open
+   delimiter `<'.
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 14]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+3.2.4. Attributes
+
+   In a start-tag, white space and attributes are allowed between the
+   element name and the closing delimiter. An attribute specification
+   typically consists of an attribute name, an equal sign, and a value,
+   though some attribute specifications may be just a name token. White
+   space is allowed around the equal sign.
+
+   The value of the attribute may be either:
+
+        * A string literal, delimited by single quotes or double
+        quotes and not containing any occurrences of the delimiting
+        character.
+
+            NOTE - Some historical implementations consider any
+            occurrence of the `>' character to signal the end of
+            a tag. For compatibility with such implementations,
+            when `>' appears in an attribute value, it should be
+            represented with a numeric character reference. For
+            example, `<IMG SRC="eq1.jpg" alt="a>b">' should be
+            written `<IMG SRC="eq1.jpg" alt="a&#62;b">' or `<IMG
+            SRC="eq1.jpg" alt="a&gt;b">'.
+
+        * A name token (a sequence of letters, digits, periods, or
+        hyphens). Name tokens are not case sensitive.
+
+            NOTE - Some historical implementations allow any
+            character except space or `>' in a name token.
+
+   In this example, <img> is the element name, src is the attribute
+   name, and `http://host/dir/file.gif' is the attribute value:
+
+   <img src='http://host/dir/file.gif'>
+
+   A useful technique for computing an attribute value literal for a
+   given string is to replace each quote and white space character by an
+   entity reference or numeric character reference as follows:
+
+                     ENTITY      NUMERIC
+           CHARACTER REFERENCE   CHAR REF     CHARACTER DESCRIPTION
+           --------- ----------  -----------  ---------------------
+             HT                  &#9;         Tab
+             LF                  &#10;        Line Feed
+             CR                  &#13;        Carriage Return
+             SP                  &#32;        Space
+             "       &quot;      &#34;        Quotation mark
+             &       &amp;       &#38;        Ampersand
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 15]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   For example:
+
+   <IMG SRC="image.jpg" alt="First &quot;real&quot; example">
+
+   The `NAMELEN' parameter in the SGML declaration (9.5, "SGML
+   Declaration for HTML") limits the length of an attribute value to
+   1024 characters.
+
+   Attributes such as ISMAP and COMPACT may be written using a minimized
+   syntax (see 7.9.1.2 "Omitted Attribute Name" in [SGML]). The markup:
+
+   <UL COMPACT="compact">
+
+   can be written using a minimized syntax:
+
+   <UL COMPACT>
+
+   NOTE - Some historical implementations only understand the minimized
+   syntax.
+
+3.2.5. Comments
+
+   To include comments in an HTML document, use a comment declaration. A
+   comment declaration consists of `<!' followed by zero or more
+   comments followed by `>'. Each comment starts with `--' and includes
+   all text up to and including the next occurrence of `--'. In a
+   comment declaration, white space is allowed after each comment, but
+   not before the first comment.  The entire comment declaration is
+   ignored.
+
+      NOTE - Some historical HTML implementations incorrectly consider
+      any `>' character to be the termination of a comment.
+
+   For example:
+
+    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+    <HEAD>
+    <TITLE>HTML Comment Example</TITLE>
+    <!-- Id: html-sgml.sgm,v 1.5 1995/05/26 21:29:50 connolly Exp  -->
+    <!-- another -- -- comment -->
+    <!>
+    </HEAD>
+    <BODY>
+    <p> <!- not a comment, just regular old data characters ->
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 16]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+3.3. HTML Public Text Identifiers
+
+   To identify information as an HTML document conforming to this
+   specification, each document must start with one of the following
+   document type declarations.
+
+   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+
+   This document type declaration refers to the HTML DTD in 9.1, "HTML
+   DTD".
+
+      NOTE - If the body of a `text/html' message entity does not begin
+      with a document type declaration, an HTML user agent should infer
+      the above document type declaration.
+
+   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN">
+
+   This document type declaration also refers to the HTML DTD which
+   appears in 9.1, "HTML DTD".
+
+   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN">
+
+   This document type declaration refers to the level 1 HTML DTD in 9.3,
+   "Level 1 HTML DTD". Form elements must not occur in level 1
+   documents.
+
+   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN">
+   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 1//EN">
+
+   These two document type declarations refer to the HTML DTD in 9.2,
+   "Strict HTML DTD" and 9.4, "Strict Level 1 HTML DTD". They refer to
+   the more structurally rigid definition of HTML.
+
+   HTML user agents may support other document types. In particular,
+   they may support other formal public identifiers, or other document
+   types altogether. They may support an internal declaration subset
+   with supplemental entity, element, and other markup declarations.
+
+3.4. Example HTML Document
+
+    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+    <HTML>
+    <!-- Here's a good place to put a comment. -->
+    <HEAD>
+    <TITLE>Structural Example</TITLE>
+    </HEAD><BODY>
+    <H1>First Header</H1>
+    <P>This is a paragraph in the example HTML file. Keep in mind
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 17]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    that the title does not appear in the document text, but that
+    the header (defined by H1) does.</P>
+    <OL>
+    <LI>First item in an ordered list.
+    <LI>Second item in an ordered list.
+      <UL COMPACT>
+      <LI> Note that lists can be nested;
+      <LI> Whitespace may be used to assist in reading the
+           HTML source.
+      </UL>
+    <LI>Third item in an ordered list.
+    </OL>
+    <P>This is an additional paragraph. Technically, end tags are
+    not required for paragraphs, although they are allowed. You can
+    include character highlighting in a paragraph. <EM>This sentence
+    of the paragraph is emphasized.</EM> Note that the &lt;/P&gt;
+    end tag has been omitted.
+    <P>
+    <IMG SRC ="triangle.xbm" alt="Warning: ">
+    Be sure to read these <b>bold instructions</b>.
+    </BODY></HTML>
+
+4. HTML as an Internet Media Type
+
+   An HTML user agent allows users to interact with resources which have
+   HTML representations. At a minimum, it must allow users to examine
+   and navigate the content of HTML level 1 documents. HTML user agents
+   should be able to preserve all formatting distinctions represented in
+   an HTML document, and be able to simultaneously present resources
+   referred to by IMG elements (they may ignore some formatting
+   distinctions or IMG resources at the request of the user). Level 2
+   HTML user agents should support form entry and submission.
+
+4.1. text/html media type
+
+   This specification defines the Internet Media Type [IMEDIA] (formerly
+   referred to as the Content Type [MIME]) called `text/html'. The
+   following is to be registered with [IANA].
+
+    Media Type name
+            text
+
+    Media subtype name
+            html
+
+    Required parameters
+            none
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 18]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    Optional parameters
+            level, charset
+
+    Encoding considerations
+            any encoding is allowed
+
+    Security considerations
+            see 10, "Security Considerations"
+
+    The optional parameters are defined as follows:
+
+    Level
+            The level parameter specifies the feature set used in
+            the document. The level is an integer number, implying
+            that any features of same or lower level may be present
+            in the document. Level 1 is all features defined in this
+            specification except those that require the <FORM>
+            element. Level 2 includes form processing. Level 2 is
+            the default.
+
+    Charset
+            The charset parameter (as defined in section 7.1.1 of
+            RFC 1521[MIME]) may be given to specify the character
+            encoding scheme used to represent the HTML document as a
+            sequence of octets. The default value is outside the
+            scope of this specification; but for example, the
+            default is `US-ASCII' in the context of MIME mail, and
+            `ISO-8859-1' in the context of HTTP [HTTP].
+
+4.2. HTML Document Representation
+
+   A message entity with a content type of `text/html' represents an
+   HTML document, consisting of a single text entity. The `charset'
+   parameter (whether implicit or explicit) identifies a character
+   encoding scheme. The text entity consists of the characters
+   determined by this character encoding scheme and the octets of the
+   body of the message entity.
+
+4.2.1. Undeclared Markup Error Handling
+
+   To facilitate experimentation and interoperability between
+   implementations of various versions of HTML, the installed base of
+   HTML user agents supports a superset of the HTML 2.0 language by
+   reducing it to HTML 2.0: markup in the form of a start-tag or end-
+   tag, whose generic identifier is not declared is mapped to nothing
+   during tokenization. Undeclared attributes are treated similarly. The
+   entire attribute specification of an unknown attribute (i.e., the
+   unknown attribute and its value, if any) should be ignored. On the
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 19]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   other hand, references to undeclared entities should be treated as
+   data characters.
+
+   For example:
+
+    <div class=chapter><h1>foo</h1><p>...</div>
+      => <H1>,"foo",</H1>,<P>,"..."
+    xxx <P ID=z23> yyy
+      => "xxx ",<P>," yyy
+    Let &alpha; &amp; &beta; be finite sets.
+      => "Let &alpha; & &beta; be finite sets."
+
+   Support for notifying the user of such errors is encouraged.
+
+   Information providers are warned that this convention is not binding:
+   unspecified behavior may result, as such markup does not conform to
+   this specification.
+
+4.2.2. Conventional Representation of Newlines
+
+   SGML specifies that a text entity is a sequence of records, each
+   beginning with a record start character and ending with a record end
+   character (code positions 10 and 13 respectively) (section 7.6.1,
+   "Record Boundaries" in [SGML]).
+
+   [MIME] specifies that a body of type `text/*' is a sequence of lines,
+   each terminated by CRLF, that is, octets 13, 10.
+
+   In practice, HTML documents are frequently represented and
+   transmitted using an end of line convention that depends on the
+   conventions of the source of the document; frequently, that
+   representation consists of CR only, LF only, or a CR LF sequence.
+   Hence the decoding of the octets will often result in a text entity
+   with some missing record start and record end characters.
+
+   Since there is no ambiguity, HTML user agents are encouraged to infer
+   the missing record start and end characters.
+
+   An HTML user agent should treat end of line in any of its variations
+   as a word space in all contexts except preformatted text. Within
+   preformatted text, an HTML user agent should treat any of the three
+   common representations of end-of-line as starting a new line.
+
+5. Document Structure
+
+   An HTML document is a tree of elements, including a head and body,
+   headings, paragraphs, lists, etc. Form elements are discussed in 8,
+   "Forms".
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 20]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.1. Document Element: HTML
+
+   The HTML document element consists of a head and a body, much like a
+   memo or a mail message. The head contains the title and optional
+   elements. The body is a text flow consisting of paragraphs, lists,
+   and other elements.
+
+5.2. Head: HEAD
+
+   The head of an HTML document is an unordered collection of
+   information about the document. For example:
+
+    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+    <HEAD>
+    <TITLE>Introduction to HTML</TITLE>
+    </HEAD>
+    ...
+
+5.2.1. Title: TITLE
+
+   Every HTML document must contain a <TITLE> element.
+
+   The title should identify the contents of the document in a global
+   context. A short title, such as "Introduction" may be meaningless out
+   of context. A title such as "Introduction to HTML Elements" is more
+   appropriate.
+
+      NOTE - The length of a title is not limited; however, long titles
+      may be truncated in some applications. To minimize this
+      possibility, titles should be fewer than 64 characters.
+
+   A user agent may display the title of a document in a history list or
+   as a label for the window displaying the document. This differs from
+   headings (5.4, "Headings: H1 ... H6"), which are typically displayed
+   within the body text flow.
+
+5.2.2. Base Address: BASE
+
+   The optional <BASE> element provides a base address for interpreting
+   relative URLs when the document is read out of context (see 7,
+   "Hyperlinks"). The value of the HREF attribute must be an absolute
+   URI.
+
+5.2.3. Keyword Index: ISINDEX
+
+   The <ISINDEX> element indicates that the user agent should allow the
+   user to search an index by giving keywords. See 7.5, "Queries and
+   Indexes" for details.
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 21]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.2.4. Link: LINK
+
+   The <LINK> element represents a hyperlink (see 7, "Hyperlinks").  Any
+   number of LINK elements may occur in the <HEAD> element of an HTML
+   document. It has the same attributes as the <A> element (see 5.7.3,
+   "Anchor: A").
+
+   The <LINK> element is typically used to indicate authorship, related
+   indexes and glossaries, older or more recent versions, document
+   hierarchy, associated resources such as style sheets, etc.
+
+5.2.5. Associated Meta-information: META
+
+   The <META> element is an extensible container for use in identifying
+   specialized document meta-information.  Meta-information has two main
+   functions:
+
+        * to provide a means to discover that the data set exists
+        and how it might be obtained or accessed; and
+
+        * to document the content, quality, and features of a data
+        set, indicating its fitness for use.
+
+   Each <META> element specifies a name/value pair. If multiple META
+   elements are provided with the same name, their combined contents--
+   concatenated as a comma-separated list--is the value associated with
+   that name.
+
+        NOTE - The <META> element should not be used where a
+        specific element, such as <TITLE>, would be more
+        appropriate. Rather than a <META> element with a URI as
+        the value of the CONTENT attribute, use a <LINK>
+        element.
+
+   HTTP servers may read the content of the document <HEAD> to generate
+   header fields corresponding to any elements defining a value for the
+   attribute HTTP-EQUIV.
+
+        NOTE - The method by which the server extracts document
+        meta-information is unspecified and not mandatory. The
+        <META> element only provides an extensible mechanism for
+        identifying and embedding document meta-information --
+        how it may be used is up to the individual server
+        implementation and the HTML user agent.
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 22]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    Attributes of the META element:
+
+    HTTP-EQUIV
+            binds the element to an HTTP header field. An HTTP
+            server may use this information to process the document.
+            In particular, it may include a header field in the
+            responses to requests for this document: the header name
+            is taken from the HTTP-EQUIV attribute value, and the
+            header value is taken from the value of the CONTENT
+            attribute. HTTP header names are not case sensitive.
+
+    NAME
+            specifies the name of the name/value pair. If not
+            present, HTTP-EQUIV gives the name.
+
+    CONTENT
+            specifies the value of the name/value pair.
+
+    Examples
+
+    If the document contains:
+
+    <META HTTP-EQUIV="Expires"
+          CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">
+    <meta http-equiv="Keywords" CONTENT="Fred">
+    <META HTTP-EQUIV="Reply-to"
+          content="fielding@ics.uci.edu (Roy Fielding)">
+    <Meta Http-equiv="Keywords" CONTENT="Barney">
+
+    then the server may include the following header fields:
+
+    Expires: Tue, 04 Dec 1993 21:29:02 GMT
+    Keywords: Fred, Barney
+    Reply-to: fielding@ics.uci.edu (Roy Fielding)
+
+    as part of the HTTP response to a `GET' or `HEAD' request for
+    that document.
+
+    An HTTP server must not use the <META> element to form an HTTP
+    response header unless the HTTP-EQUIV attribute is present.
+
+    An HTTP server may disregard any <META> elements that specify
+    information controlled by the HTTP server, for example `Server',
+
+    `Date', and `Last-modified'.
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 23]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.2.6. Next Id: NEXTID
+
+   The <NEXTID> element is included for historical reasons only.  HTML
+   documents should not contain <NEXTID> elements.
+
+   The <NEXTID> element gives a hint for the name to use for a new <A>
+   element when editing an HTML document. It should be distinct from all
+   NAME attribute values on <A> elements. For example:
+
+   <NEXTID N=Z27>
+
+5.3. Body: BODY
+
+   The <BODY> element contains the text flow of the document, including
+   headings, paragraphs, lists, etc.
+
+   For example:
+
+    <BODY>
+    <h1>Important Stuff</h1>
+    <p>Explanation about important stuff...
+    </BODY>
+
+5.4. Headings: H1 ... H6
+
+   The six heading elements, <H1> through <H6>, denote section headings.
+   Although the order and occurrence of headings is not constrained by
+   the HTML DTD, documents should not skip levels (for example, from H1
+   to H3), as converting such documents to other representations is
+   often problematic.
+
+   Example of use:
+
+    <H1>This is a heading</H1>
+    Here is some text
+    <H2>Second level heading</H2>
+    Here is some more text.
+
+    Typical renderings are:
+
+    H1
+            Bold, very-large font, centered. One or two blank lines
+            above and below.
+
+    H2
+            Bold, large font, flush-left. One or two blank lines
+            above and below.
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 24]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    H3
+            Italic, large font, slightly indented from the left
+            margin. One or two blank lines above and below.
+
+    H4
+            Bold, normal font, indented more than H3. One blank line
+            above and below.
+
+    H5
+            Italic, normal font, indented as H4. One blank line
+            above.
+
+    H6
+            Bold, indented same as normal text, more than H5. One
+            blank line above.
+
+5.5. Block Structuring Elements
+
+   Block structuring elements include paragraphs, lists, and block
+   quotes. They must not contain heading elements, but they may contain
+   phrase markup, and in some cases, they may be nested.
+
+5.5.1. Paragraph: P
+
+   The <P> element indicates a paragraph. The exact indentation, leading
+   space, etc. of a paragraph is not specified and may be a function of
+   other tags, style sheets, etc.
+
+   Typically, paragraphs are surrounded by a vertical space of one line
+   or half a line. The first line in a paragraph is indented in some
+   cases.
+
+   Example of use:
+
+    <H1>This Heading Precedes the Paragraph</H1>
+    <P>This is the text of the first paragraph.
+    <P>This is the text of the second paragraph. Although you do not
+    need to start paragraphs on new lines, maintaining this
+    convention facilitates document maintenance.</P>
+    <P>This is the text of a third paragraph.</P>
+
+5.5.2. Preformatted Text: PRE
+
+   The <PRE> element represents a character cell block of text and is
+   suitable for text that has been formatted for a monospaced font.
+
+   The <PRE> tag may be used with the optional WIDTH attribute. The
+   WIDTH attribute specifies the maximum number of characters for a line
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 25]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   and allows the HTML user agent to select a suitable font and
+   indentation.
+
+   Within preformatted text:
+
+        * Line breaks within the text are rendered as a move to the
+        beginning of the next line.
+
+            NOTE - References to the "beginning of a new line"
+            do not imply that the renderer is forbidden from
+            using a constant left indent for rendering
+            preformatted text. The left indent may be
+            constrained by the width required.
+
+        * Anchor elements and phrase markup may be used.
+
+            NOTE - Constraints on the processing of <PRE>
+            content may limit or prevent the ability of the HTML
+            user agent to faithfully render phrase markup.
+
+        * Elements that define paragraph formatting (headings,
+        address, etc.) must not be used.
+
+            NOTE - Some historical documents contain <P> tags in
+            <PRE> elements. User agents are encouraged to treat
+            this as a line break. A <P> tag followed by a
+            newline character should produce only one line
+            break, not a line break plus a blank line.
+
+        * The horizontal tab character (code position 9 in the HTML
+        document character set) must be interpreted as the smallest
+        positive nonzero number of spaces which will leave the
+        number of characters so far on the line as a multiple of 8.
+        Documents should not contain tab characters, as they are not
+        supported consistently.
+
+    Example of use:
+
+    <PRE>
+    Line 1.
+           Line 2 is to the right of line 1.     <a href="abc">abc</a>
+           Line 3 aligns with line 2.            <a href="def">def</a>
+    </PRE>
+
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 26]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.5.2.1. Example and Listing: XMP, LISTING
+
+   The <XMP> and <LISTING> elements are similar to the <PRE> element,
+   but they have a different syntax. Their content is declared as CDATA,
+   which means that no markup except the end-tag open delimiter-in-
+   context is recognized (see 9.6 "Delimiter Recognition" of [SGML]).
+
+      NOTE - In a previous draft of the HTML specification, the syntax
+      of <XMP> and <LISTING> elements allowed closing tags to be treated
+      as data characters, as long as the tag name was not <XMP> or
+      <LISTING>, respectively.
+
+   Since CDATA declared content has a number of unfortunate interactions
+   with processing techniques and tends to be used and implemented
+   inconsistently, HTML documents should not contain <XMP> nor <LISTING>
+   elements -- the <PRE> tag is more expressive and more consistently
+   supported.
+
+   The <LISTING> element should be rendered so that at least 132
+   characters fit on a line. The <XMP> element should be rendered so
+   that at least 80 characters fit on a line but is otherwise identical
+   to the <LISTING> element.
+
+      NOTE - In a previous draft, HTML included a <PLAINTEXT> element
+      that is similar to the <LISTING> element, except that there is no
+      closing tag: all characters after the <PLAINTEXT> start-tag are
+      data.
+
+5.5.3. Address: ADDRESS
+
+   The <ADDRESS> element contains such information as address, signature
+   and authorship, often at the beginning or end of the body of a
+   document.
+
+   Typically, the <ADDRESS> element is rendered in an italic typeface
+   and may be indented.
+
+   Example of use:
+
+    <ADDRESS>
+    Newsletter editor<BR>
+    J.R. Brown<BR>
+    JimquickPost News, Jimquick, CT 01234<BR>
+    Tel (123) 456 7890
+    </ADDRESS>
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 27]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.5.4. Block Quote: BLOCKQUOTE
+
+   The <BLOCKQUOTE> element contains text quoted from another source.
+
+   A typical rendering might be a slight extra left and right indent,
+   and/or italic font. The <BLOCKQUOTE> typically provides space above
+   and below the quote.
+
+   Single-font rendition may reflect the quotation style of Internet
+   mail by putting a vertical line of graphic characters, such as the
+   greater than symbol (>), in the left margin.
+
+   Example of use:
+
+    I think the play ends
+    <BLOCKQUOTE>
+    <P>Soft you now, the fair Ophelia. Nymph, in thy orisons, be all
+    my sins remembered.
+    </BLOCKQUOTE>
+    but I am not sure.
+
+5.6. List Elements
+
+   HTML includes a number of list elements. They may be used in
+   combination; for example, a <OL> may be nested in an <LI> element of
+   a <UL>.
+
+   The COMPACT attribute suggests that a compact rendering be used.
+
+5.6.1. Unordered List: UL, LI
+
+   The <UL> represents a list of items -- typically rendered as a
+   bulleted list.
+
+   The content of a <UL> element is a sequence of <LI> elements.  For
+   example:
+
+    <UL>
+    <LI>First list item
+    <LI>Second list item
+     <p>second paragraph of second item
+    <LI>Third list item
+    </UL>
+
+5.6.2. Ordered List: OL
+
+   The <OL> element represents an ordered list of items, sorted by
+   sequence or order of importance. It is typically rendered as a
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 28]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   numbered list.
+
+   The content of a <OL> element is a sequence of <LI> elements.  For
+   example:
+
+    <OL>
+    <LI>Click the Web button to open URI window.
+    <LI>Enter the URI number in the text field of the Open URI
+    window. The Web document you specified is displayed.
+      <ol>
+       <li>substep 1
+       <li>substep 2
+      </ol>
+    <LI>Click highlighted text to move from one link to another.
+    </OL>
+
+5.6.3. Directory List: DIR
+
+   The <DIR> element is similar to the <UL> element. It represents a
+   list of short items, typically up to 20 characters each. Items in a
+   directory list may be arranged in columns, typically 24 characters
+   wide.
+
+   The content of a <DIR> element is a sequence of <LI> elements.
+   Nested block elements are not allowed in the content of <DIR>
+   elements. For example:
+
+    <DIR>
+    <LI>A-H<LI>I-M
+    <LI>M-R<LI>S-Z
+    </DIR>
+
+5.6.4. Menu List: MENU
+
+   The <MENU> element is a list of items with typically one line per
+   item. The menu list style is typically more compact than the style of
+   an unordered list.
+
+   The content of a <MENU> element is a sequence of <LI> elements.
+   Nested block elements are not allowed in the content of <MENU>
+   elements. For example:
+
+    <MENU>
+    <LI>First item in the list.
+    <LI>Second item in the list.
+    <LI>Third item in the list.
+    </MENU>
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 29]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.6.5. Definition List: DL, DT, DD
+
+   A definition list is a list of terms and corresponding definitions.
+   Definition lists are typically formatted with the term flush-left and
+   the definition, formatted paragraph style, indented after the term.
+
+   The content of a <DL> element is a sequence of <DT> elements and/or
+   <DD> elements, usually in pairs. Multiple <DT> may be paired with a
+   single <DD> element. Documents should not contain multiple
+   consecutive <DD> elements.
+
+   Example of use:
+
+    <DL>
+    <DT>Term<DD>This is the definition of the first term.
+    <DT>Term<DD>This is the definition of the second term.
+    </DL>
+
+   If the DT term does not fit in the DT column (typically one third of
+   the display area), it may be extended across the page with the DD
+   section moved to the next line, or it may be wrapped onto successive
+   lines of the left hand column.
+
+   The optional COMPACT attribute suggests that a compact rendering be
+   used, because the list items are small and/or the entire list is
+   large.
+
+   Unless the COMPACT attribute is present, an HTML user agent may leave
+   white space between successive DT, DD pairs. The COMPACT attribute
+   may also reduce the width of the left-hand (DT) column.
+
+    <DL COMPACT>
+    <DT>Term<DD>This is the first definition in compact format.
+    <DT>Term<DD>This is the second definition in compact format.
+    </DL>
+
+5.7. Phrase Markup
+
+   Phrases may be marked up according to idiomatic usage, typographic
+   appearance, or for use as hyperlink anchors.
+
+   User agents must render highlighted phrases distinctly from plain
+   text. Additionally, <EM> content must be rendered as distinct from
+   <STRONG> content, and <B> content must rendered as distinct from <I>
+   content.
+
+   Phrase elements may be nested within the content of other phrase
+   elements; however, HTML user agents may render nested phrase elements
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 30]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   indistinctly from non-nested elements:
+
+   plain <B>bold <I>italic</I></B> may be rendered
+   the same as plain <B>bold </B><I>italic</I>
+
+5.7.1. Idiomatic Elements
+
+   Phrases may be marked up to indicate certain idioms.
+
+      NOTE - User agents may support the <DFN> element, not included in
+      this specification, as it has been deployed to some extent. It is
+      used to indicate the defining instance of a term, and it is
+      typically rendered in italic or bold italic.
+
+5.7.1.1. Citation: CITE
+
+      The <CITE> element is used to indicate the title of a book or
+      other citation. It is typically rendered as italics. For example:
+
+      He just couldn't get enough of <cite>The Grapes of Wrath</cite>.
+
+5.7.1.2. Code: CODE
+
+      The <CODE> element indicates an example of code, typically
+      rendered in a mono-spaced font. The <CODE> element is intended for
+      short words or phrases of code; the <PRE> block structuring
+      element (5.5.2, "Preformatted Text: PRE") is more appropriate
+       for multiple-line listings. For example:
+
+      The expression <code>x += 1</code>
+      is short for <code>x = x + 1</code>.
+
+5.7.1.3. Emphasis: EM
+
+      The <EM> element indicates an emphasized phrase, typically
+      rendered as italics. For example:
+
+      A singular subject <em>always</em> takes a singular verb.
+
+5.7.1.4. Keyboard: KBD
+
+      The <KBD> element indicates text typed by a user, typically
+      rendered in a mono-spaced font. This is commonly used in
+      instruction manuals. For example:
+
+      Enter <kbd>FIND IT</kbd> to search the database.
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 31]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.7.1.5. Sample: SAMP
+
+      The <SAMP> element indicates a sequence of literal characters,
+      typically rendered in a mono-spaced font. For example:
+
+      The only word containing the letters <samp>mt</samp> is dreamt.
+
+5.7.1.6. Strong Emphasis: STRONG
+
+      The <STRONG> element indicates strong emphasis, typically rendered
+      in bold. For example:
+
+      <strong>STOP</strong>, or I'll say "<strong>STOP</strong>" again!
+
+5.7.1.7. Variable: VAR
+
+      The <VAR> element indicates a placeholder variable, typically
+      rendered as italic. For example:
+
+      Type <SAMP>html-check <VAR>file</VAR> | more</SAMP>
+      to check <VAR>file</VAR> for markup errors.
+
+5.7.2. Typographic Elements
+
+      Typographic elements are used to specify the format of marked
+      text.
+
+      Typical renderings for idiomatic elements may vary between user
+      agents. If a specific rendering is necessary -- for example, when
+      referring to a specific text attribute as in "The italic parts are
+      mandatory" -- a typographic element can be used to ensure that the
+      intended typography is used where possible.
+
+      NOTE - User agents may support some typographic elements not
+      included in this specification, as they have been deployed to some
+      extent. The <STRIKE> element indicates horizontal line through the
+      characters, and the <U> element indicates an underline.
+
+5.7.2.1. Bold: B
+
+   The <B> element indicates bold text. Where bold typography is
+   unavailable, an alternative representation may be used.
+
+5.7.2.2. Italic: I
+
+   The <I> element indicates italic text. Where italic typography is
+   unavailable, an alternative representation may be used.
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 32]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+5.7.2.3. Teletype: TT
+
+   The <TT> element indicates teletype (monospaced )text. Where a
+   teletype font is unavailable, an alternative representation may be
+   used.
+
+5.7.3. Anchor: A
+
+   The <A> element indicates a hyperlink anchor (see 7, "Hyperlinks").
+   At least one of the NAME and HREF attributes should be present.
+   Attributes of the <A> element:
+
+    HREF
+            gives the URI of the head anchor of a hyperlink.
+
+    NAME
+            gives the name of the anchor, and makes it available as
+            a head of a hyperlink.
+
+    TITLE
+            suggests a title for the destination resource --
+            advisory only. The TITLE attribute may be used:
+
+                * for display prior to accessing the destination
+                resource, for example, as a margin note or on a
+                small box while the mouse is over the anchor, or
+                while the document is being loaded;
+
+                * for resources that do not include a title, such as
+                graphics, plain text and Gopher menus, for use as a
+                window title.
+
+    REL
+            The REL attribute gives the relationship(s) described by
+            the hyperlink. The value is a whitespace separated list
+            of relationship names. The semantics of link
+            relationships are not specified in this document.
+
+    REV
+            same as the REL attribute, but the semantics of the
+            relationship are in the reverse direction. A link from A
+            to B with REL="X" expresses the same relationship as a
+            link from B to A with REV="X". An anchor may have both
+            REL and REV attributes.
+
+    URN
+            specifies a preferred, more persistent identifier for
+            the head anchor of the hyperlink. The syntax and
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 33]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+            semantics of the URN attribute are not yet specified.
+
+    METHODS
+            specifies methods to be used in accessing the
+            destination, as a whitespace-separated list of names.
+            The set of applicable names is a function of the scheme
+            of the URI in the HREF attribute. For similar reasons as
+            for the TITLE attribute, it may be useful to include the
+            information in advance in the link. For example, the
+            HTML user agent may chose a different rendering as a
+            function of the methods allowed; for example, something
+            that is searchable may get a different icon.
+
+5.8. Line Break: BR
+
+   The <BR> element specifies a line break between words (see 6,
+   "Characters, Words, and Paragraphs"). For example:
+
+    <P> Pease porridge hot<BR>
+    Pease porridge cold<BR>
+    Pease porridge in the pot<BR>
+    Nine days old.
+
+5.9. Horizontal Rule: HR
+
+   The <HR> element is a divider between sections of text; typically a
+   full width horizontal rule or equivalent graphic.  For example:
+
+    <HR>
+    <ADDRESS>February 8, 1995, CERN</ADDRESS>
+    </BODY>
+
+5.10. Image: IMG
+
+   The <IMG> element refers to an image or icon via a hyperlink (see
+   7.3, "Simultaneous Presentation of Image Resources").
+
+   HTML user agents may process the value of the ALT attribute as an
+   alternative to processing the image resource indicated by the SRC
+   attribute.
+
+      NOTE - Some HTML user agents can process graphics linked via
+      anchors, but not <IMG> graphics. If a graphic is essential, it
+      should be referenced from an <A> element rather than an <IMG>
+      element. If the graphic is not essential, then the <IMG> element
+      is appropriate.
+
+   Attributes of the <IMG> element:
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 34]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    ALIGN
+            alignment of the image with respect to the text
+            baseline.
+
+                * `TOP' specifies that the top of the image aligns
+                with the tallest item on the line containing the
+                image.
+
+                * `MIDDLE' specifies that the center of the image
+                aligns with the baseline of the line containing the
+                image.
+
+                * `BOTTOM' specifies that the bottom of the image
+                aligns with the baseline of the line containing the
+                image.
+
+    ALT
+            text to use in place of the referenced image resource,
+            for example due to processing constraints or user
+            preference.
+
+    ISMAP
+            indicates an image map (see 7.6, "Image Maps").
+
+    SRC
+            specifies the URI of the image resource.
+
+                NOTE - In practice, the media types of image
+                resources are limited to a few raster graphic
+                formats: typically `image/gif', `image/jpeg'. In
+                particular, `text/html' resources are not
+                intended to be used as image resources.
+
+    Examples of use:
+
+    <IMG SRC="triangle.xbm" ALT="Warning:"> Be sure
+    to read these instructions.
+
+    <a href="http://machine/htbin/imagemap/sample">
+    <IMG SRC="sample.xbm" ISMAP>
+    </a>
+
+6. Characters, Words, and Paragraphs
+
+   An HTML user agent should present the body of an HTML document as a
+   collection of typeset paragraphs and preformatted text.  Except for
+   preformatted elements (<PRE>, <XMP>, <LISTING>, <TEXTAREA>), each
+   block structuring element is regarded as a paragraph by taking the
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 35]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   data characters in its content and the content of its descendant
+   elements, concatenating them, and splitting the result into words,
+   separated by space, tab, or record end characters (and perhaps hyphen
+   characters). The sequence of words is typeset as a paragraph by
+   breaking it into lines.
+
+6.1. The HTML Document Character Set
+
+   The document character set specified in 9.5, "SGML Declaration for
+   HTML" must be supported by HTML user agents. It includes the graphic
+   characters of Latin Alphabet No. 1, or simply Latin-1.  Latin-1
+   comprises 191 graphic characters, including the alphabets of most
+   Western European languages.
+
+      NOTE - Use of the non-breaking space and soft hyphen indicator
+      characters is discouraged because support for them is not widely
+      deployed.
+
+      NOTE - To support non-western writing systems, a larger character
+      repertoire will be specified in a future version of HTML. The
+      document character set will be [ISO-10646], or some subset that
+      agrees with [ISO-10646]; in particular, all numeric character
+      references must use code positions assigned by [ISO-10646].
+
+   In SGML applications, the use of control characters is limited in
+   order to maximize the chance of successful interchange over
+   heterogeneous networks and operating systems. In the HTML document
+   character set only three control characters are allowed: Horizontal
+   Tab, Carriage Return, and Line Feed (code positions 9, 13, and 10).
+
+   The HTML DTD references the Added Latin 1 entity set, to allow
+   mnemonic representation of selected Latin 1 characters using only the
+   widely supported ASCII character repertoire. For example:
+
+   Kurt G&ouml;del was a famous logician and mathematician.
+
+   See 9.7.2, "ISO Latin 1 Character Entity Set" for a table of the
+   "Added Latin 1" entities, and 13, "The HTML Coded Character Set" for
+   a table of the code positions of [ISO 8859-1] and the control
+   characters in the HTML document character set.
+
+7. Hyperlinks
+
+   In addition to general purpose elements such as paragraphs and lists,
+   HTML documents can express hyperlinks. An HTML user agent allows the
+   user to navigate these hyperlinks.
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 36]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   A hyperlink is a relationship between two anchors, called the head
+   and the tail of the hyperlink[DEXTER]. Anchors are identified by an
+   anchor address: an absolute Uniform Resource Identifier (URI),
+   optionally followed by a '#' and a sequence of characters called a
+   fragment identifier. For example:
+
+   http://www.w3.org/hypertext/WWW/TheProject.html
+   http://www.w3.org/hypertext/WWW/TheProject.html#z31
+
+   In an anchor address, the URI refers to a resource; it may be used in
+   a variety of information retrieval protocols to obtain an entity that
+   represents the resource, such as an HTML document. The fragment
+   identifier, if present, refers to some view on, or portion of the
+   resource.
+
+   Each of the following markup constructs indicates the tail anchor of
+   a hyperlink or set of hyperlinks:
+
+        * <A> elements with HREF present.
+
+        * <LINK> elements.
+
+        * <IMG> elements.
+
+        * <INPUT> elements with the SRC attribute present.
+
+        * <ISINDEX> elements.
+
+        * <FORM> elements with `METHOD=GET'.
+
+   These markup constructs refer to head anchors by a URI, either
+   absolute or relative, or a fragment identifier, or both.
+
+   In the case of a relative URI, the absolute URI in the address of the
+   head anchor is the result of combining the relative URI with a base
+   absolute URI as in [RELURL]. The base document is taken from the
+   document's <BASE> element, if present; else, it is determined as in
+   [RELURL].
+
+7.1. Accessing Resources
+
+   Once the address of the head anchor is determined, the user agent may
+   obtain a representation of the resource.
+
+   For example, if the base URI is `http://host/x/y.html' and the
+   document contains:
+
+   <img src="../icons/abc.gif">
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 37]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   then the user agent uses the URI `http://host/icons/abc.gif' to
+   access the resource, as in [URL]..
+
+7.2. Activation of Hyperlinks
+
+   An HTML user agent allows the user to navigate the content of the
+   document and request activation of hyperlinks denoted by <A>
+   elements. HTML user agents should also allow activation of <LINK>
+   element hyperlinks.
+
+   To activate a link, the user agent obtains a representation of the
+   resource identified in the address of the head anchor. If the
+   representation is another HTML document, navigation may begin again
+   with this new document.
+
+7.3. Simultaneous Presentation of Image Resources
+
+   An HTML user agent may activate hyperlinks indicated by <IMG> and
+   <INPUT> elements concurrently with processing the document; that is,
+   image hyperlinks may be processed without explicit request by the
+   user. Image resources should be embedded in the presentation at the
+   point of the tail anchor, that is the <IMG> or <INPUT> element.
+
+   <LINK> hyperlinks may also be processed without explicit user
+   request; for example, style sheet resources may be processed before
+   or during the processing of the document.
+
+7.4. Fragment Identifiers
+
+   Any characters following a `#' character in a hypertext address
+   constitute a fragment identifier. In particular, an address of the
+   form `#fragment' refers to an anchor in the same document.
+
+   The meaning of fragment identifiers depends on the media type of the
+   representation of the anchor's resource. For `text/html'
+   representations, it refers to the <A> element with a NAME attribute
+   whose value is the same as the fragment identifier.  The matching is
+   case sensitive. The document should have exactly one such element.
+   The user agent should indicate the anchor element, for example by
+   scrolling to and/or highlighting the phrase.
+
+   For example, if the base URI is `http://host/x/y.html' and the user
+   activated the link denoted by the following markup:
+
+   <p> See: <a href="app1.html#bananas">appendix 1</a>
+   for more detail on bananas.
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 38]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   Then the user agent accesses the resource identified by
+   `http://host/x/app1.html'. Assuming the resource is represented using
+   the `text/html' media type, the user agent must locate the <A>
+   element whose NAME attribute is `bananas' and begin navigation there.
+
+7.5. Queries and Indexes
+
+   The <ISINDEX> element represents a set of hyperlinks. The user can
+   choose from the set by providing keywords to the user agent.  The
+   user agent computes the head URI by appending `?' and the keywords to
+   the base URI. The keywords are escaped according to [URL] and joined
+   by `+'. For example, if a document contains:
+
+    <BASE HREF="http://host/index">
+    <ISINDEX>
+
+    and the user provides the keywords `apple' and `berry', then the
+    user agent must access the resource
+    `http://host/index?apple+berry'.
+
+    <FORM> elements with `METHOD=GET' also represent sets of
+    hyperlinks. See 8.2.2, "Query Forms: METHOD=GET" for details.
+
+7.6. Image Maps
+
+   If the ISMAP attribute is present on an <IMG> element, the <IMG>
+   element must be contained in an <A> element with an HREF present.
+   This construct represents a set of hyperlinks. The user can choose
+   from the set by choosing a pixel of the image. The user agent
+   computes the head URI by appending `?' and the x and y coordinates of
+   the pixel to the URI given in the <A> element.  For example, if a
+   document contains:
+
+   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+   <head><title>ImageMap Example</title>
+   <BASE HREF="http://host/index"></head>
+   <body>
+   <p> Choose any of these icons:<br>
+   <a href="/cgi-bin/imagemap"><img ismap src="icons.gif"></a>
+
+   and the user chooses the upper-leftmost pixel, the chosen
+   hyperlink is the one with the URI
+   `http://host/cgi-bin/imagemap?0,0'.
+
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 39]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+8. Forms
+
+   A form is a template for a form data set and an associated
+   method and action URI. A form data set is a sequence of
+   name/value pair fields. The names are specified on the NAME
+   attributes of form input elements, and the values are given
+   initial values by various forms of markup and edited by the
+   user. The resulting form data set is used to access an
+   information service as a function of the action and method.
+
+   Forms elements can be mixed in with document structuring
+   elements. For example, a <PRE> element may contain a <FORM>
+   element, or a <FORM> element may contain lists which contain
+   <INPUT> elements. This gives considerable flexibility in
+   designing the layout of forms.
+
+   Form processing is a level 2 feature.
+
+8.1. Form Elements
+
+8.1.1. Form: FORM
+
+   The <FORM> element contains a sequence of input elements, along
+   with document structuring elements. The attributes are:
+
+    ACTION
+            specifies the action URI for the form. The action URI of
+            a form defaults to the base URI of the document (see 7,
+            "Hyperlinks").
+
+    METHOD
+            selects a method of accessing the action URI. The set of
+            applicable methods is a function of the scheme of the
+            action URI of the form. See 8.2.2, "Query Forms:
+            METHOD=GET" and 8.2.3, "Forms with Side-Effects:
+            METHOD=POST".
+
+    ENCTYPE
+            specifies the media type used to encode the name/value
+            pairs for transport, in case the protocol does not
+            itself impose a format. See 8.2.1, "The form-urlencoded
+            Media Type".
+
+8.1.2. Input Field: INPUT
+
+   The <INPUT> element represents a field for user input. The TYPE
+   attribute discriminates between several variations of fields.
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 40]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   The <INPUT> element has a number of attributes. The set of applicable
+   attributes depends on the value of the TYPE attribute.
+
+8.1.2.1. Text Field: INPUT TYPE=TEXT
+
+   The default value of the TYPE attribute is `TEXT', indicating a
+   single line text entry field. (Use the <TEXTAREA> element for multi-
+   line text fields.)
+
+   Required attributes are:
+
+    NAME
+            name for the form field corresponding to this element.
+
+    The optional attributes are:
+
+    MAXLENGTH
+            constrains the number of characters that can be entered
+            into a text input field. If the value of MAXLENGTH is
+            greater the the value of the SIZE attribute, the field
+            should scroll appropriately. The default number of
+            characters is unlimited.
+
+    SIZE
+            specifies the amount of display space allocated to this
+            input field according to its type. The default depends
+            on the user agent.
+
+    VALUE
+            The initial value of the field.
+
+    For example:
+
+<p>Street Address: <input name=street><br>
+Postal City code: <input name=city size=16 maxlength=16><br>
+Zip Code: <input name=zip size=10 maxlength=10 value="99999-9999"><br>
+
+8.1.2.2. Password Field: INPUT TYPE=PASSWORD
+
+   An <INPUT> element with `TYPE=PASSWORD' is a text field as above,
+   except that the value is obscured as it is entered. (see also: 10,
+   "Security Considerations").
+
+   For example:
+
+<p>Name: <input name=login> Password: <input type=password name=passwd>
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 41]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+8.1.2.3. Check Box: INPUT TYPE=CHECKBOX
+
+   An <INPUT> element with `TYPE=CHECKBOX' represents a boolean choice.
+   A set of such elements with the same name represents an n-of-many
+   choice field. Required attributes are:
+
+    NAME
+            symbolic name for the form field corresponding to this
+            element or group of elements.
+
+    VALUE
+            The portion of the value of the field contributed by
+            this element.
+
+    Optional attributes are:
+
+    CHECKED
+            indicates that the initial state is on.
+
+    For example:
+
+  <p>What flavors do you like?
+  <input type=checkbox name=flavor value=vanilla>Vanilla<br>
+  <input type=checkbox name=flavor value=strawberry>Strawberry<br>
+  <input type=checkbox name=flavor value=chocolate checked>Chocolate<br>
+
+8.1.2.4. Radio Button: INPUT TYPE=RADIO
+
+   An <INPUT> element with `TYPE=RADIO' represents a boolean choice. A
+   set of such elements with the same name represents a 1-of-many choice
+   field. The NAME and VALUE attributes are required as for check boxes.
+   Optional attributes are:
+
+    CHECKED
+            indicates that the initial state is on.
+   At all times, exactly one of the radio buttons in a set is checked.
+   If none of the <INPUT> elements of a set of radio buttons specifies
+   `CHECKED', then the user agent must check the first radio button of
+   the set initially.
+
+   For example:
+
+    <p>Which is your favorite?
+    <input type=radio name=flavor value=vanilla>Vanilla<br>
+    <input type=radio name=flavor value=strawberry>Strawberry<br>
+    <input type=radio name=flavor value=chocolate>Chocolate<br>
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 42]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+8.1.2.5. Image Pixel: INPUT TYPE=IMAGE
+
+   An <INPUT> element with `TYPE=IMAGE' specifies an image resource to
+   display, and allows input of two form fields: the x and y coordinate
+   of a pixel chosen from the image. The names of the fields are the
+   name of the field with `.x' and `.y' appended.  `TYPE=IMAGE' implies
+   `TYPE=SUBMIT' processing; that is, when a pixel is chosen, the form
+   as a whole is submitted.
+
+   The NAME attribute is required as for other input fields. The SRC
+   attribute is required and the ALIGN is optional as for the <IMG>
+   element (see 5.10, "Image: IMG").
+
+   For example:
+
+    <p>Choose a point on the map:
+    <input type=image name=point src="map.gif">
+
+8.1.2.6. Hidden Field: INPUT TYPE=HIDDEN
+
+   An <INPUT> element with `TYPE=HIDDEN' represents a hidden field.The
+   user does not interact with this field; instead, the VALUE attribute
+   specifies the value of the field. The NAME and VALUE attributes are
+   required.
+
+   For example:
+
+   <input type=hidden name=context value="l2k3j4l2k3j4l2k3j4lk23">
+
+8.1.2.7. Submit Button: INPUT TYPE=SUBMIT
+
+   An <INPUT> element with `TYPE=SUBMIT' represents an input option,
+   typically a button, that instructs the user agent to submit the form.
+   Optional attributes are:
+
+    NAME
+            indicates that this element contributes a form field
+            whose value is given by the VALUE attribute. If the NAME
+            attribute is not present, this element does not
+            contribute a form field.
+
+    VALUE
+            indicates a label for the input (button).
+
+    You may submit this request internally:
+    <input type=submit name=recipient value=internal><br>
+    or to the external world:
+    <input type=submit name=recipient value=world>
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 43]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+8.1.2.8. Reset Button: INPUT TYPE=RESET
+
+   An <INPUT> element with `TYPE=RESET' represents an input option,
+   typically a button, that instructs the user agent to reset the form's
+   fields to their initial states. The VALUE attribute, if present,
+   indicates a label for the input (button).
+
+   When you are finished, you may submit this request:
+   <input type=submit><br>
+   You may clear the form and start over at any time: <input type=reset>
+
+8.1.3. Selection: SELECT
+
+   The <SELECT> element constrains the form field to an enumerated list
+   of values. The values are given in <OPTION> elements.  Attributes
+   are:
+
+    MULTIPLE
+            indicates that more than one option may be included in
+            the value.
+
+    NAME
+            specifies the name of the form field.
+
+    SIZE
+            specifies the number of visible items. Select fields of
+            size one are typically pop-down menus, whereas select
+            fields with size greater than one are typically lists.
+
+    For example:
+
+    <SELECT NAME="flavor">
+    <OPTION>Vanilla
+    <OPTION>Strawberry
+    <OPTION value="RumRasin">Rum and Raisin
+    <OPTION selected>Peach and Orange
+    </SELECT>
+
+   The initial state has the first option selected, unless a SELECTED
+   attribute is present on any of the <OPTION> elements.
+
+8.1.3.1. Option: OPTION
+
+   The Option element can only occur within a Select element. It
+   represents one choice, and has the following attributes:
+
+    SELECTED
+            Indicates that this option is initially selected.
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 44]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    VALUE
+            indicates the value to be returned if this option is
+            chosen. The field value defaults to the content of the
+            <OPTION> element.
+
+   The content of the <OPTION> element is presented to the user to
+   represent the option. It is used as a returned value if the VALUE
+   attribute is not present.
+
+8.1.4. Text Area: TEXTAREA
+
+   The <TEXTAREA> element represents a multi-line text field.
+   Attributes are:
+
+    COLS
+            the number of visible columns to display for the text
+            area, in characters.
+
+    NAME
+            Specifies the name of the form field.
+
+    ROWS
+            The number of visible rows to display for the text area,
+            in characters.
+
+    For example:
+
+    <TEXTAREA NAME="address" ROWS=6 COLS=64>
+    HaL Computer Systems
+    1315 Dell Avenue
+    Campbell, California 95008
+    </TEXTAREA>
+
+   The content of the <TEXTAREA> element is the field's initial value.
+
+   Typically, the ROWS and COLS attributes determine the visible
+   dimension of the field in characters. The field is typically rendered
+   in a fixed-width font. HTML user agents should allow text to extend
+   beyond these limits by scrolling as needed.
+
+8.2. Form Submission
+
+   An HTML user agent begins processing a form by presenting the
+   document with the fields in their initial state. The user is allowed
+   to modify the fields, constrained by the field type etc.  When the
+   user indicates that the form should be submitted (using a submit
+   button or image input), the form data set is processed according to
+   its method, action URI and enctype.
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 45]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   When there is only one single-line text input field in a form, the
+   user agent should accept Enter in that field as a request to submit
+   the form.
+
+8.2.1. The form-urlencoded Media Type
+
+   The default encoding for all forms is `application/x-www-form-
+   urlencoded'. A form data set is represented in this media type as
+   follows:
+
+        1. The form field names and values are escaped: space
+        characters are replaced by `+', and then reserved characters
+        are escaped as per [URL]; that is, non-alphanumeric
+        characters are replaced by `%HH', a percent sign and two
+        hexadecimal digits representing the ASCII code of the
+        character. Line breaks, as in multi-line text field values,
+        are represented as CR LF pairs, i.e. `%0D%0A'.
+
+        2. The fields are listed in the order they appear in the
+        document with the name separated from the value by `=' and
+        the pairs separated from each other by `&'. Fields with null
+        values may be omitted. In particular, unselected radio
+        buttons and checkboxes should not appear in the encoded
+        data, but hidden fields with VALUE attributes present
+        should.
+
+            NOTE - The URI from a query form submission can be
+            used in a normal anchor style hyperlink.
+            Unfortunately, the use of the `&' character to
+            separate form fields interacts with its use in SGML
+            attribute values as an entity reference delimiter.
+            For example, the URI `http://host/?x=1&y=2' must be
+            written `<a href="http://host/?x=1&#38;y=2"' or `<a
+            href="http://host/?x=1&amp;y=2">'.
+
+            HTTP server implementors, and in particular, CGI
+            implementors are encouraged to support the use of
+            `;' in place of `&' to save users the trouble of
+            escaping `&' characters this way.
+
+8.2.2. Query Forms: METHOD=GET
+
+   If the processing of a form is idempotent (i.e. it has no lasting
+   observable effect on the state of the world), then the form method
+   should be `GET'. Many database searches have no visible side-effects
+   and make ideal applications of query forms.
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 46]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   To process a form whose action URL is an HTTP URL and whose method is
+   `GET', the user agent starts with the action URI and appends a `?'
+   and the form data set, in `application/x-www-form-urlencoded' format
+   as above. The user agent then traverses the link to this URI just as
+   if it were an anchor (see 7.2, "Activation of Hyperlinks").
+
+      NOTE - The URL encoding may result in very long URIs, which cause
+      some historical HTTP server implementations to exhibit defective
+      behavior. As a result, some HTML forms are written using
+      `METHOD=POST' even though the form submission has no side-effects.
+
+8.2.3. Forms with Side-Effects: METHOD=POST
+
+   If the service associated with the processing of a form has side
+   effects (for example, modification of a database or subscription to a
+   service), the method should be `POST'.
+
+   To process a form whose action URL is an HTTP URL and whose method is
+   `POST', the user agent conducts an HTTP POST transaction using the
+   action URI, and a message body of type `application/x-www-form-
+   urlencoded' format as above. The user agent should display the
+   response from the HTTP POST interaction just as it would display the
+   response from an HTTP GET above.
+
+8.2.4. Example Form Submission: Questionnaire Form
+
+   Consider the following document:
+
+    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+    <title>Sample of HTML Form Submission</title>
+    <H1>Sample Questionnaire</H1>
+    <P>Please fill out this questionnaire:
+    <FORM METHOD="POST" ACTION="http://www.w3.org/sample">
+    <P>Your name: <INPUT NAME="name" size="48">
+    <P>Male <INPUT NAME="gender" TYPE=RADIO VALUE="male">
+    <P>Female <INPUT NAME="gender" TYPE=RADIO VALUE="female">
+    <P>Number in family: <INPUT NAME="family" TYPE=text>
+    <P>Cities in which you maintain a residence:
+    <UL>
+    <LI>Kent <INPUT NAME="city" TYPE=checkbox VALUE="kent">
+    <LI>Miami <INPUT NAME="city" TYPE=checkbox VALUE="miami">
+    <LI>Other <TEXTAREA NAME="other" cols=48 rows=4></textarea>
+    </UL>
+    Nickname: <INPUT NAME="nickname" SIZE="42">
+    <P>Thank you for responding to this questionnaire.
+    <P><INPUT TYPE=SUBMIT> <INPUT TYPE=RESET>
+    </FORM>
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 47]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    The initial state of the form data set is:
+
+    name
+            ""
+
+    gender
+            "male"
+
+    family
+            ""
+
+    other
+            ""
+
+    nickname
+            ""
+
+    Note that the radio input has an initial value, while the
+    checkbox has none.
+
+    The user might edit the fields and request that the form be
+    submitted. At that point, suppose the values are:
+
+    name
+            "John Doe"
+
+    gender
+            "male"
+
+    family
+            "5"
+
+    city
+            "kent"
+
+    city
+            "miami"
+
+    other
+            "abc\ndefk"
+
+    nickname
+            "J&D"
+
+   The user agent then conducts an HTTP POST transaction using the URI
+   `http://www.w3.org/sample'. The message body would be (ignore the
+   line break):
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 48]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   name=John+Doe&gender=male&family=5&city=kent&city=miami&
+   other=abc%0D%0Adef&nickname=J%26D
+
+9. HTML Public Text
+
+9.1. HTML DTD
+
+   This is the Document Type Definition for the HyperText Markup
+   Language, level 2.
+
+<!--    html.dtd
+
+        Document Type Definition for the HyperText Markup Language
+                 (HTML DTD)
+
+        $Id: rfc1866.txt,v 1.1 2001-09-20 23:27:02 Pixel Exp $
+
+        Author: Daniel W. Connolly <connolly@w3.org>
+        See Also: html.decl, html-1.dtd
+          http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
+-->
+
+<!ENTITY % HTML.Version
+        "-//IETF//DTD HTML 2.0//EN"
+
+        -- Typical usage:
+
+            <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+            <html>
+            ...
+            </html>
+        --
+        >
+
+
+<!--============ Feature Test Entities ========================-->
+
+<!ENTITY % HTML.Recommended "IGNORE"
+        -- Certain features of the language are necessary for
+           compatibility with widespread usage, but they may
+           compromise the structural integrity of a document.
+           This feature test entity enables a more prescriptive
+           document type definition that eliminates
+           those features.
+        -->
+
+<![ %HTML.Recommended [
+        <!ENTITY % HTML.Deprecated "IGNORE">
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 49]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+]]>
+
+<!ENTITY % HTML.Deprecated "INCLUDE"
+        -- Certain features of the language are necessary for
+           compatibility with earlier versions of the specification,
+           but they tend to be used and implemented inconsistently,
+           and their use is deprecated. This feature test entity
+           enables a document type definition that eliminates
+           these features.
+        -->
+
+<!ENTITY % HTML.Highlighting "INCLUDE"
+        -- Use this feature test entity to validate that a
+           document uses no highlighting tags, which may be
+           ignored on minimal implementations.
+        -->
+
+<!ENTITY % HTML.Forms "INCLUDE"
+        -- Use this feature test entity to validate that a document
+           contains no forms, which may not be supported in minimal
+           implementations
+        -->
+
+<!--============== Imported Names ==============================-->
+
+<!ENTITY % Content-Type "CDATA"
+        -- meaning an internet media type
+           (aka MIME content type, as per RFC1521)
+        -->
+
+<!ENTITY % HTTP-Method "GET | POST"
+        -- as per HTTP specification, in progress
+        -->
+
+<!--========= DTD "Macros" =====================-->
+
+<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
+
+<!ENTITY % list " UL | OL | DIR | MENU " >
+
+
+<!--======= Character mnemonic entities =================-->
+
+<!ENTITY % ISOlat1 PUBLIC
+  "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
+%ISOlat1;
+
+<!ENTITY amp CDATA "&#38;"     -- ampersand          -->
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 50]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!ENTITY gt CDATA "&#62;"      -- greater than       -->
+<!ENTITY lt CDATA "&#60;"      -- less than          -->
+<!ENTITY quot CDATA "&#34;"    -- double quote       -->
+
+
+<!--========= SGML Document Access (SDA) Parameter Entities =====-->
+
+<!-- HTML 2.0 contains SGML Document Access (SDA) fixed attributes
+in support of easy transformation to the International Committee
+for Accessible Document Design (ICADD) DTD
+         "-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
+ICADD applications are designed to support usable access to
+structured information by print-impaired individuals through
+Braille, large print and voice synthesis.  For more information on
+SDA & ICADD:
+        - ISO 12083:1993, Annex A.8, Facilities for Braille,
+          large print and computer voice
+        - ICADD ListServ
+          <ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
+        - Usenet news group bit.listserv.easi
+        - Recording for the Blind, +1 800 221 4792
+-->
+
+<!ENTITY % SDAFORM  "SDAFORM  CDATA  #FIXED"
+          -- one to one mapping        -->
+<!ENTITY % SDARULE  "SDARULE  CDATA  #FIXED"
+          -- context-sensitive mapping -->
+<!ENTITY % SDAPREF  "SDAPREF  CDATA  #FIXED"
+          -- generated text prefix     -->
+<!ENTITY % SDASUFF  "SDASUFF  CDATA  #FIXED"
+          -- generated text suffix     -->
+<!ENTITY % SDASUSP  "SDASUSP  NAME   #FIXED"
+          -- suspend transform process -->
+
+
+<!--========== Text Markup =====================-->
+
+<![ %HTML.Highlighting [
+
+<!ENTITY % font " TT | B | I ">
+
+<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
+
+<!ENTITY % text "#PCDATA | A | IMG | BR | %phrase | %font">
+
+<!ELEMENT (%font;|%phrase) - - (%text)*>
+<!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
+        %SDAFORM; "Lit"
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 51]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        >
+<!ATTLIST ( B | STRONG )
+        %SDAFORM; "B"
+        >
+<!ATTLIST ( I | EM | CITE )
+        %SDAFORM; "It"
+        >
+
+<!-- <TT>       Typewriter text                         -->
+<!-- <B>        Bold text                               -->
+<!-- <I>        Italic text                             -->
+
+<!-- <EM>       Emphasized phrase                       -->
+<!-- <STRONG>   Strong emphasis                         -->
+<!-- <CODE>     Source code phrase                      -->
+<!-- <SAMP>     Sample text or characters               -->
+<!-- <KBD>      Keyboard phrase, e.g. user input        -->
+<!-- <VAR>      Variable phrase or substitutable        -->
+<!-- <CITE>     Name or title of cited work             -->
+
+<!ENTITY % pre.content "#PCDATA | A | HR | BR | %font | %phrase">
+
+]]>
+
+<!ENTITY % text "#PCDATA | A | IMG | BR">
+
+<!ELEMENT BR    - O EMPTY>
+<!ATTLIST BR
+        %SDAPREF; "&#RE;"
+        >
+
+<!-- <BR>       Line break      -->
+
+
+<!--========= Link Markup ======================-->
+
+<!ENTITY % linkType "NAMES">
+
+<!ENTITY % linkExtraAttributes
+        "REL %linkType #IMPLIED
+        REV %linkType #IMPLIED
+        URN CDATA #IMPLIED
+        TITLE CDATA #IMPLIED
+        METHODS NAMES #IMPLIED
+        ">
+
+<![ %HTML.Recommended [
+        <!ENTITY % A.content   "(%text)*"
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 52]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        -- <H1><a name="xxx">Heading</a></H1>
+                is preferred to
+           <a name="xxx"><H1>Heading</H1></a>
+        -->
+]]>
+
+<!ENTITY % A.content   "(%heading|%text)*">
+
+<!ELEMENT A     - - %A.content -(A)>
+<!ATTLIST A
+        HREF CDATA #IMPLIED
+        NAME CDATA #IMPLIED
+        %linkExtraAttributes;
+        %SDAPREF; "<Anchor: #AttList>"
+        >
+<!-- <A>                Anchor; source/destination of link      -->
+<!-- <A NAME="...">     Name of this anchor                     -->
+<!-- <A HREF="...">     Address of link destination             -->
+<!-- <A URN="...">      Permanent address of destination        -->
+<!-- <A REL=...>        Relationship to destination             -->
+<!-- <A REV=...>        Relationship of destination to this     -->
+<!-- <A TITLE="...">    Title of destination (advisory)         -->
+<!-- <A METHODS="...">  Operations on destination (advisory)    -->
+
+
+<!--========== Images ==========================-->
+
+<!ELEMENT IMG    - O EMPTY>
+<!ATTLIST IMG
+        SRC CDATA  #REQUIRED
+        ALT CDATA #IMPLIED
+        ALIGN (top|middle|bottom) #IMPLIED
+        ISMAP (ISMAP) #IMPLIED
+        %SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
+        >
+
+<!-- <IMG>              Image; icon, glyph or illustration      -->
+<!-- <IMG SRC="...">    Address of image object                 -->
+<!-- <IMG ALT="...">    Textual alternative                     -->
+<!-- <IMG ALIGN=...>    Position relative to text               -->
+<!-- <IMG ISMAP>        Each pixel can be a link                -->
+
+<!--========== Paragraphs=======================-->
+
+<!ELEMENT P     - O (%text)*>
+<!ATTLIST P
+        %SDAFORM; "Para"
+        >
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 53]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!-- <P>        Paragraph       -->
+
+
+<!--========== Headings, Titles, Sections ===============-->
+
+<!ELEMENT HR    - O EMPTY>
+<!ATTLIST HR
+        %SDAPREF; "&#RE;&#RE;"
+        >
+
+<!-- <HR>       Horizontal rule -->
+
+<!ELEMENT ( %heading )  - -  (%text;)*>
+<!ATTLIST H1
+        %SDAFORM; "H1"
+        >
+<!ATTLIST H2
+        %SDAFORM; "H2"
+        >
+<!ATTLIST H3
+        %SDAFORM; "H3"
+        >
+<!ATTLIST H4
+        %SDAFORM; "H4"
+        >
+<!ATTLIST H5
+        %SDAFORM; "H5"
+        >
+<!ATTLIST H6
+        %SDAFORM; "H6"
+        >
+
+<!-- <H1>       Heading, level 1 -->
+<!-- <H2>       Heading, level 2 -->
+<!-- <H3>       Heading, level 3 -->
+<!-- <H4>       Heading, level 4 -->
+<!-- <H5>       Heading, level 5 -->
+<!-- <H6>       Heading, level 6 -->
+
+
+<!--========== Text Flows ======================-->
+
+<![ %HTML.Forms [
+        <!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
+]]>
+
+<!ENTITY % block.forms "BLOCKQUOTE">
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 54]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<![ %HTML.Deprecated [
+        <!ENTITY % preformatted "PRE | XMP | LISTING">
+]]>
+
+<!ENTITY % preformatted "PRE">
+
+<!ENTITY % block "P | %list | DL
+        | %preformatted
+        | %block.forms">
+
+<!ENTITY % flow "(%text|%block)*">
+
+<!ENTITY % pre.content "#PCDATA | A | HR | BR">
+<!ELEMENT PRE - - (%pre.content)*>
+<!ATTLIST PRE
+        WIDTH NUMBER #implied
+        %SDAFORM; "Lit"
+        >
+
+<!-- <PRE>              Preformatted text               -->
+<!-- <PRE WIDTH=...>    Maximum characters per line     -->
+
+<![ %HTML.Deprecated [
+
+<!ENTITY % literal "CDATA"
+        -- historical, non-conforming parsing mode where
+           the only markup signal is the end tag
+           in full
+        -->
+
+<!ELEMENT (XMP|LISTING) - -  %literal>
+<!ATTLIST XMP
+        %SDAFORM; "Lit"
+        %SDAPREF; "Example:&#RE;"
+        >
+<!ATTLIST LISTING
+        %SDAFORM; "Lit"
+        %SDAPREF; "Listing:&#RE;"
+        >
+
+<!-- <XMP>              Example section         -->
+<!-- <LISTING>          Computer listing        -->
+
+<!ELEMENT PLAINTEXT - O %literal>
+<!-- <PLAINTEXT>        Plain text passage      -->
+
+<!ATTLIST PLAINTEXT
+        %SDAFORM; "Lit"
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 55]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        >
+]]>
+
+<!--========== Lists ==================-->
+
+<!ELEMENT DL    - -  (DT | DD)+>
+<!ATTLIST DL
+        COMPACT (COMPACT) #IMPLIED
+        %SDAFORM; "List"
+        %SDAPREF; "Definition List:"
+        >
+
+<!ELEMENT DT    - O (%text)*>
+<!ATTLIST DT
+        %SDAFORM; "Term"
+        >
+
+<!ELEMENT DD    - O %flow>
+<!ATTLIST DD
+        %SDAFORM; "LItem"
+        >
+
+<!-- <DL>               Definition list, or glossary    -->
+<!-- <DL COMPACT>       Compact style list              -->
+<!-- <DT>               Term in definition list         -->
+<!-- <DD>               Definition of term              -->
+
+<!ELEMENT (OL|UL) - -  (LI)+>
+<!ATTLIST OL
+        COMPACT (COMPACT) #IMPLIED
+        %SDAFORM; "List"
+        >
+<!ATTLIST UL
+        COMPACT (COMPACT) #IMPLIED
+        %SDAFORM; "List"
+        >
+<!-- <UL>               Unordered list                  -->
+<!-- <UL COMPACT>       Compact list style              -->
+<!-- <OL>               Ordered, or numbered list       -->
+<!-- <OL COMPACT>       Compact list style              -->
+
+
+<!ELEMENT (DIR|MENU) - -  (LI)+ -(%block)>
+<!ATTLIST DIR
+        COMPACT (COMPACT) #IMPLIED
+        %SDAFORM; "List"
+        %SDAPREF; "<LHead>Directory</LHead>"
+        >
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 56]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!ATTLIST MENU
+        COMPACT (COMPACT) #IMPLIED
+        %SDAFORM; "List"
+        %SDAPREF; "<LHead>Menu</LHead>"
+        >
+
+<!-- <DIR>              Directory list                  -->
+<!-- <DIR COMPACT>      Compact list style              -->
+<!-- <MENU>             Menu list                       -->
+<!-- <MENU COMPACT>     Compact list style              -->
+
+<!ELEMENT LI    - O %flow>
+<!ATTLIST LI
+        %SDAFORM; "LItem"
+        >
+
+<!-- <LI>               List item                       -->
+
+<!--========== Document Body ===================-->
+
+<![ %HTML.Recommended [
+        <!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
+        -- <h1>Heading</h1>
+           <p>Text ...
+                is preferred to
+           <h1>Heading</h1>
+           Text ...
+        -->
+]]>
+
+<!ENTITY % body.content "(%heading | %text | %block |
+                                 HR | ADDRESS)*">
+
+<!ELEMENT BODY O O  %body.content>
+
+<!-- <BODY>     Document body   -->
+
+<!ELEMENT BLOCKQUOTE - - %body.content>
+<!ATTLIST BLOCKQUOTE
+        %SDAFORM; "BQ"
+        >
+
+<!-- <BLOCKQUOTE>       Quoted passage  -->
+
+<!ELEMENT ADDRESS - - (%text|P)*>
+<!ATTLIST  ADDRESS
+        %SDAFORM; "Lit"
+        %SDAPREF; "Address:&#RE;"
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 57]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        >
+
+<!-- <ADDRESS>  Address, signature, or byline   -->
+
+
+<!--======= Forms ====================-->
+
+<![ %HTML.Forms [
+
+<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
+<!ATTLIST FORM
+        ACTION CDATA #IMPLIED
+        METHOD (%HTTP-Method) GET
+        ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
+        %SDAPREF; "<Para>Form:</Para>"
+        %SDASUFF; "<Para>Form End.</Para>"
+        >
+
+<!-- <FORM>                     Fill-out or data-entry form     -->
+<!-- <FORM ACTION="...">        Address for completed form      -->
+<!-- <FORM METHOD=...>          Method of submitting form       -->
+<!-- <FORM ENCTYPE="...">       Representation of form data     -->
+
+<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
+                        RADIO | SUBMIT | RESET |
+                        IMAGE | HIDDEN )">
+<!ELEMENT INPUT - O EMPTY>
+<!ATTLIST INPUT
+        TYPE %InputType TEXT
+        NAME CDATA #IMPLIED
+        VALUE CDATA #IMPLIED
+        SRC CDATA #IMPLIED
+        CHECKED (CHECKED) #IMPLIED
+        SIZE CDATA #IMPLIED
+        MAXLENGTH NUMBER #IMPLIED
+        ALIGN (top|middle|bottom) #IMPLIED
+        %SDAPREF; "Input: "
+        >
+
+<!-- <INPUT>                    Form input datum                -->
+<!-- <INPUT TYPE=...>           Type of input interaction       -->
+<!-- <INPUT NAME=...>           Name of form datum              -->
+<!-- <INPUT VALUE="...">        Default/initial/selected value  -->
+<!-- <INPUT SRC="...">          Address of image                -->
+<!-- <INPUT CHECKED>            Initial state is "on"           -->
+<!-- <INPUT SIZE=...>           Field size hint                 -->
+<!-- <INPUT MAXLENGTH=...>      Data length maximum             -->
+<!-- <INPUT ALIGN=...>          Image alignment                 -->
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 58]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
+<!ATTLIST SELECT
+        NAME CDATA #REQUIRED
+        SIZE NUMBER #IMPLIED
+        MULTIPLE (MULTIPLE) #IMPLIED
+        %SDAFORM; "List"
+        %SDAPREF;
+        "<LHead>Select #AttVal(Multiple)</LHead>"
+        >
+
+<!-- <SELECT>                   Selection of option(s)          -->
+<!-- <SELECT NAME=...>          Name of form datum              -->
+<!-- <SELECT SIZE=...>          Options displayed at a time     -->
+<!-- <SELECT MULTIPLE>          Multiple selections allowed     -->
+
+<!ELEMENT OPTION - O (#PCDATA)*>
+<!ATTLIST OPTION
+        SELECTED (SELECTED) #IMPLIED
+        VALUE CDATA #IMPLIED
+        %SDAFORM; "LItem"
+        %SDAPREF;
+        "Option: #AttVal(Value) #AttVal(Selected)"
+        >
+
+<!-- <OPTION>                   A selection option              -->
+<!-- <OPTION SELECTED>          Initial state                   -->
+<!-- <OPTION VALUE="...">       Form datum value for this option-->
+
+<!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
+<!ATTLIST TEXTAREA
+        NAME CDATA #REQUIRED
+        ROWS NUMBER #REQUIRED
+        COLS NUMBER #REQUIRED
+        %SDAFORM; "Para"
+        %SDAPREF; "Input Text -- #AttVal(Name): "
+        >
+
+<!-- <TEXTAREA>                 An area for text input          -->
+<!-- <TEXTAREA NAME=...>        Name of form datum              -->
+<!-- <TEXTAREA ROWS=...>        Height of area                  -->
+<!-- <TEXTAREA COLS=...>        Width of area                   -->
+
+]]>
+
+
+<!--======= Document Head ======================-->
+
+<![ %HTML.Recommended [
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 59]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        <!ENTITY % head.extra "">
+]]>
+<!ENTITY % head.extra "& NEXTID?">
+
+<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
+
+<!ELEMENT HEAD O O  (%head.content) +(META|LINK)>
+
+<!-- <HEAD>     Document head   -->
+
+<!ELEMENT TITLE - -  (#PCDATA)*  -(META|LINK)>
+<!ATTLIST TITLE
+        %SDAFORM; "Ti"    >
+
+<!-- <TITLE>    Title of document -->
+
+<!ELEMENT LINK - O EMPTY>
+<!ATTLIST LINK
+        HREF CDATA #REQUIRED
+        %linkExtraAttributes;
+        %SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>"    >
+
+<!-- <LINK>             Link from this document                 -->
+<!-- <LINK HREF="...">  Address of link destination             -->
+<!-- <LINK URN="...">   Lasting name of destination             -->
+<!-- <LINK REL=...>     Relationship to destination             -->
+<!-- <LINK REV=...>     Relationship of destination to this     -->
+<!-- <LINK TITLE="..."> Title of destination (advisory)         -->
+<!-- <LINK METHODS="..."> Operations allowed (advisory)         -->
+
+<!ELEMENT ISINDEX - O EMPTY>
+<!ATTLIST ISINDEX
+        %SDAPREF;
+   "<Para>[Document is indexed/searchable.]</Para>">
+
+<!-- <ISINDEX>          Document is a searchable index          -->
+
+<!ELEMENT BASE - O EMPTY>
+<!ATTLIST BASE
+        HREF CDATA #REQUIRED     >
+
+<!-- <BASE>             Base context document                   -->
+<!-- <BASE HREF="...">  Address for this document               -->
+
+<!ELEMENT NEXTID - O EMPTY>
+<!ATTLIST NEXTID
+        N CDATA #REQUIRED     >
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 60]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!-- <NEXTID>           Next ID to use for link name            -->
+<!-- <NEXTID N=...>     Next ID to use for link name            -->
+
+<!ELEMENT META - O EMPTY>
+<!ATTLIST META
+        HTTP-EQUIV  NAME    #IMPLIED
+        NAME        NAME    #IMPLIED
+        CONTENT     CDATA   #REQUIRED    >
+
+<!-- <META>                     Generic Meta-information        -->
+<!-- <META HTTP-EQUIV=...>      HTTP response header name       -->
+<!-- <META NAME=...>            Meta-information name           -->
+<!-- <META CONTENT="...">       Associated information          -->
+
+<!--======= Document Structure =================-->
+
+<![ %HTML.Deprecated [
+        <!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
+]]>
+<!ENTITY % html.content "HEAD, BODY">
+
+<!ELEMENT HTML O O  (%html.content)>
+<!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
+
+<!ATTLIST HTML
+        %version.attr;
+        %SDAFORM; "Book"
+        >
+
+<!-- <HTML>                     HTML Document   -->
+
+9.2. Strict HTML DTD
+
+   This document type declaration refers to the HTML DTD with the
+   `HTML.Recommended' entity defined as `INCLUDE' rather than IGNORE;
+   that is, it refers to the more structurally rigid definition of HTML.
+
+<!--    html-s.dtd
+
+        Document Type Definition for the HyperText Markup Language
+        with strict validation (HTML Strict DTD).
+
+        $Id: rfc1866.txt,v 1.1 2001-09-20 23:27:02 Pixel Exp $
+
+        Author: Daniel W. Connolly <connolly@w3.org>
+        See Also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
+-->
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 61]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!ENTITY % HTML.Version
+        "-//IETF//DTD HTML 2.0 Strict//EN"
+
+        -- Typical usage:
+
+            <!DOCTYPE HTML PUBLIC
+                "-//IETF//DTD HTML Strict//EN">
+            <html>
+            ...
+            </html>
+        --
+        >
+
+<!-- Feature Test Entities -->
+<!ENTITY % HTML.Recommended "INCLUDE">
+
+<!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN">
+%html;
+
+9.3. Level 1 HTML DTD
+
+   This document type declaration refers to the HTML DTD with the
+   `HTML.Forms' entity defined as `IGNORE' rather than `INCLUDE'.
+   Documents which contain <FORM> elements do not conform to this DTD,
+   and must use the level 2 DTD.
+
+<!--    html-1.dtd
+
+        Document Type Definition for the HyperText Markup Language
+        with Level 1 Extensions (HTML Level 1 DTD).
+
+        $Id: rfc1866.txt,v 1.1 2001-09-20 23:27:02 Pixel Exp $
+
+        Author: Daniel W. Connolly <connolly@w3.org>
+        See Also: http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
+
+-->
+
+<!ENTITY % HTML.Version
+        "-//IETF//DTD HTML 2.0 Level 1//EN"
+
+        -- Typical usage:
+
+            <!DOCTYPE HTML PUBLIC
+                "-//IETF//DTD HTML Level 1//EN">
+            <html>
+            ...
+            </html>
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 62]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+        --
+        >
+
+<!-- Feature Test Entities -->
+<!ENTITY % HTML.Forms "IGNORE">
+
+<!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN">
+%html;
+
+9.4. Strict Level 1 HTML DTD
+
+   This document type declaration refers to the level 1 HTML DTD with
+   the `HTML.Recommended' entity defined as `INCLUDE' rather than
+   IGNORE; that is, it refers to the more structurally rigid definition
+   of HTML.
+
+<!--    html-1s.dtd
+
+        Document Type Definition for the HyperText Markup Language
+        Struct Level 1
+
+        $Id: rfc1866.txt,v 1.1 2001-09-20 23:27:02 Pixel Exp $
+
+        Author: Daniel W. Connolly <connolly@w3.org>
+        See Also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
+-->
+
+<!ENTITY % HTML.Version
+        "-//IETF//DTD HTML 2.0 Strict Level 1//EN"
+
+        -- Typical usage:
+
+            <!DOCTYPE HTML PUBLIC
+                "-//IETF//DTD HTML Strict Level 1//EN">
+            <html>
+            ...
+            </html>
+        --
+        >
+
+<!-- Feature Test Entities -->
+
+
+<!ENTITY % HTML.Recommended "INCLUDE">
+
+<!ENTITY % html-1 PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN">
+%html-1;
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 63]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+9.5. SGML Declaration for HTML
+
+   This is the SGML Declaration for HyperText Markup Language.
+
+<!SGML  "ISO 8879:1986"
+--
+        SGML Declaration for HyperText Markup Language (HTML).
+
+--
+
+CHARSET
+         BASESET  "ISO 646:1983//CHARSET
+                   International Reference Version
+                   (IRV)//ESC 2/5 4/0"
+         DESCSET  0   9   UNUSED
+                  9   2   9
+                  11  2   UNUSED
+                  13  1   13
+                  14  18  UNUSED
+                  32  95  32
+                  127 1   UNUSED
+     BASESET   "ISO Registration Number 100//CHARSET
+                ECMA-94 Right Part of
+                Latin Alphabet Nr. 1//ESC 2/13 4/1"
+
+         DESCSET  128  32   UNUSED
+                  160  96    32
+
+CAPACITY        SGMLREF
+                TOTALCAP        150000
+                GRPCAP          150000
+                ENTCAP          150000
+
+SCOPE    DOCUMENT
+SYNTAX
+         SHUNCHAR CONTROLS 0 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 127
+         BASESET  "ISO 646:1983//CHARSET
+                   International Reference Version
+                   (IRV)//ESC 2/5 4/0"
+         DESCSET  0 128 0
+         FUNCTION
+                  RE          13
+                  RS          10
+                  SPACE       32
+                  TAB SEPCHAR  9
+         NAMING   LCNMSTRT ""
+                  UCNMSTRT ""
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 64]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+                  LCNMCHAR ".-"
+                  UCNMCHAR ".-"
+                  NAMECASE GENERAL YES
+                           ENTITY  NO
+         DELIM    GENERAL  SGMLREF
+                  SHORTREF SGMLREF
+         NAMES    SGMLREF
+         QUANTITY SGMLREF
+                  ATTSPLEN 2100
+                  LITLEN   1024
+                  NAMELEN  72    -- somewhat arbitrary; taken from
+                                internet line length conventions --
+                  PILEN    1024
+                  TAGLVL   100
+                  TAGLEN   2100
+                  GRPGTCNT 150
+                  GRPCNT   64
+
+FEATURES
+  MINIMIZE
+    DATATAG  NO
+    OMITTAG  YES
+    RANK     NO
+    SHORTTAG YES
+  LINK
+    SIMPLE   NO
+    IMPLICIT NO
+    EXPLICIT NO
+  OTHER
+    CONCUR   NO
+    SUBDOC   NO
+    FORMAL   YES
+  APPINFO    "SDA"  -- conforming SGML Document Access application
+                    --
+>
+<!--
+        $Id: rfc1866.txt,v 1.1 2001-09-20 23:27:02 Pixel Exp $
+
+        Author: Daniel W. Connolly <connolly@w3.org>
+
+        See also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
+ -->
+
+9.6. Sample SGML Open Entity Catalog for HTML
+
+   The SGML standard describes an "entity manager" as the portion or
+   component of an SGML system that maps SGML entities into the actual
+   storage model (e.g., the file system). The standard itself does not
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 65]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   define a particular mapping methodology or notation.
+
+   To assist the interoperability among various SGML tools and systems,
+   the SGML Open consortium has passed a technical resolution that
+   defines a format for an application-independent entity catalog that
+   maps external identifiers and/or entity names to file names.
+
+   Each entry in the catalog associates a storage object identifier
+   (such as a file name) with information about the external entity that
+   appears in the SGML document. In addition to entries that associate
+   public identifiers, a catalog entry can associate an entity name with
+   a storage object identifier. For example, the following are possible
+   catalog entries:
+
+        -- catalog: SGML Open style entity catalog for HTML --
+        -- $Id: rfc1866.txt,v 1.1 2001-09-20 23:27:02 Pixel Exp $ --
+
+        -- Ways to refer to Level 2: most general to most specific --
+PUBLIC  "-//IETF//DTD HTML//EN"                 html.dtd
+PUBLIC  "-//IETF//DTD HTML 2.0//EN"             html.dtd
+PUBLIC  "-//IETF//DTD HTML Level 2//EN"         html.dtd
+PUBLIC  "-//IETF//DTD HTML 2.0 Level 2//EN"     html.dtd
+
+        -- Ways to refer to Level 1: most general to most specific --
+PUBLIC  "-//IETF//DTD HTML Level 1//EN"         html-1.dtd
+PUBLIC  "-//IETF//DTD HTML 2.0 Level 1//EN"     html-1.dtd
+
+        -- Ways to refer to
+                 Strict Level 2: most general to most specific --
+PUBLIC  "-//IETF//DTD HTML Strict//EN"                  html-s.dtd
+PUBLIC  "-//IETF//DTD HTML 2.0 Strict//EN"              html-s.dtd
+PUBLIC  "-//IETF//DTD HTML Strict Level 2//EN"          html-s.dtd
+PUBLIC  "-//IETF//DTD HTML 2.0 Strict Level 2//EN"      html-s.dtd
+
+        -- Ways to refer to
+                 Strict Level 1: most general to most specific --
+PUBLIC  "-//IETF//DTD HTML Strict Level 1//EN"          html-1s.dtd
+PUBLIC  "-//IETF//DTD HTML 2.0 Strict Level 1//EN"      html-1s.dtd
+
+        -- ISO latin 1 entity set for HTML --
+PUBLIC  "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML" ISOlat1\
+sgml
+
+9.7. Character Entity Sets
+
+   The HTML DTD defines the following entities. They represent
+   particular graphic characters which have special meanings in places
+   in the markup, or may not be part of the character set available to
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 66]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+   the writer.
+
+9.7.1. Numeric and Special Graphic Entity Set
+
+   The following table lists each of the characters included from the
+   Numeric and Special Graphic entity set, along with its name, syntax
+   for use, and description. This list is derived from `ISO Standard
+   8879:1986//ENTITIES Numeric and Special Graphic//EN'.  However, HTML
+   does not include for the entire entity set -- only the entities
+   listed below are included.
+
+    GLYPH   NAME    SYNTAX  DESCRIPTION
+    <       lt      &lt;    Less than sign
+    >       gt      &gt;    Greater than signn
+    &       amp     &amp;   Ampersand
+    "       quot    &quot;  Double quote sign
+
+9.7.2. ISO Latin 1 Character Entity Set
+
+   The following public text lists each of the characters specified in
+   the Added Latin 1 entity set, along with its name, syntax for use,
+   and description. This list is derived from ISO Standard
+   8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire
+   entity set.
+
+<!-- (C) International Organization for Standardization 1986
+     Permission to copy in any form is granted for use with
+     conforming SGML systems and applications as defined in
+     ISO 8879, provided this notice is included in all copies.
+-->
+<!-- Character entity set. Typical invocation:
+     <!ENTITY % ISOlat1 PUBLIC
+       "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
+     %ISOlat1;
+-->
+<!--    Modified for use in HTML
+        $Id: rfc1866.txt,v 1.1 2001-09-20 23:27:02 Pixel Exp $ -->
+<!ENTITY AElig  CDATA "&#198;" -- capital AE diphthong (ligature) -->
+<!ENTITY Aacute CDATA "&#193;" -- capital A, acute accent -->
+<!ENTITY Acirc  CDATA "&#194;" -- capital A, circumflex accent -->
+<!ENTITY Agrave CDATA "&#192;" -- capital A, grave accent -->
+<!ENTITY Aring  CDATA "&#197;" -- capital A, ring -->
+<!ENTITY Atilde CDATA "&#195;" -- capital A, tilde -->
+<!ENTITY Auml   CDATA "&#196;" -- capital A, dieresis or umlaut mark -->
+<!ENTITY Ccedil CDATA "&#199;" -- capital C, cedilla -->
+<!ENTITY ETH    CDATA "&#208;" -- capital Eth, Icelandic -->
+<!ENTITY Eacute CDATA "&#201;" -- capital E, acute accent -->
+<!ENTITY Ecirc  CDATA "&#202;" -- capital E, circumflex accent -->
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 67]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!ENTITY Egrave CDATA "&#200;" -- capital E, grave accent -->
+<!ENTITY Euml   CDATA "&#203;" -- capital E, dieresis or umlaut mark -->
+<!ENTITY Iacute CDATA "&#205;" -- capital I, acute accent -->
+<!ENTITY Icirc  CDATA "&#206;" -- capital I, circumflex accent -->
+<!ENTITY Igrave CDATA "&#204;" -- capital I, grave accent -->
+<!ENTITY Iuml   CDATA "&#207;" -- capital I, dieresis or umlaut mark -->
+<!ENTITY Ntilde CDATA "&#209;" -- capital N, tilde -->
+<!ENTITY Oacute CDATA "&#211;" -- capital O, acute accent -->
+<!ENTITY Ocirc  CDATA "&#212;" -- capital O, circumflex accent -->
+<!ENTITY Ograve CDATA "&#210;" -- capital O, grave accent -->
+<!ENTITY Oslash CDATA "&#216;" -- capital O, slash -->
+<!ENTITY Otilde CDATA "&#213;" -- capital O, tilde -->
+<!ENTITY Ouml   CDATA "&#214;" -- capital O, dieresis or umlaut mark -->
+<!ENTITY THORN  CDATA "&#222;" -- capital THORN, Icelandic -->
+<!ENTITY Uacute CDATA "&#218;" -- capital U, acute accent -->
+<!ENTITY Ucirc  CDATA "&#219;" -- capital U, circumflex accent -->
+<!ENTITY Ugrave CDATA "&#217;" -- capital U, grave accent -->
+<!ENTITY Uuml   CDATA "&#220;" -- capital U, dieresis or umlaut mark -->
+<!ENTITY Yacute CDATA "&#221;" -- capital Y, acute accent -->
+<!ENTITY aacute CDATA "&#225;" -- small a, acute accent -->
+<!ENTITY acirc  CDATA "&#226;" -- small a, circumflex accent -->
+<!ENTITY aelig  CDATA "&#230;" -- small ae diphthong (ligature) -->
+<!ENTITY agrave CDATA "&#224;" -- small a, grave accent -->
+<!ENTITY aring  CDATA "&#229;" -- small a, ring -->
+<!ENTITY atilde CDATA "&#227;" -- small a, tilde -->
+<!ENTITY auml   CDATA "&#228;" -- small a, dieresis or umlaut mark -->
+<!ENTITY ccedil CDATA "&#231;" -- small c, cedilla -->
+<!ENTITY eacute CDATA "&#233;" -- small e, acute accent -->
+<!ENTITY ecirc  CDATA "&#234;" -- small e, circumflex accent -->
+<!ENTITY egrave CDATA "&#232;" -- small e, grave accent -->
+<!ENTITY eth    CDATA "&#240;" -- small eth, Icelandic -->
+<!ENTITY euml   CDATA "&#235;" -- small e, dieresis or umlaut mark -->
+<!ENTITY iacute CDATA "&#237;" -- small i, acute accent -->
+<!ENTITY icirc  CDATA "&#238;" -- small i, circumflex accent -->
+<!ENTITY igrave CDATA "&#236;" -- small i, grave accent -->
+<!ENTITY iuml   CDATA "&#239;" -- small i, dieresis or umlaut mark -->
+<!ENTITY ntilde CDATA "&#241;" -- small n, tilde -->
+<!ENTITY oacute CDATA "&#243;" -- small o, acute accent -->
+<!ENTITY ocirc  CDATA "&#244;" -- small o, circumflex accent -->
+<!ENTITY ograve CDATA "&#242;" -- small o, grave accent -->
+<!ENTITY oslash CDATA "&#248;" -- small o, slash -->
+<!ENTITY otilde CDATA "&#245;" -- small o, tilde -->
+<!ENTITY ouml   CDATA "&#246;" -- small o, dieresis or umlaut mark -->
+<!ENTITY szlig  CDATA "&#223;" -- small sharp s, German (sz ligature)->
+<!ENTITY thorn  CDATA "&#254;" -- small thorn, Icelandic -->
+<!ENTITY uacute CDATA "&#250;" -- small u, acute accent -->
+<!ENTITY ucirc  CDATA "&#251;" -- small u, circumflex accent -->
+<!ENTITY ugrave CDATA "&#249;" -- small u, grave accent -->
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 68]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+<!ENTITY uuml   CDATA "&#252;" -- small u, dieresis or umlaut mark -->
+<!ENTITY yacute CDATA "&#253;" -- small y, acute accent -->
+<!ENTITY yuml   CDATA "&#255;" -- small y, dieresis or umlaut mark -->
+
+10. Security Considerations
+
+   Anchors, embedded images, and all other elements which contain URIs
+   as parameters may cause the URI to be dereferenced in response to
+   user input. In this case, the security considerations of [URL] apply.
+
+   The widely deployed methods for submitting forms requests -- HTTP and
+   SMTP -- provide little assurance of confidentiality.  Information
+   providers who request sensitive information via forms -- especially
+   by way of the `PASSWORD' type input field (see 8.1.2, "Input Field:
+   INPUT") -- should be aware and make their users aware of the lack of
+   confidentiality.
+
+11. References
+
+    [URI]
+            Berners-Lee, T., "Universal Resource Identifiers in WWW:
+            A Unifying Syntax for the Expression of Names and
+            Addresses of Objects on the Network as used in the
+            World- Wide Web",  RFC 1630, CERN, June 1994.
+            <URL:ftp://ds.internic.net/rfc/rfc1630.txt>
+
+    [URL]
+            Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+            Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
+            University of Minnesota, December 1994.
+            <URL:ftp://ds.internic.net/rfc/rfc1738.txt>
+
+    [HTTP]
+            Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen,
+            "Hypertext Transfer Protocol - HTTP/1.0", Work in
+            Progress, MIT, UC Irvine, CERN, March 1995.
+
+    [MIME]
+            Borenstein, N., and N. Freed. "MIME (Multipurpose
+            Internet Mail Extensions) Part One: Mechanisms for
+            Specifying and Describing the Format of Internet Message
+            Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
+            <URL:ftp://ds.internic.net/rfc/rfc1521.txt>
+
+    [RELURL]
+            Fielding, R., "Relative Uniform Resource Locators", RFC
+            1808, June 1995
+            <URL:ftp://ds.internic.net/rfc/rfc1808.txt>
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 69]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    [GOLD90]
+            Goldfarb, C., "The SGML Handbook", Y. Rubinsky, Ed.,
+            Oxford University Press, 1990.
+
+    [DEXTER]
+            Frank Halasz and Mayer Schwartz, "The Dexter Hypertext
+            Reference Model", Communications of the ACM, pp.
+            30-39, vol. 37 no. 2, Feb 1994.
+
+    [IMEDIA]
+            Postel, J., "Media Type Registration Procedure",
+            RFC 1590, USC/Information Sciences Institute, March 1994.
+            <URL:ftp://ds.internic.net/rfc/rfc1590.txt>
+
+    [IANA]
+            Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+            RFC 1700, USC/Information Sciecnes Institute, October
+            1994.  <URL:ftp://ds.internic.net/rfc/rfc1700.txt>
+
+    [SQ91]
+            SoftQuad. "The SGML Primer", 3rd ed., SoftQuad Inc.,
+            1991. <URL:http://www.sq.com/>
+
+    [ISO-646]
+            ISO/IEC 646:1991 Information technology -- ISO 7-bit
+            coded character set for information interchange
+            <URL:http://www.iso.ch/cate/d4777.html>
+
+    [ISO-10646]
+            ISO/IEC 10646-1:1993 Information technology -- Universal
+            Multiple-Octet Coded Character Set (UCS) -- Part 1:
+            Architecture and Basic Multilingual Plane
+            <URL:http://www.iso.ch/cate/d18741.html>
+
+    [ISO-8859-1]
+            ISO 8859. International Standard -- Information
+            Processing -- 8-bit Single-Byte Coded Graphic Character
+            Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.
+            <URL:http://www.iso.ch/cate/d16338.html>
+
+    [SGML]
+            ISO 8879. Information Processing -- Text and Office
+            Systems - Standard Generalized Markup Language (SGML),
+            1986. <URL:http://www.iso.ch/cate/d16387.html>
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 70]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+12. Acknowledgments
+
+   The HTML document type was designed by Tim Berners-Lee at CERN as
+   part of the 1990 World Wide Web project. In 1992, Dan Connolly wrote
+   the HTML Document Type Definition (DTD) and a brief HTML
+   specification.
+
+   Since 1993, a wide variety of Internet participants have contributed
+   to the evolution of HTML, which has included the addition of in-line
+   images introduced by the NCSA Mosaic software for WWW. Dave Raggett
+   played an important role in deriving the forms material from the
+   HTML+ specification.
+
+   Dan Connolly and Karen Olson Muldrow rewrote the HTML Specification
+   in 1994. The document was then edited by the HTML working group as a
+   whole, with updates being made by Eric Schieler, Mike Knezovich, and
+   Eric W. Sink at Spyglass, Inc.  Finally, Roy Fielding restructured
+   the entire draft into its current form.
+
+   Special thanks to the many active participants in the HTML working
+   group, too numerous to list individually, without whom there would be
+   no standards process and no standard. That this document approaches
+   its objective of carefully converging a description of current
+   practice and formalization of HTML's relationship to SGML is a
+   tribute to their effort.
+
+12.1. Authors' Addresses
+
+   Tim Berners-Lee
+   Director, W3 Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, U.S.A.
+
+   Phone: +1 (617) 253 9670
+   Fax: +1 (617) 258 8682
+   EMail: timbl@w3.org
+
+
+   Daniel W. Connolly
+   Research Technical Staff, W3 Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, U.S.A.
+
+   Phone: +1 (617) 258 8682
+   EMail: connolly@w3.org
+   URI: http://www.w3.org/hypertext/WWW/People/Connolly/
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 71]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+13. The HTML Coded Character Set
+
+   This list details the code positions and characters of the HTML
+   document character set, specified in 9.5, "SGML Declaration for
+   HTML". This coded character set is based on [ISO-8859-1].
+
+    REFERENCE       DESCRIPTION
+    --------------  -----------
+    &#00; - &#08;   Unused
+    &#09;           Horizontal tab
+    &#10;           Line feed
+    &#11; - &#12;   Unused
+    &#13;           Carriage Return
+    &#14; - &#31;   Unused
+    &#32;           Space
+    &#33;           Exclamation mark
+    &#34;           Quotation mark
+    &#35;           Number sign
+    &#36;           Dollar sign
+    &#37;           Percent sign
+    &#38;           Ampersand
+    &#39;           Apostrophe
+    &#40;           Left parenthesis
+    &#41;           Right parenthesis
+    &#42;           Asterisk
+    &#43;           Plus sign
+    &#44;           Comma
+    &#45;           Hyphen
+    &#46;           Period (fullstop)
+    &#47;           Solidus (slash)
+    &#48; - &#57;   Digits 0-9
+    &#58;           Colon
+    &#59;           Semi-colon
+    &#60;           Less than
+    &#61;           Equals sign
+    &#62;           Greater than
+    &#63;           Question mark
+    &#64;           Commercial at
+    &#65; - &#90;   Letters A-Z
+    &#91;           Left square bracket
+    &#92;           Reverse solidus (backslash)
+    &#93;           Right square bracket
+    &#94;           Caret
+    &#95;           Horizontal bar (underscore)
+    &#96;           Acute accent
+    &#97; - &#122;  Letters a-z
+    &#123;          Left curly brace
+    &#124;          Vertical bar
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 72]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    &#125;          Right curly brace
+    &#126;          Tilde
+    &#127; - &#159; Unused
+    &#160;          Non-breaking Space
+    &#161;          Inverted exclamation
+    &#162;          Cent sign
+    &#163;          Pound sterling
+    &#164;          General currency sign
+    &#165;          Yen sign
+    &#166;          Broken vertical bar
+    &#167;          Section sign
+    &#168;          Umlaut (dieresis)
+    &#169;          Copyright
+    &#170;          Feminine ordinal
+    &#171;          Left angle quote, guillemotleft
+    &#172;          Not sign
+    &#173;          Soft hyphen
+    &#174;          Registered trademark
+    &#175;          Macron accent
+    &#176;          Degree sign
+    &#177;          Plus or minus
+    &#178;          Superscript two
+    &#179;          Superscript three
+    &#180;          Acute accent
+    &#181;          Micro sign
+    &#182;          Paragraph sign
+    &#183;          Middle dot
+    &#184;          Cedilla
+    &#185;          Superscript one
+    &#186;          Masculine ordinal
+    &#187;          Right angle quote, guillemotright
+    &#188;          Fraction one-fourth
+    &#189;          Fraction one-half
+    &#190;          Fraction three-fourths
+    &#191;          Inverted question mark
+    &#192;          Capital A, grave accent
+    &#193;          Capital A, acute accent
+    &#194;          Capital A, circumflex accent
+    &#195;          Capital A, tilde
+    &#196;          Capital A, dieresis or umlaut mark
+    &#197;          Capital A, ring
+    &#198;          Capital AE dipthong (ligature)
+    &#199;          Capital C, cedilla
+    &#200;          Capital E, grave accent
+    &#201;          Capital E, acute accent
+    &#202;          Capital E, circumflex accent
+    &#203;          Capital E, dieresis or umlaut mark
+    &#204;          Capital I, grave accent
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 73]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    &#205;          Capital I, acute accent
+    &#206;          Capital I, circumflex accent
+    &#207;          Capital I, dieresis or umlaut mark
+    &#208;          Capital Eth, Icelandic
+    &#209;          Capital N, tilde
+    &#210;          Capital O, grave accent
+    &#211;          Capital O, acute accent
+    &#212;          Capital O, circumflex accent
+    &#213;          Capital O, tilde
+    &#214;          Capital O, dieresis or umlaut mark
+    &#215;          Multiply sign
+    &#216;          Capital O, slash
+    &#217;          Capital U, grave accent
+    &#218;          Capital U, acute accent
+    &#219;          Capital U, circumflex accent
+    &#220;          Capital U, dieresis or umlaut mark
+    &#221;          Capital Y, acute accent
+    &#222;          Capital THORN, Icelandic
+    &#223;          Small sharp s, German (sz ligature)
+    &#224;          Small a, grave accent
+    &#225;          Small a, acute accent
+    &#226;          Small a, circumflex accent
+    &#227;          Small a, tilde
+    &#228;          Small a, dieresis or umlaut mark
+    &#229;          Small a, ring
+    &#230;          Small ae dipthong (ligature)
+    &#231;          Small c, cedilla
+    &#232;          Small e, grave accent
+    &#233;          Small e, acute accent
+    &#234;          Small e, circumflex accent
+    &#235;          Small e, dieresis or umlaut mark
+    &#236;          Small i, grave accent
+    &#237;          Small i, acute accent
+    &#238;          Small i, circumflex accent
+    &#239;          Small i, dieresis or umlaut mark
+    &#240;          Small eth, Icelandic
+    &#241;          Small n, tilde
+    &#242;          Small o, grave accent
+    &#243;          Small o, acute accent
+    &#244;          Small o, circumflex accent
+    &#245;          Small o, tilde
+    &#246;          Small o, dieresis or umlaut mark
+    &#247;          Division sign
+    &#248;          Small o, slash
+    &#249;          Small u, grave accent
+    &#250;          Small u, acute accent
+    &#251;          Small u, circumflex accent
+    &#252;          Small u, dieresis or umlaut mark
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 74]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    &#253;          Small y, acute accent
+    &#254;          Small thorn, Icelandic
+    &#255;          Small y, dieresis or umlaut mark
+
+14. Proposed Entities
+
+   The HTML DTD references the "Added Latin 1" entity set, which only
+   supplies named entities for a subset of the non-ASCII characters in
+   [ISO-8859-1], namely the accented characters. The following entities
+   should be supported so that all ISO 8859-1 characters may only be
+   referenced symbolically. The names for these entities are taken from
+   the appendixes of [SGML].
+
+    <!ENTITY nbsp   CDATA "&#160;" -- no-break space -->
+    <!ENTITY iexcl  CDATA "&#161;" -- inverted exclamation mark -->
+    <!ENTITY cent   CDATA "&#162;" -- cent sign -->
+    <!ENTITY pound  CDATA "&#163;" -- pound sterling sign -->
+    <!ENTITY curren CDATA "&#164;" -- general currency sign -->
+    <!ENTITY yen    CDATA "&#165;" -- yen sign -->
+    <!ENTITY brvbar CDATA "&#166;" -- broken (vertical) bar -->
+    <!ENTITY sect   CDATA "&#167;" -- section sign -->
+    <!ENTITY uml    CDATA "&#168;" -- umlaut (dieresis) -->
+    <!ENTITY copy   CDATA "&#169;" -- copyright sign -->
+    <!ENTITY ordf   CDATA "&#170;" -- ordinal indicator, feminine -->
+    <!ENTITY laquo  CDATA "&#171;" -- angle quotation mark, left -->
+    <!ENTITY not    CDATA "&#172;" -- not sign -->
+    <!ENTITY shy    CDATA "&#173;" -- soft hyphen -->
+    <!ENTITY reg    CDATA "&#174;" -- registered sign -->
+    <!ENTITY macr   CDATA "&#175;" -- macron -->
+    <!ENTITY deg    CDATA "&#176;" -- degree sign -->
+    <!ENTITY plusmn CDATA "&#177;" -- plus-or-minus sign -->
+    <!ENTITY sup2   CDATA "&#178;" -- superscript two -->
+    <!ENTITY sup3   CDATA "&#179;" -- superscript three -->
+    <!ENTITY acute  CDATA "&#180;" -- acute accent -->
+    <!ENTITY micro  CDATA "&#181;" -- micro sign -->
+    <!ENTITY para   CDATA "&#182;" -- pilcrow (paragraph sign) -->
+    <!ENTITY middot CDATA "&#183;" -- middle dot -->
+    <!ENTITY cedil  CDATA "&#184;" -- cedilla -->
+    <!ENTITY sup1   CDATA "&#185;" -- superscript one -->
+    <!ENTITY ordm   CDATA "&#186;" -- ordinal indicator, masculine -->
+    <!ENTITY raquo  CDATA "&#187;" -- angle quotation mark, right -->
+    <!ENTITY frac14 CDATA "&#188;" -- fraction one-quarter -->
+    <!ENTITY frac12 CDATA "&#189;" -- fraction one-half -->
+    <!ENTITY frac34 CDATA "&#190;" -- fraction three-quarters -->
+    <!ENTITY iquest CDATA "&#191;" -- inverted question mark -->
+    <!ENTITY Agrave CDATA "&#192;" -- capital A, grave accent -->
+    <!ENTITY Aacute CDATA "&#193;" -- capital A, acute accent -->
+    <!ENTITY Acirc  CDATA "&#194;" -- capital A, circumflex accent -->
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 75]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    <!ENTITY Atilde CDATA "&#195;" -- capital A, tilde -->
+    <!ENTITY Auml   CDATA "&#196;" -- capital A, dieresis or umlaut mark -->
+    <!ENTITY Aring  CDATA "&#197;" -- capital A, ring -->
+    <!ENTITY AElig  CDATA "&#198;" -- capital AE diphthong (ligature) -->
+    <!ENTITY Ccedil CDATA "&#199;" -- capital C, cedilla -->
+    <!ENTITY Egrave CDATA "&#200;" -- capital E, grave accent -->
+    <!ENTITY Eacute CDATA "&#201;" -- capital E, acute accent -->
+    <!ENTITY Ecirc  CDATA "&#202;" -- capital E, circumflex accent -->
+    <!ENTITY Euml   CDATA "&#203;" -- capital E, dieresis or umlaut mark -->
+    <!ENTITY Igrave CDATA "&#204;" -- capital I, grave accent -->
+    <!ENTITY Iacute CDATA "&#205;" -- capital I, acute accent -->
+    <!ENTITY Icirc  CDATA "&#206;" -- capital I, circumflex accent -->
+    <!ENTITY Iuml   CDATA "&#207;" -- capital I, dieresis or umlaut mark -->
+    <!ENTITY ETH    CDATA "&#208;" -- capital Eth, Icelandic -->
+    <!ENTITY Ntilde CDATA "&#209;" -- capital N, tilde -->
+    <!ENTITY Ograve CDATA "&#210;" -- capital O, grave accent -->
+    <!ENTITY Oacute CDATA "&#211;" -- capital O, acute accent -->
+    <!ENTITY Ocirc  CDATA "&#212;" -- capital O, circumflex accent -->
+    <!ENTITY Otilde CDATA "&#213;" -- capital O, tilde -->
+    <!ENTITY Ouml   CDATA "&#214;" -- capital O, dieresis or umlaut mark -->
+    <!ENTITY times  CDATA "&#215;" -- multiply sign -->
+    <!ENTITY Oslash CDATA "&#216;" -- capital O, slash -->
+    <!ENTITY Ugrave CDATA "&#217;" -- capital U, grave accent -->
+    <!ENTITY Uacute CDATA "&#218;" -- capital U, acute accent -->
+    <!ENTITY Ucirc  CDATA "&#219;" -- capital U, circumflex accent -->
+    <!ENTITY Uuml   CDATA "&#220;" -- capital U, dieresis or umlaut mark -->
+    <!ENTITY Yacute CDATA "&#221;" -- capital Y, acute accent -->
+    <!ENTITY THORN  CDATA "&#222;" -- capital THORN, Icelandic -->
+    <!ENTITY szlig  CDATA "&#223;" -- small sharp s, German (sz ligature) -->
+    <!ENTITY agrave CDATA "&#224;" -- small a, grave accent -->
+    <!ENTITY aacute CDATA "&#225;" -- small a, acute accent -->
+    <!ENTITY acirc  CDATA "&#226;" -- small a, circumflex accent -->
+    <!ENTITY atilde CDATA "&#227;" -- small a, tilde -->
+    <!ENTITY auml   CDATA "&#228;" -- small a, dieresis or umlaut mark -->
+    <!ENTITY aring  CDATA "&#229;" -- small a, ring -->
+    <!ENTITY aelig  CDATA "&#230;" -- small ae diphthong (ligature) -->
+    <!ENTITY ccedil CDATA "&#231;" -- small c, cedilla -->
+    <!ENTITY egrave CDATA "&#232;" -- small e, grave accent -->
+    <!ENTITY eacute CDATA "&#233;" -- small e, acute accent -->
+    <!ENTITY ecirc  CDATA "&#234;" -- small e, circumflex accent -->
+    <!ENTITY euml   CDATA "&#235;" -- small e, dieresis or umlaut mark -->
+    <!ENTITY igrave CDATA "&#236;" -- small i, grave accent -->
+    <!ENTITY iacute CDATA "&#237;" -- small i, acute accent -->
+    <!ENTITY icirc  CDATA "&#238;" -- small i, circumflex accent -->
+    <!ENTITY iuml   CDATA "&#239;" -- small i, dieresis or umlaut mark -->
+    <!ENTITY eth    CDATA "&#240;" -- small eth, Icelandic -->
+    <!ENTITY ntilde CDATA "&#241;" -- small n, tilde -->
+    <!ENTITY ograve CDATA "&#242;" -- small o, grave accent -->
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 76]
+
+RFC 1866            Hypertext Markup Language - 2.0        November 1995
+
+
+    <!ENTITY oacute CDATA "&#243;" -- small o, acute accent -->
+    <!ENTITY ocirc  CDATA "&#244;" -- small o, circumflex accent -->
+    <!ENTITY otilde CDATA "&#245;" -- small o, tilde -->
+    <!ENTITY ouml   CDATA "&#246;" -- small o, dieresis or umlaut mark -->
+    <!ENTITY divide CDATA "&#247;" -- divide sign -->
+    <!ENTITY oslash CDATA "&#248;" -- small o, slash -->
+    <!ENTITY ugrave CDATA "&#249;" -- small u, grave accent -->
+    <!ENTITY uacute CDATA "&#250;" -- small u, acute accent -->
+    <!ENTITY ucirc  CDATA "&#251;" -- small u, circumflex accent -->
+    <!ENTITY uuml   CDATA "&#252;" -- small u, dieresis or umlaut mark -->
+    <!ENTITY yacute CDATA "&#253;" -- small y, acute accent -->
+    <!ENTITY thorn  CDATA "&#254;" -- small thorn, Icelandic -->
+    <!ENTITY yuml   CDATA "&#255;" -- small y, dieresis or umlaut mark -->
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee & Connolly      Standards Track                    [Page 77]
+
diff --git a/doc/rfc2616.txt b/doc/rfc2616.txt
new file mode 100644
index 0000000..45d7d08
--- /dev/null
+++ b/doc/rfc2616.txt
@@ -0,0 +1,9859 @@
+
+
+
+
+
+
+Network Working Group                                      R. Fielding
+Request for Comments: 2616                                   UC Irvine
+Obsoletes: 2068                                              J. Gettys
+Category: Standards Track                                   Compaq/W3C
+                                                              J. Mogul
+                                                                Compaq
+                                                            H. Frystyk
+                                                               W3C/MIT
+                                                           L. Masinter
+                                                                 Xerox
+                                                              P. Leach
+                                                             Microsoft
+                                                        T. Berners-Lee
+                                                               W3C/MIT
+                                                             June 1999
+
+
+                Hypertext Transfer Protocol -- HTTP/1.1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Hypertext Transfer Protocol (HTTP) is an application-level
+   protocol for distributed, collaborative, hypermedia information
+   systems. It is a generic, stateless, protocol which can be used for
+   many tasks beyond its use for hypertext, such as name servers and
+   distributed object management systems, through extension of its
+   request methods, error codes and headers [47]. A feature of HTTP is
+   the typing and negotiation of data representation, allowing systems
+   to be built independently of the data being transferred.
+
+   HTTP has been in use by the World-Wide Web global information
+   initiative since 1990. This specification defines the protocol
+   referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
+
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 1]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+Table of Contents
+
+   1   Introduction ...................................................7
+   1.1    Purpose......................................................7
+   1.2   Requirements .................................................8
+   1.3   Terminology ..................................................8
+   1.4   Overall Operation ...........................................12
+   2   Notational Conventions and Generic Grammar ....................14
+   2.1   Augmented BNF ...............................................14
+   2.2   Basic Rules .................................................15
+   3   Protocol Parameters ...........................................17
+   3.1   HTTP Version ................................................17
+   3.2   Uniform Resource Identifiers ................................18
+   3.2.1    General Syntax ...........................................19
+   3.2.2    http URL .................................................19
+   3.2.3    URI Comparison ...........................................20
+   3.3   Date/Time Formats ...........................................20
+   3.3.1    Full Date ................................................20
+   3.3.2    Delta Seconds ............................................21
+   3.4   Character Sets ..............................................21
+   3.4.1    Missing Charset ..........................................22
+   3.5   Content Codings .............................................23
+   3.6   Transfer Codings ............................................24
+   3.6.1    Chunked Transfer Coding ..................................25
+   3.7   Media Types .................................................26
+   3.7.1    Canonicalization and Text Defaults .......................27
+   3.7.2    Multipart Types ..........................................27
+   3.8   Product Tokens ..............................................28
+   3.9   Quality Values ..............................................29
+   3.10  Language Tags ...............................................29
+   3.11  Entity Tags .................................................30
+   3.12  Range Units .................................................30
+   4   HTTP Message ..................................................31
+   4.1   Message Types ...............................................31
+   4.2   Message Headers .............................................31
+   4.3   Message Body ................................................32
+   4.4   Message Length ..............................................33
+   4.5   General Header Fields .......................................34
+   5   Request .......................................................35
+   5.1   Request-Line ................................................35
+   5.1.1    Method ...................................................36
+   5.1.2    Request-URI ..............................................36
+   5.2   The Resource Identified by a Request ........................38
+   5.3   Request Header Fields .......................................38
+   6   Response ......................................................39
+   6.1   Status-Line .................................................39
+   6.1.1    Status Code and Reason Phrase ............................39
+   6.2   Response Header Fields ......................................41
+
+
+
+Fielding, et al.            Standards Track                     [Page 2]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   7   Entity ........................................................42
+   7.1   Entity Header Fields ........................................42
+   7.2   Entity Body .................................................43
+   7.2.1    Type .....................................................43
+   7.2.2    Entity Length ............................................43
+   8   Connections ...................................................44
+   8.1   Persistent Connections ......................................44
+   8.1.1    Purpose ..................................................44
+   8.1.2    Overall Operation ........................................45
+   8.1.3    Proxy Servers ............................................46
+   8.1.4    Practical Considerations .................................46
+   8.2   Message Transmission Requirements ...........................47
+   8.2.1    Persistent Connections and Flow Control ..................47
+   8.2.2    Monitoring Connections for Error Status Messages .........48
+   8.2.3    Use of the 100 (Continue) Status .........................48
+   8.2.4    Client Behavior if Server Prematurely Closes Connection ..50
+   9   Method Definitions ............................................51
+   9.1   Safe and Idempotent Methods .................................51
+   9.1.1    Safe Methods .............................................51
+   9.1.2    Idempotent Methods .......................................51
+   9.2   OPTIONS .....................................................52
+   9.3   GET .........................................................53
+   9.4   HEAD ........................................................54
+   9.5   POST ........................................................54
+   9.6   PUT .........................................................55
+   9.7   DELETE ......................................................56
+   9.8   TRACE .......................................................56
+   9.9   CONNECT .....................................................57
+   10   Status Code Definitions ......................................57
+   10.1  Informational 1xx ...........................................57
+   10.1.1   100 Continue .............................................58
+   10.1.2   101 Switching Protocols ..................................58
+   10.2  Successful 2xx ..............................................58
+   10.2.1   200 OK ...................................................58
+   10.2.2   201 Created ..............................................59
+   10.2.3   202 Accepted .............................................59
+   10.2.4   203 Non-Authoritative Information ........................59
+   10.2.5   204 No Content ...........................................60
+   10.2.6   205 Reset Content ........................................60
+   10.2.7   206 Partial Content ......................................60
+   10.3  Redirection 3xx .............................................61
+   10.3.1   300 Multiple Choices .....................................61
+   10.3.2   301 Moved Permanently ....................................62
+   10.3.3   302 Found ................................................62
+   10.3.4   303 See Other ............................................63
+   10.3.5   304 Not Modified .........................................63
+   10.3.6   305 Use Proxy ............................................64
+   10.3.7   306 (Unused) .............................................64
+
+
+
+Fielding, et al.            Standards Track                     [Page 3]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   10.3.8   307 Temporary Redirect ...................................65
+   10.4  Client Error 4xx ............................................65
+   10.4.1    400 Bad Request .........................................65
+   10.4.2    401 Unauthorized ........................................66
+   10.4.3    402 Payment Required ....................................66
+   10.4.4    403 Forbidden ...........................................66
+   10.4.5    404 Not Found ...........................................66
+   10.4.6    405 Method Not Allowed ..................................66
+   10.4.7    406 Not Acceptable ......................................67
+   10.4.8    407 Proxy Authentication Required .......................67
+   10.4.9    408 Request Timeout .....................................67
+   10.4.10   409 Conflict ............................................67
+   10.4.11   410 Gone ................................................68
+   10.4.12   411 Length Required .....................................68
+   10.4.13   412 Precondition Failed .................................68
+   10.4.14   413 Request Entity Too Large ............................69
+   10.4.15   414 Request-URI Too Long ................................69
+   10.4.16   415 Unsupported Media Type ..............................69
+   10.4.17   416 Requested Range Not Satisfiable .....................69
+   10.4.18   417 Expectation Failed ..................................70
+   10.5  Server Error 5xx ............................................70
+   10.5.1   500 Internal Server Error ................................70
+   10.5.2   501 Not Implemented ......................................70
+   10.5.3   502 Bad Gateway ..........................................70
+   10.5.4   503 Service Unavailable ..................................70
+   10.5.5   504 Gateway Timeout ......................................71
+   10.5.6   505 HTTP Version Not Supported ...........................71
+   11   Access Authentication ........................................71
+   12   Content Negotiation ..........................................71
+   12.1  Server-driven Negotiation ...................................72
+   12.2  Agent-driven Negotiation ....................................73
+   12.3  Transparent Negotiation .....................................74
+   13   Caching in HTTP ..............................................74
+   13.1.1   Cache Correctness ........................................75
+   13.1.2   Warnings .................................................76
+   13.1.3   Cache-control Mechanisms .................................77
+   13.1.4   Explicit User Agent Warnings .............................78
+   13.1.5   Exceptions to the Rules and Warnings .....................78
+   13.1.6   Client-controlled Behavior ...............................79
+   13.2  Expiration Model ............................................79
+   13.2.1   Server-Specified Expiration ..............................79
+   13.2.2   Heuristic Expiration .....................................80
+   13.2.3   Age Calculations .........................................80
+   13.2.4   Expiration Calculations ..................................83
+   13.2.5   Disambiguating Expiration Values .........................84
+   13.2.6   Disambiguating Multiple Responses ........................84
+   13.3  Validation Model ............................................85
+   13.3.1   Last-Modified Dates ......................................86
+
+
+
+Fielding, et al.            Standards Track                     [Page 4]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   13.3.2   Entity Tag Cache Validators ..............................86
+   13.3.3   Weak and Strong Validators ...............................86
+   13.3.4   Rules for When to Use Entity Tags and Last-Modified Dates.89
+   13.3.5   Non-validating Conditionals ..............................90
+   13.4  Response Cacheability .......................................91
+   13.5  Constructing Responses From Caches ..........................92
+   13.5.1   End-to-end and Hop-by-hop Headers ........................92
+   13.5.2   Non-modifiable Headers ...................................92
+   13.5.3   Combining Headers ........................................94
+   13.5.4   Combining Byte Ranges ....................................95
+   13.6  Caching Negotiated Responses ................................95
+   13.7  Shared and Non-Shared Caches ................................96
+   13.8  Errors or Incomplete Response Cache Behavior ................97
+   13.9  Side Effects of GET and HEAD ................................97
+   13.10   Invalidation After Updates or Deletions ...................97
+   13.11   Write-Through Mandatory ...................................98
+   13.12   Cache Replacement .........................................99
+   13.13   History Lists .............................................99
+   14   Header Field Definitions ....................................100
+   14.1  Accept .....................................................100
+   14.2  Accept-Charset .............................................102
+   14.3  Accept-Encoding ............................................102
+   14.4  Accept-Language ............................................104
+   14.5  Accept-Ranges ..............................................105
+   14.6  Age ........................................................106
+   14.7  Allow ......................................................106
+   14.8  Authorization ..............................................107
+   14.9  Cache-Control ..............................................108
+   14.9.1   What is Cacheable .......................................109
+   14.9.2   What May be Stored by Caches ............................110
+   14.9.3   Modifications of the Basic Expiration Mechanism .........111
+   14.9.4   Cache Revalidation and Reload Controls ..................113
+   14.9.5   No-Transform Directive ..................................115
+   14.9.6   Cache Control Extensions ................................116
+   14.10   Connection ...............................................117
+   14.11   Content-Encoding .........................................118
+   14.12   Content-Language .........................................118
+   14.13   Content-Length ...........................................119
+   14.14   Content-Location .........................................120
+   14.15   Content-MD5 ..............................................121
+   14.16   Content-Range ............................................122
+   14.17   Content-Type .............................................124
+   14.18   Date .....................................................124
+   14.18.1   Clockless Origin Server Operation ......................125
+   14.19   ETag .....................................................126
+   14.20   Expect ...................................................126
+   14.21   Expires ..................................................127
+   14.22   From .....................................................128
+
+
+
+Fielding, et al.            Standards Track                     [Page 5]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   14.23   Host .....................................................128
+   14.24   If-Match .................................................129
+   14.25   If-Modified-Since ........................................130
+   14.26   If-None-Match ............................................132
+   14.27   If-Range .................................................133
+   14.28   If-Unmodified-Since ......................................134
+   14.29   Last-Modified ............................................134
+   14.30   Location .................................................135
+   14.31   Max-Forwards .............................................136
+   14.32   Pragma ...................................................136
+   14.33   Proxy-Authenticate .......................................137
+   14.34   Proxy-Authorization ......................................137
+   14.35   Range ....................................................138
+   14.35.1    Byte Ranges ...........................................138
+   14.35.2    Range Retrieval Requests ..............................139
+   14.36   Referer ..................................................140
+   14.37   Retry-After ..............................................141
+   14.38   Server ...................................................141
+   14.39   TE .......................................................142
+   14.40   Trailer ..................................................143
+   14.41  Transfer-Encoding..........................................143
+   14.42   Upgrade ..................................................144
+   14.43   User-Agent ...............................................145
+   14.44   Vary .....................................................145
+   14.45   Via ......................................................146
+   14.46   Warning ..................................................148
+   14.47   WWW-Authenticate .........................................150
+   15 Security Considerations .......................................150
+   15.1      Personal Information....................................151
+   15.1.1   Abuse of Server Log Information .........................151
+   15.1.2   Transfer of Sensitive Information .......................151
+   15.1.3   Encoding Sensitive Information in URI's .................152
+   15.1.4   Privacy Issues Connected to Accept Headers ..............152
+   15.2  Attacks Based On File and Path Names .......................153
+   15.3  DNS Spoofing ...............................................154
+   15.4  Location Headers and Spoofing ..............................154
+   15.5  Content-Disposition Issues .................................154
+   15.6  Authentication Credentials and Idle Clients ................155
+   15.7  Proxies and Caching ........................................155
+   15.7.1    Denial of Service Attacks on Proxies....................156
+   16   Acknowledgments .............................................156
+   17   References ..................................................158
+   18   Authors' Addresses ..........................................162
+   19   Appendices ..................................................164
+   19.1  Internet Media Type message/http and application/http ......164
+   19.2  Internet Media Type multipart/byteranges ...................165
+   19.3  Tolerant Applications ......................................166
+   19.4  Differences Between HTTP Entities and RFC 2045 Entities ....167
+
+
+
+Fielding, et al.            Standards Track                     [Page 6]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   19.4.1   MIME-Version ............................................167
+   19.4.2   Conversion to Canonical Form ............................167
+   19.4.3   Conversion of Date Formats ..............................168
+   19.4.4   Introduction of Content-Encoding ........................168
+   19.4.5   No Content-Transfer-Encoding ............................168
+   19.4.6   Introduction of Transfer-Encoding .......................169
+   19.4.7   MHTML and Line Length Limitations .......................169
+   19.5  Additional Features ........................................169
+   19.5.1   Content-Disposition .....................................170
+   19.6  Compatibility with Previous Versions .......................170
+   19.6.1   Changes from HTTP/1.0 ...................................171
+   19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
+   19.6.3   Changes from RFC 2068 ...................................172
+   20   Index .......................................................175
+   21   Full Copyright Statement ....................................176
+
+1 Introduction
+
+1.1 Purpose
+
+   The Hypertext Transfer Protocol (HTTP) is an application-level
+   protocol for distributed, collaborative, hypermedia information
+   systems. HTTP has been in use by the World-Wide Web global
+   information initiative since 1990. The first version of HTTP,
+   referred to as HTTP/0.9, was a simple protocol for raw data transfer
+   across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
+   the protocol by allowing messages to be in the format of MIME-like
+   messages, containing metainformation about the data transferred and
+   modifiers on the request/response semantics. However, HTTP/1.0 does
+   not sufficiently take into consideration the effects of hierarchical
+   proxies, caching, the need for persistent connections, or virtual
+   hosts. In addition, the proliferation of incompletely-implemented
+   applications calling themselves "HTTP/1.0" has necessitated a
+   protocol version change in order for two communicating applications
+   to determine each other's true capabilities.
+
+   This specification defines the protocol referred to as "HTTP/1.1".
+   This protocol includes more stringent requirements than HTTP/1.0 in
+   order to ensure reliable implementation of its features.
+
+   Practical information systems require more functionality than simple
+   retrieval, including search, front-end update, and annotation. HTTP
+   allows an open-ended set of methods and headers that indicate the
+   purpose of a request [47]. It builds on the discipline of reference
+   provided by the Uniform Resource Identifier (URI) [3], as a location
+   (URL) [4] or name (URN) [20], for indicating the resource to which a
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 7]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   method is to be applied. Messages are passed in a format similar to
+   that used by Internet mail [9] as defined by the Multipurpose
+   Internet Mail Extensions (MIME) [7].
+
+   HTTP is also used as a generic protocol for communication between
+   user agents and proxies/gateways to other Internet systems, including
+   those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
+   and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
+   access to resources available from diverse applications.
+
+1.2 Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [34].
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the MUST or REQUIRED level requirements for the protocols it
+   implements. An implementation that satisfies all the MUST or REQUIRED
+   level and all the SHOULD level requirements for its protocols is said
+   to be "unconditionally compliant"; one that satisfies all the MUST
+   level requirements but not all the SHOULD level requirements for its
+   protocols is said to be "conditionally compliant."
+
+1.3 Terminology
+
+   This specification uses a number of terms to refer to the roles
+   played by participants in, and objects of, the HTTP communication.
+
+   connection
+      A transport layer virtual circuit established between two programs
+      for the purpose of communication.
+
+   message
+      The basic unit of HTTP communication, consisting of a structured
+      sequence of octets matching the syntax defined in section 4 and
+      transmitted via the connection.
+
+   request
+      An HTTP request message, as defined in section 5.
+
+   response
+      An HTTP response message, as defined in section 6.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 8]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   resource
+      A network data object or service that can be identified by a URI,
+      as defined in section 3.2. Resources may be available in multiple
+      representations (e.g. multiple languages, data formats, size, and
+      resolutions) or vary in other ways.
+
+   entity
+      The information transferred as the payload of a request or
+      response. An entity consists of metainformation in the form of
+      entity-header fields and content in the form of an entity-body, as
+      described in section 7.
+
+   representation
+      An entity included with a response that is subject to content
+      negotiation, as described in section 12. There may exist multiple
+      representations associated with a particular response status.
+
+   content negotiation
+      The mechanism for selecting the appropriate representation when
+      servicing a request, as described in section 12. The
+      representation of entities in any response can be negotiated
+      (including error responses).
+
+   variant
+      A resource may have one, or more than one, representation(s)
+      associated with it at any given instant. Each of these
+      representations is termed a `varriant'.  Use of the term `variant'
+      does not necessarily imply that the resource is subject to content
+      negotiation.
+
+   client
+      A program that establishes connections for the purpose of sending
+      requests.
+
+   user agent
+      The client which initiates a request. These are often browsers,
+      editors, spiders (web-traversing robots), or other end user tools.
+
+   server
+      An application program that accepts connections in order to
+      service requests by sending back responses. Any given program may
+      be capable of being both a client and a server; our use of these
+      terms refers only to the role being performed by the program for a
+      particular connection, rather than to the program's capabilities
+      in general. Likewise, any server may act as an origin server,
+      proxy, gateway, or tunnel, switching behavior based on the nature
+      of each request.
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 9]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   origin server
+      The server on which a given resource resides or is to be created.
+
+   proxy
+      An intermediary program which acts as both a server and a client
+      for the purpose of making requests on behalf of other clients.
+      Requests are serviced internally or by passing them on, with
+      possible translation, to other servers. A proxy MUST implement
+      both the client and server requirements of this specification. A
+      "transparent proxy" is a proxy that does not modify the request or
+      response beyond what is required for proxy authentication and
+      identification. A "non-transparent proxy" is a proxy that modifies
+      the request or response in order to provide some added service to
+      the user agent, such as group annotation services, media type
+      transformation, protocol reduction, or anonymity filtering. Except
+      where either transparent or non-transparent behavior is explicitly
+      stated, the HTTP proxy requirements apply to both types of
+      proxies.
+
+   gateway
+      A server which acts as an intermediary for some other server.
+      Unlike a proxy, a gateway receives requests as if it were the
+      origin server for the requested resource; the requesting client
+      may not be aware that it is communicating with a gateway.
+
+   tunnel
+      An intermediary program which is acting as a blind relay between
+      two connections. Once active, a tunnel is not considered a party
+      to the HTTP communication, though the tunnel may have been
+      initiated by an HTTP request. The tunnel ceases to exist when both
+      ends of the relayed connections are closed.
+
+   cache
+      A program's local store of response messages and the subsystem
+      that controls its message storage, retrieval, and deletion. A
+      cache stores cacheable responses in order to reduce the response
+      time and network bandwidth consumption on future, equivalent
+      requests. Any client or server may include a cache, though a cache
+      cannot be used by a server that is acting as a tunnel.
+
+   cacheable
+      A response is cacheable if a cache is allowed to store a copy of
+      the response message for use in answering subsequent requests. The
+      rules for determining the cacheability of HTTP responses are
+      defined in section 13. Even if a resource is cacheable, there may
+      be additional constraints on whether a cache can use the cached
+      copy for a particular request.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 10]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   first-hand
+      A response is first-hand if it comes directly and without
+      unnecessary delay from the origin server, perhaps via one or more
+      proxies. A response is also first-hand if its validity has just
+      been checked directly with the origin server.
+
+   explicit expiration time
+      The time at which the origin server intends that an entity should
+      no longer be returned by a cache without further validation.
+
+   heuristic expiration time
+      An expiration time assigned by a cache when no explicit expiration
+      time is available.
+
+   age
+      The age of a response is the time since it was sent by, or
+      successfully validated with, the origin server.
+
+   freshness lifetime
+      The length of time between the generation of a response and its
+      expiration time.
+
+   fresh
+      A response is fresh if its age has not yet exceeded its freshness
+      lifetime.
+
+   stale
+      A response is stale if its age has passed its freshness lifetime.
+
+   semantically transparent
+      A cache behaves in a "semantically transparent" manner, with
+      respect to a particular response, when its use affects neither the
+      requesting client nor the origin server, except to improve
+      performance. When a cache is semantically transparent, the client
+      receives exactly the same response (except for hop-by-hop headers)
+      that it would have received had its request been handled directly
+      by the origin server.
+
+   validator
+      A protocol element (e.g., an entity tag or a Last-Modified time)
+      that is used to find out whether a cache entry is an equivalent
+      copy of an entity.
+
+   upstream/downstream
+      Upstream and downstream describe the flow of a message: all
+      messages flow from upstream to downstream.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 11]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   inbound/outbound
+      Inbound and outbound refer to the request and response paths for
+      messages: "inbound" means "traveling toward the origin server",
+      and "outbound" means "traveling toward the user agent"
+
+1.4 Overall Operation
+
+   The HTTP protocol is a request/response protocol. A client sends a
+   request to the server in the form of a request method, URI, and
+   protocol version, followed by a MIME-like message containing request
+   modifiers, client information, and possible body content over a
+   connection with a server. The server responds with a status line,
+   including the message's protocol version and a success or error code,
+   followed by a MIME-like message containing server information, entity
+   metainformation, and possible entity-body content. The relationship
+   between HTTP and MIME is described in appendix 19.4.
+
+   Most HTTP communication is initiated by a user agent and consists of
+   a request to be applied to a resource on some origin server. In the
+   simplest case, this may be accomplished via a single connection (v)
+   between the user agent (UA) and the origin server (O).
+
+          request chain ------------------------>
+       UA -------------------v------------------- O
+          <----------------------- response chain
+
+   A more complicated situation occurs when one or more intermediaries
+   are present in the request/response chain. There are three common
+   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
+   forwarding agent, receiving requests for a URI in its absolute form,
+   rewriting all or part of the message, and forwarding the reformatted
+   request toward the server identified by the URI. A gateway is a
+   receiving agent, acting as a layer above some other server(s) and, if
+   necessary, translating the requests to the underlying server's
+   protocol. A tunnel acts as a relay point between two connections
+   without changing the messages; tunnels are used when the
+   communication needs to pass through an intermediary (such as a
+   firewall) even when the intermediary cannot understand the contents
+   of the messages.
+
+          request chain -------------------------------------->
+       UA -----v----- A -----v----- B -----v----- C -----v----- O
+          <------------------------------------- response chain
+
+   The figure above shows three intermediaries (A, B, and C) between the
+   user agent and origin server. A request or response message that
+   travels the whole chain will pass through four separate connections.
+   This distinction is important because some HTTP communication options
+
+
+
+Fielding, et al.            Standards Track                    [Page 12]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   may apply only to the connection with the nearest, non-tunnel
+   neighbor, only to the end-points of the chain, or to all connections
+   along the chain. Although the diagram is linear, each participant may
+   be engaged in multiple, simultaneous communications. For example, B
+   may be receiving requests from many clients other than A, and/or
+   forwarding requests to servers other than C, at the same time that it
+   is handling A's request.
+
+   Any party to the communication which is not acting as a tunnel may
+   employ an internal cache for handling requests. The effect of a cache
+   is that the request/response chain is shortened if one of the
+   participants along the chain has a cached response applicable to that
+   request. The following illustrates the resulting chain if B has a
+   cached copy of an earlier response from O (via C) for a request which
+   has not been cached by UA or A.
+
+          request chain ---------->
+       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
+          <--------- response chain
+
+   Not all responses are usefully cacheable, and some requests may
+   contain modifiers which place special requirements on cache behavior.
+   HTTP requirements for cache behavior and cacheable responses are
+   defined in section 13.
+
+   In fact, there are a wide variety of architectures and configurations
+   of caches and proxies currently being experimented with or deployed
+   across the World Wide Web. These systems include national hierarchies
+   of proxy caches to save transoceanic bandwidth, systems that
+   broadcast or multicast cache entries, organizations that distribute
+   subsets of cached data via CD-ROM, and so on. HTTP systems are used
+   in corporate intranets over high-bandwidth links, and for access via
+   PDAs with low-power radio links and intermittent connectivity. The
+   goal of HTTP/1.1 is to support the wide diversity of configurations
+   already deployed while introducing protocol constructs that meet the
+   needs of those who build web applications that require high
+   reliability and, failing that, at least reliable indications of
+   failure.
+
+   HTTP communication usually takes place over TCP/IP connections. The
+   default port is TCP 80 [19], but other ports can be used. This does
+   not preclude HTTP from being implemented on top of any other protocol
+   on the Internet, or on other networks. HTTP only presumes a reliable
+   transport; any protocol that provides such guarantees can be used;
+   the mapping of the HTTP/1.1 request and response structures onto the
+   transport data units of the protocol in question is outside the scope
+   of this specification.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 13]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   In HTTP/1.0, most implementations used a new connection for each
+   request/response exchange. In HTTP/1.1, a connection may be used for
+   one or more request/response exchanges, although connections may be
+   closed for a variety of reasons (see section 8.1).
+
+2 Notational Conventions and Generic Grammar
+
+2.1 Augmented BNF
+
+   All of the mechanisms specified in this document are described in
+   both prose and an augmented Backus-Naur Form (BNF) similar to that
+   used by RFC 822 [9]. Implementors will need to be familiar with the
+   notation in order to understand this specification. The augmented BNF
+   includes the following constructs:
+
+   name = definition
+      The name of a rule is simply the name itself (without any
+      enclosing "<" and ">") and is separated from its definition by the
+      equal "=" character. White space is only significant in that
+      indentation of continuation lines is used to indicate a rule
+      definition that spans more than one line. Certain basic rules are
+      in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
+      brackets are used within definitions whenever their presence will
+      facilitate discerning the use of rule names.
+
+   "literal"
+      Quotation marks surround literal text. Unless stated otherwise,
+      the text is case-insensitive.
+
+   rule1 | rule2
+      Elements separated by a bar ("|") are alternatives, e.g., "yes |
+      no" will accept yes or no.
+
+   (rule1 rule2)
+      Elements enclosed in parentheses are treated as a single element.
+      Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
+      foo elem" and "elem bar elem".
+
+   *rule
+      The character "*" preceding an element indicates repetition. The
+      full form is "<n>*<m>element" indicating at least <n> and at most
+      <m> occurrences of element. Default values are 0 and infinity so
+      that "*(element)" allows any number, including zero; "1*element"
+      requires at least one; and "1*2element" allows one or two.
+
+   [rule]
+      Square brackets enclose optional elements; "[foo bar]" is
+      equivalent to "*1(foo bar)".
+
+
+
+Fielding, et al.            Standards Track                    [Page 14]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   N rule
+      Specific repetition: "<n>(element)" is equivalent to
+      "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
+      Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
+      alphabetic characters.
+
+   #rule
+      A construct "#" is defined, similar to "*", for defining lists of
+      elements. The full form is "<n>#<m>element" indicating at least
+      <n> and at most <m> elements, each separated by one or more commas
+      (",") and OPTIONAL linear white space (LWS). This makes the usual
+      form of lists very easy; a rule such as
+         ( *LWS element *( *LWS "," *LWS element ))
+      can be shown as
+         1#element
+      Wherever this construct is used, null elements are allowed, but do
+      not contribute to the count of elements present. That is,
+      "(element), , (element) " is permitted, but counts as only two
+      elements. Therefore, where at least one element is required, at
+      least one non-null element MUST be present. Default values are 0
+      and infinity so that "#element" allows any number, including zero;
+      "1#element" requires at least one; and "1#2element" allows one or
+      two.
+
+   ; comment
+      A semi-colon, set off some distance to the right of rule text,
+      starts a comment that continues to the end of line. This is a
+      simple way of including useful notes in parallel with the
+      specifications.
+
+   implied *LWS
+      The grammar described by this specification is word-based. Except
+      where noted otherwise, linear white space (LWS) can be included
+      between any two adjacent words (token or quoted-string), and
+      between adjacent words and separators, without changing the
+      interpretation of a field. At least one delimiter (LWS and/or
+
+      separators) MUST exist between any two tokens (for the definition
+      of "token" below), since they would otherwise be interpreted as a
+      single token.
+
+2.2 Basic Rules
+
+   The following rules are used throughout this specification to
+   describe basic parsing constructs. The US-ASCII coded character set
+   is defined by ANSI X3.4-1986 [21].
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 15]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       OCTET          = <any 8-bit sequence of data>
+       CHAR           = <any US-ASCII character (octets 0 - 127)>
+       UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
+       LOALPHA        = <any US-ASCII lowercase letter "a".."z">
+       ALPHA          = UPALPHA | LOALPHA
+       DIGIT          = <any US-ASCII digit "0".."9">
+       CTL            = <any US-ASCII control character
+                        (octets 0 - 31) and DEL (127)>
+       CR             = <US-ASCII CR, carriage return (13)>
+       LF             = <US-ASCII LF, linefeed (10)>
+       SP             = <US-ASCII SP, space (32)>
+       HT             = <US-ASCII HT, horizontal-tab (9)>
+       <">            = <US-ASCII double-quote mark (34)>
+
+   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
+   protocol elements except the entity-body (see appendix 19.3 for
+   tolerant applications). The end-of-line marker within an entity-body
+   is defined by its associated media type, as described in section 3.7.
+
+       CRLF           = CR LF
+
+   HTTP/1.1 header field values can be folded onto multiple lines if the
+   continuation line begins with a space or horizontal tab. All linear
+   white space, including folding, has the same semantics as SP. A
+   recipient MAY replace any linear white space with a single SP before
+   interpreting the field value or forwarding the message downstream.
+
+       LWS            = [CRLF] 1*( SP | HT )
+
+   The TEXT rule is only used for descriptive field contents and values
+   that are not intended to be interpreted by the message parser. Words
+   of *TEXT MAY contain characters from character sets other than ISO-
+   8859-1 [22] only when encoded according to the rules of RFC 2047
+   [14].
+
+       TEXT           = <any OCTET except CTLs,
+                        but including LWS>
+
+   A CRLF is allowed in the definition of TEXT only as part of a header
+   field continuation. It is expected that the folding LWS will be
+   replaced with a single SP before interpretation of the TEXT value.
+
+   Hexadecimal numeric characters are used in several protocol elements.
+
+       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
+                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 16]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Many HTTP/1.1 header field values consist of words separated by LWS
+   or special characters. These special characters MUST be in a quoted
+   string to be used within a parameter value (as defined in section
+   3.6).
+
+       token          = 1*<any CHAR except CTLs or separators>
+       separators     = "(" | ")" | "<" | ">" | "@"
+                      | "," | ";" | ":" | "\" | <">
+                      | "/" | "[" | "]" | "?" | "="
+                      | "{" | "}" | SP | HT
+
+   Comments can be included in some HTTP header fields by surrounding
+   the comment text with parentheses. Comments are only allowed in
+   fields containing "comment" as part of their field value definition.
+   In all other fields, parentheses are considered part of the field
+   value.
+
+       comment        = "(" *( ctext | quoted-pair | comment ) ")"
+       ctext          = <any TEXT excluding "(" and ")">
+
+   A string of text is parsed as a single word if it is quoted using
+   double-quote marks.
+
+       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
+       qdtext         = <any TEXT except <">>
+
+   The backslash character ("\") MAY be used as a single-character
+   quoting mechanism only within quoted-string and comment constructs.
+
+       quoted-pair    = "\" CHAR
+
+3 Protocol Parameters
+
+3.1 HTTP Version
+
+   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
+   of the protocol. The protocol versioning policy is intended to allow
+   the sender to indicate the format of a message and its capacity for
+   understanding further HTTP communication, rather than the features
+   obtained via that communication. No change is made to the version
+   number for the addition of message components which do not affect
+   communication behavior or which only add to extensible field values.
+   The <minor> number is incremented when the changes made to the
+   protocol add features which do not change the general message parsing
+   algorithm, but which may add to the message semantics and imply
+   additional capabilities of the sender. The <major> number is
+   incremented when the format of a message within the protocol is
+   changed. See RFC 2145 [36] for a fuller explanation.
+
+
+
+Fielding, et al.            Standards Track                    [Page 17]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The version of an HTTP message is indicated by an HTTP-Version field
+   in the first line of the message.
+
+       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
+
+   Note that the major and minor numbers MUST be treated as separate
+   integers and that each MAY be incremented higher than a single digit.
+   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
+   lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
+   MUST NOT be sent.
+
+   An application that sends a request or response message that includes
+   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
+   with this specification. Applications that are at least conditionally
+   compliant with this specification SHOULD use an HTTP-Version of
+   "HTTP/1.1" in their messages, and MUST do so for any message that is
+   not compatible with HTTP/1.0. For more details on when to send
+   specific HTTP-Version values, see RFC 2145 [36].
+
+   The HTTP version of an application is the highest HTTP version for
+   which the application is at least conditionally compliant.
+
+   Proxy and gateway applications need to be careful when forwarding
+   messages in protocol versions different from that of the application.
+   Since the protocol version indicates the protocol capability of the
+   sender, a proxy/gateway MUST NOT send a message with a version
+   indicator which is greater than its actual version. If a higher
+   version request is received, the proxy/gateway MUST either downgrade
+   the request version, or respond with an error, or switch to tunnel
+   behavior.
+
+   Due to interoperability problems with HTTP/1.0 proxies discovered
+   since the publication of RFC 2068[33], caching proxies MUST, gateways
+   MAY, and tunnels MUST NOT upgrade the request to the highest version
+   they support. The proxy/gateway's response to that request MUST be in
+   the same major version as the request.
+
+      Note: Converting between versions of HTTP may involve modification
+      of header fields required or forbidden by the versions involved.
+
+3.2 Uniform Resource Identifiers
+
+   URIs have been known by many names: WWW addresses, Universal Document
+   Identifiers, Universal Resource Identifiers [3], and finally the
+   combination of Uniform Resource Locators (URL) [4] and Names (URN)
+   [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
+   simply formatted strings which identify--via name, location, or any
+   other characteristic--a resource.
+
+
+
+Fielding, et al.            Standards Track                    [Page 18]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+3.2.1 General Syntax
+
+   URIs in HTTP can be represented in absolute form or relative to some
+   known base URI [11], depending upon the context of their use. The two
+   forms are differentiated by the fact that absolute URIs always begin
+   with a scheme name followed by a colon. For definitive information on
+   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
+   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
+   1738 [4] and RFC 1808 [11]). This specification adopts the
+   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
+   "host","abs_path", "rel_path", and "authority" from that
+   specification.
+
+   The HTTP protocol does not place any a priori limit on the length of
+   a URI. Servers MUST be able to handle the URI of any resource they
+   serve, and SHOULD be able to handle URIs of unbounded length if they
+   provide GET-based forms that could generate such URIs. A server
+   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
+   than the server can handle (see section 10.4.15).
+
+      Note: Servers ought to be cautious about depending on URI lengths
+      above 255 bytes, because some older client or proxy
+      implementations might not properly support these lengths.
+
+3.2.2 http URL
+
+   The "http" scheme is used to locate network resources via the HTTP
+   protocol. This section defines the scheme-specific syntax and
+   semantics for http URLs.
+
+   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+
+   If the port is empty or not given, port 80 is assumed. The semantics
+   are that the identified resource is located at the server listening
+   for TCP connections on that port of that host, and the Request-URI
+   for the resource is abs_path (section 5.1.2). The use of IP addresses
+   in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
+   the abs_path is not present in the URL, it MUST be given as "/" when
+   used as a Request-URI for a resource (section 5.1.2). If a proxy
+   receives a host name which is not a fully qualified domain name, it
+   MAY add its domain to the host name it received. If a proxy receives
+   a fully qualified domain name, the proxy MUST NOT change the host
+   name.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 19]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+3.2.3 URI Comparison
+
+   When comparing two URIs to decide if they match or not, a client
+   SHOULD use a case-sensitive octet-by-octet comparison of the entire
+   URIs, with these exceptions:
+
+      - A port that is empty or not given is equivalent to the default
+        port for that URI-reference;
+
+        - Comparisons of host names MUST be case-insensitive;
+
+        - Comparisons of scheme names MUST be case-insensitive;
+
+        - An empty abs_path is equivalent to an abs_path of "/".
+
+   Characters other than those in the "reserved" and "unsafe" sets (see
+   RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
+
+   For example, the following three URIs are equivalent:
+
+      http://abc.com:80/~smith/home.html
+      http://ABC.com/%7Esmith/home.html
+      http://ABC.com:/%7esmith/home.html
+
+3.3 Date/Time Formats
+
+3.3.1 Full Date
+
+   HTTP applications have historically allowed three different formats
+   for the representation of date/time stamps:
+
+      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
+      Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
+      Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
+
+   The first format is preferred as an Internet standard and represents
+   a fixed-length subset of that defined by RFC 1123 [8] (an update to
+   RFC 822 [9]). The second format is in common use, but is based on the
+   obsolete RFC 850 [12] date format and lacks a four-digit year.
+   HTTP/1.1 clients and servers that parse the date value MUST accept
+   all three formats (for compatibility with HTTP/1.0), though they MUST
+   only generate the RFC 1123 format for representing HTTP-date values
+   in header fields. See section 19.3 for further information.
+
+      Note: Recipients of date values are encouraged to be robust in
+      accepting date values that may have been sent by non-HTTP
+      applications, as is sometimes the case when retrieving or posting
+      messages via proxies/gateways to SMTP or NNTP.
+
+
+
+Fielding, et al.            Standards Track                    [Page 20]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
+   (GMT), without exception. For the purposes of HTTP, GMT is exactly
+   equal to UTC (Coordinated Universal Time). This is indicated in the
+   first two formats by the inclusion of "GMT" as the three-letter
+   abbreviation for time zone, and MUST be assumed when reading the
+   asctime format. HTTP-date is case sensitive and MUST NOT include
+   additional LWS beyond that specifically included as SP in the
+   grammar.
+
+       HTTP-date    = rfc1123-date | rfc850-date | asctime-date
+       rfc1123-date = wkday "," SP date1 SP time SP "GMT"
+       rfc850-date  = weekday "," SP date2 SP time SP "GMT"
+       asctime-date = wkday SP date3 SP time SP 4DIGIT
+       date1        = 2DIGIT SP month SP 4DIGIT
+                      ; day month year (e.g., 02 Jun 1982)
+       date2        = 2DIGIT "-" month "-" 2DIGIT
+                      ; day-month-year (e.g., 02-Jun-82)
+       date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
+                      ; month day (e.g., Jun  2)
+       time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+                      ; 00:00:00 - 23:59:59
+       wkday        = "Mon" | "Tue" | "Wed"
+                    | "Thu" | "Fri" | "Sat" | "Sun"
+       weekday      = "Monday" | "Tuesday" | "Wednesday"
+                    | "Thursday" | "Friday" | "Saturday" | "Sunday"
+       month        = "Jan" | "Feb" | "Mar" | "Apr"
+                    | "May" | "Jun" | "Jul" | "Aug"
+                    | "Sep" | "Oct" | "Nov" | "Dec"
+
+      Note: HTTP requirements for the date/time stamp format apply only
+      to their usage within the protocol stream. Clients and servers are
+      not required to use these formats for user presentation, request
+      logging, etc.
+
+3.3.2 Delta Seconds
+
+   Some HTTP header fields allow a time value to be specified as an
+   integer number of seconds, represented in decimal, after the time
+   that the message was received.
+
+       delta-seconds  = 1*DIGIT
+
+3.4 Character Sets
+
+   HTTP uses the same definition of the term "character set" as that
+   described for MIME:
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 21]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The term "character set" is used in this document to refer to a
+   method used with one or more tables to convert a sequence of octets
+   into a sequence of characters. Note that unconditional conversion in
+   the other direction is not required, in that not all characters may
+   be available in a given character set and a character set may provide
+   more than one sequence of octets to represent a particular character.
+   This definition is intended to allow various kinds of character
+   encoding, from simple single-table mappings such as US-ASCII to
+   complex table switching methods such as those that use ISO-2022's
+   techniques. However, the definition associated with a MIME character
+   set name MUST fully specify the mapping to be performed from octets
+   to characters. In particular, use of external profiling information
+   to determine the exact mapping is not permitted.
+
+      Note: This use of the term "character set" is more commonly
+      referred to as a "character encoding." However, since HTTP and
+      MIME share the same registry, it is important that the terminology
+      also be shared.
+
+   HTTP character sets are identified by case-insensitive tokens. The
+   complete set of tokens is defined by the IANA Character Set registry
+   [19].
+
+       charset = token
+
+   Although HTTP allows an arbitrary token to be used as a charset
+   value, any token that has a predefined value within the IANA
+   Character Set registry [19] MUST represent the character set defined
+   by that registry. Applications SHOULD limit their use of character
+   sets to those defined by the IANA registry.
+
+   Implementors should be aware of IETF character set requirements [38]
+   [41].
+
+3.4.1 Missing Charset
+
+   Some HTTP/1.0 software has interpreted a Content-Type header without
+   charset parameter incorrectly to mean "recipient should guess."
+   Senders wishing to defeat this behavior MAY include a charset
+   parameter even when the charset is ISO-8859-1 and SHOULD do so when
+   it is known that it will not confuse the recipient.
+
+   Unfortunately, some older HTTP/1.0 clients did not deal properly with
+   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
+   charset label provided by the sender; and those user agents that have
+   a provision to "guess" a charset MUST use the charset from the
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 22]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   content-type field if they support that charset, rather than the
+   recipient's preference, when initially displaying a document. See
+   section 3.7.1.
+
+3.5 Content Codings
+
+   Content coding values indicate an encoding transformation that has
+   been or can be applied to an entity. Content codings are primarily
+   used to allow a document to be compressed or otherwise usefully
+   transformed without losing the identity of its underlying media type
+   and without loss of information. Frequently, the entity is stored in
+   coded form, transmitted directly, and only decoded by the recipient.
+
+       content-coding   = token
+
+   All content-coding values are case-insensitive. HTTP/1.1 uses
+   content-coding values in the Accept-Encoding (section 14.3) and
+   Content-Encoding (section 14.11) header fields. Although the value
+   describes the content-coding, what is more important is that it
+   indicates what decoding mechanism will be required to remove the
+   encoding.
+
+   The Internet Assigned Numbers Authority (IANA) acts as a registry for
+   content-coding value tokens. Initially, the registry contains the
+   following tokens:
+
+   gzip An encoding format produced by the file compression program
+        "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
+        Lempel-Ziv coding (LZ77) with a 32 bit CRC.
+
+   compress
+        The encoding format produced by the common UNIX file compression
+        program "compress". This format is an adaptive Lempel-Ziv-Welch
+        coding (LZW).
+
+        Use of program names for the identification of encoding formats
+        is not desirable and is discouraged for future encodings. Their
+        use here is representative of historical practice, not good
+        design. For compatibility with previous implementations of HTTP,
+        applications SHOULD consider "x-gzip" and "x-compress" to be
+        equivalent to "gzip" and "compress" respectively.
+
+   deflate
+        The "zlib" format defined in RFC 1950 [31] in combination with
+        the "deflate" compression mechanism described in RFC 1951 [29].
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 23]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   identity
+        The default (identity) encoding; the use of no transformation
+        whatsoever. This content-coding is used only in the Accept-
+        Encoding header, and SHOULD NOT be used in the Content-Encoding
+        header.
+
+   New content-coding value tokens SHOULD be registered; to allow
+   interoperability between clients and servers, specifications of the
+   content coding algorithms needed to implement a new value SHOULD be
+   publicly available and adequate for independent implementation, and
+   conform to the purpose of content coding defined in this section.
+
+3.6 Transfer Codings
+
+   Transfer-coding values are used to indicate an encoding
+   transformation that has been, can be, or may need to be applied to an
+   entity-body in order to ensure "safe transport" through the network.
+   This differs from a content coding in that the transfer-coding is a
+   property of the message, not of the original entity.
+
+       transfer-coding         = "chunked" | transfer-extension
+       transfer-extension      = token *( ";" parameter )
+
+   Parameters are in  the form of attribute/value pairs.
+
+       parameter               = attribute "=" value
+       attribute               = token
+       value                   = token | quoted-string
+
+   All transfer-coding values are case-insensitive. HTTP/1.1 uses
+   transfer-coding values in the TE header field (section 14.39) and in
+   the Transfer-Encoding header field (section 14.41).
+
+   Whenever a transfer-coding is applied to a message-body, the set of
+   transfer-codings MUST include "chunked", unless the message is
+   terminated by closing the connection. When the "chunked" transfer-
+   coding is used, it MUST be the last transfer-coding applied to the
+   message-body. The "chunked" transfer-coding MUST NOT be applied more
+   than once to a message-body. These rules allow the recipient to
+   determine the transfer-length of the message (section 4.4).
+
+   Transfer-codings are analogous to the Content-Transfer-Encoding
+   values of MIME [7], which were designed to enable safe transport of
+   binary data over a 7-bit transport service. However, safe transport
+   has a different focus for an 8bit-clean transfer protocol. In HTTP,
+   the only unsafe characteristic of message-bodies is the difficulty in
+   determining the exact body length (section 7.2.2), or the desire to
+   encrypt data over a shared transport.
+
+
+
+Fielding, et al.            Standards Track                    [Page 24]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Internet Assigned Numbers Authority (IANA) acts as a registry for
+   transfer-coding value tokens. Initially, the registry contains the
+   following tokens: "chunked" (section 3.6.1), "identity" (section
+   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
+   (section 3.5).
+
+   New transfer-coding value tokens SHOULD be registered in the same way
+   as new content-coding value tokens (section 3.5).
+
+   A server which receives an entity-body with a transfer-coding it does
+   not understand SHOULD return 501 (Unimplemented), and close the
+   connection. A server MUST NOT send transfer-codings to an HTTP/1.0
+   client.
+
+3.6.1 Chunked Transfer Coding
+
+   The chunked encoding modifies the body of a message in order to
+   transfer it as a series of chunks, each with its own size indicator,
+   followed by an OPTIONAL trailer containing entity-header fields. This
+   allows dynamically produced content to be transferred along with the
+   information necessary for the recipient to verify that it has
+   received the full message.
+
+       Chunked-Body   = *chunk
+                        last-chunk
+                        trailer
+                        CRLF
+
+       chunk          = chunk-size [ chunk-extension ] CRLF
+                        chunk-data CRLF
+       chunk-size     = 1*HEX
+       last-chunk     = 1*("0") [ chunk-extension ] CRLF
+
+       chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
+       chunk-ext-name = token
+       chunk-ext-val  = token | quoted-string
+       chunk-data     = chunk-size(OCTET)
+       trailer        = *(entity-header CRLF)
+
+   The chunk-size field is a string of hex digits indicating the size of
+   the chunk. The chunked encoding is ended by any chunk whose size is
+   zero, followed by the trailer, which is terminated by an empty line.
+
+   The trailer allows the sender to include additional HTTP header
+   fields at the end of the message. The Trailer header field can be
+   used to indicate which header fields are included in a trailer (see
+   section 14.40).
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 25]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A server using chunked transfer-coding in a response MUST NOT use the
+   trailer for any header fields unless at least one of the following is
+   true:
+
+   a)the request included a TE header field that indicates "trailers" is
+     acceptable in the transfer-coding of the  response, as described in
+     section 14.39; or,
+
+   b)the server is the origin server for the response, the trailer
+     fields consist entirely of optional metadata, and the recipient
+     could use the message (in a manner acceptable to the origin server)
+     without receiving this metadata.  In other words, the origin server
+     is willing to accept the possibility that the trailer fields might
+     be silently discarded along the path to the client.
+
+   This requirement prevents an interoperability failure when the
+   message is being received by an HTTP/1.1 (or later) proxy and
+   forwarded to an HTTP/1.0 recipient. It avoids a situation where
+   compliance with the protocol would have necessitated a possibly
+   infinite buffer on the proxy.
+
+   An example process for decoding a Chunked-Body is presented in
+   appendix 19.4.6.
+
+   All HTTP/1.1 applications MUST be able to receive and decode the
+   "chunked" transfer-coding, and MUST ignore chunk-extension extensions
+   they do not understand.
+
+3.7 Media Types
+
+   HTTP uses Internet Media Types [17] in the Content-Type (section
+   14.17) and Accept (section 14.1) header fields in order to provide
+   open and extensible data typing and type negotiation.
+
+       media-type     = type "/" subtype *( ";" parameter )
+       type           = token
+       subtype        = token
+
+   Parameters MAY follow the type/subtype in the form of attribute/value
+   pairs (as defined in section 3.6).
+
+   The type, subtype, and parameter attribute names are case-
+   insensitive. Parameter values might or might not be case-sensitive,
+   depending on the semantics of the parameter name. Linear white space
+   (LWS) MUST NOT be used between the type and subtype, nor between an
+   attribute and its value. The presence or absence of a parameter might
+   be significant to the processing of a media-type, depending on its
+   definition within the media type registry.
+
+
+
+Fielding, et al.            Standards Track                    [Page 26]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Note that some older HTTP applications do not recognize media type
+   parameters. When sending data to older HTTP applications,
+   implementations SHOULD only use media type parameters when they are
+   required by that type/subtype definition.
+
+   Media-type values are registered with the Internet Assigned Number
+   Authority (IANA [19]). The media type registration process is
+   outlined in RFC 1590 [17]. Use of non-registered media types is
+   discouraged.
+
+3.7.1 Canonicalization and Text Defaults
+
+   Internet media types are registered with a canonical form. An
+   entity-body transferred via HTTP messages MUST be represented in the
+   appropriate canonical form prior to its transmission except for
+   "text" types, as defined in the next paragraph.
+
+   When in canonical form, media subtypes of the "text" type use CRLF as
+   the text line break. HTTP relaxes this requirement and allows the
+   transport of text media with plain CR or LF alone representing a line
+   break when it is done consistently for an entire entity-body. HTTP
+   applications MUST accept CRLF, bare CR, and bare LF as being
+   representative of a line break in text media received via HTTP. In
+   addition, if the text is represented in a character set that does not
+   use octets 13 and 10 for CR and LF respectively, as is the case for
+   some multi-byte character sets, HTTP allows the use of whatever octet
+   sequences are defined by that character set to represent the
+   equivalent of CR and LF for line breaks. This flexibility regarding
+   line breaks applies only to text media in the entity-body; a bare CR
+   or LF MUST NOT be substituted for CRLF within any of the HTTP control
+   structures (such as header fields and multipart boundaries).
+
+   If an entity-body is encoded with a content-coding, the underlying
+   data MUST be in a form defined above prior to being encoded.
+
+   The "charset" parameter is used with some media types to define the
+   character set (section 3.4) of the data. When no explicit charset
+   parameter is provided by the sender, media subtypes of the "text"
+   type are defined to have a default charset value of "ISO-8859-1" when
+   received via HTTP. Data in character sets other than "ISO-8859-1" or
+   its subsets MUST be labeled with an appropriate charset value. See
+   section 3.4.1 for compatibility problems.
+
+3.7.2 Multipart Types
+
+   MIME provides for a number of "multipart" types -- encapsulations of
+   one or more entities within a single message-body. All multipart
+   types share a common syntax, as defined in section 5.1.1 of RFC 2046
+
+
+
+Fielding, et al.            Standards Track                    [Page 27]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [40], and MUST include a boundary parameter as part of the media type
+   value. The message body is itself a protocol element and MUST
+   therefore use only CRLF to represent line breaks between body-parts.
+   Unlike in RFC 2046, the epilogue of any multipart message MUST be
+   empty; HTTP applications MUST NOT transmit the epilogue (even if the
+   original multipart contains an epilogue). These restrictions exist in
+   order to preserve the self-delimiting nature of a multipart message-
+   body, wherein the "end" of the message-body is indicated by the
+   ending multipart boundary.
+
+   In general, HTTP treats a multipart message-body no differently than
+   any other media type: strictly as payload. The one exception is the
+   "multipart/byteranges" type (appendix 19.2) when it appears in a 206
+   (Partial Content) response, which will be interpreted by some HTTP
+   caching mechanisms as described in sections 13.5.4 and 14.16. In all
+   other cases, an HTTP user agent SHOULD follow the same or similar
+   behavior as a MIME user agent would upon receipt of a multipart type.
+   The MIME header fields within each body-part of a multipart message-
+   body do not have any significance to HTTP beyond that defined by
+   their MIME semantics.
+
+   In general, an HTTP user agent SHOULD follow the same or similar
+   behavior as a MIME user agent would upon receipt of a multipart type.
+   If an application receives an unrecognized multipart subtype, the
+   application MUST treat it as being equivalent to "multipart/mixed".
+
+      Note: The "multipart/form-data" type has been specifically defined
+      for carrying form data suitable for processing via the POST
+      request method, as described in RFC 1867 [15].
+
+3.8 Product Tokens
+
+   Product tokens are used to allow communicating applications to
+   identify themselves by software name and version. Most fields using
+   product tokens also allow sub-products which form a significant part
+   of the application to be listed, separated by white space. By
+   convention, the products are listed in order of their significance
+   for identifying the application.
+
+       product         = token ["/" product-version]
+       product-version = token
+
+   Examples:
+
+       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+       Server: Apache/0.8.4
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 28]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Product tokens SHOULD be short and to the point. They MUST NOT be
+   used for advertising or other non-essential information. Although any
+   token character MAY appear in a product-version, this token SHOULD
+   only be used for a version identifier (i.e., successive versions of
+   the same product SHOULD only differ in the product-version portion of
+   the product value).
+
+3.9 Quality Values
+
+   HTTP content negotiation (section 12) uses short "floating point"
+   numbers to indicate the relative importance ("weight") of various
+   negotiable parameters.  A weight is normalized to a real number in
+   the range 0 through 1, where 0 is the minimum and 1 the maximum
+   value. If a parameter has a quality value of 0, then content with
+   this parameter is `not acceptable' for the client. HTTP/1.1
+   applications MUST NOT generate more than three digits after the
+   decimal point. User configuration of these values SHOULD also be
+   limited in this fashion.
+
+       qvalue         = ( "0" [ "." 0*3DIGIT ] )
+                      | ( "1" [ "." 0*3("0") ] )
+
+   "Quality values" is a misnomer, since these values merely represent
+   relative degradation in desired quality.
+
+3.10 Language Tags
+
+   A language tag identifies a natural language spoken, written, or
+   otherwise conveyed by human beings for communication of information
+   to other human beings. Computer languages are explicitly excluded.
+   HTTP uses language tags within the Accept-Language and Content-
+   Language fields.
+
+   The syntax and registry of HTTP language tags is the same as that
+   defined by RFC 1766 [1]. In summary, a language tag is composed of 1
+   or more parts: A primary language tag and a possibly empty series of
+   subtags:
+
+        language-tag  = primary-tag *( "-" subtag )
+        primary-tag   = 1*8ALPHA
+        subtag        = 1*8ALPHA
+
+   White space is not allowed within the tag and all tags are case-
+   insensitive. The name space of language tags is administered by the
+   IANA. Example tags include:
+
+       en, en-US, en-cockney, i-cherokee, x-pig-latin
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 29]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   where any two-letter primary-tag is an ISO-639 language abbreviation
+   and any two-letter initial subtag is an ISO-3166 country code. (The
+   last three tags above are not registered tags; all but the last are
+   examples of tags which could be registered in future.)
+
+3.11 Entity Tags
+
+   Entity tags are used for comparing two or more entities from the same
+   requested resource. HTTP/1.1 uses entity tags in the ETag (section
+   14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
+   If-Range (section 14.27) header fields. The definition of how they
+   are used and compared as cache validators is in section 13.3.3. An
+   entity tag consists of an opaque quoted string, possibly prefixed by
+   a weakness indicator.
+
+      entity-tag = [ weak ] opaque-tag
+      weak       = "W/"
+      opaque-tag = quoted-string
+
+   A "strong entity tag" MAY be shared by two entities of a resource
+   only if they are equivalent by octet equality.
+
+   A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
+   two entities of a resource only if the entities are equivalent and
+   could be substituted for each other with no significant change in
+   semantics. A weak entity tag can only be used for weak comparison.
+
+   An entity tag MUST be unique across all versions of all entities
+   associated with a particular resource. A given entity tag value MAY
+   be used for entities obtained by requests on different URIs. The use
+   of the same entity tag value in conjunction with entities obtained by
+   requests on different URIs does not imply the equivalence of those
+   entities.
+
+3.12 Range Units
+
+   HTTP/1.1 allows a client to request that only part (a range of) the
+   response entity be included within the response. HTTP/1.1 uses range
+   units in the Range (section 14.35) and Content-Range (section 14.16)
+   header fields. An entity can be broken down into subranges according
+   to various structural units.
+
+      range-unit       = bytes-unit | other-range-unit
+      bytes-unit       = "bytes"
+      other-range-unit = token
+
+   The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
+   implementations MAY ignore ranges specified using other units.
+
+
+
+Fielding, et al.            Standards Track                    [Page 30]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 has been designed to allow implementations of applications
+   that do not depend on knowledge of ranges.
+
+4 HTTP Message
+
+4.1 Message Types
+
+   HTTP messages consist of requests from client to server and responses
+   from server to client.
+
+       HTTP-message   = Request | Response     ; HTTP/1.1 messages
+
+   Request (section 5) and Response (section 6) messages use the generic
+   message format of RFC 822 [9] for transferring entities (the payload
+   of the message). Both types of message consist of a start-line, zero
+   or more header fields (also known as "headers"), an empty line (i.e.,
+   a line with nothing preceding the CRLF) indicating the end of the
+   header fields, and possibly a message-body.
+
+        generic-message = start-line
+                          *(message-header CRLF)
+                          CRLF
+                          [ message-body ]
+        start-line      = Request-Line | Status-Line
+
+   In the interest of robustness, servers SHOULD ignore any empty
+   line(s) received where a Request-Line is expected. In other words, if
+   the server is reading the protocol stream at the beginning of a
+   message and receives a CRLF first, it should ignore the CRLF.
+
+   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
+   after a POST request. To restate what is explicitly forbidden by the
+   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
+   extra CRLF.
+
+4.2 Message Headers
+
+   HTTP header fields, which include general-header (section 4.5),
+   request-header (section 5.3), response-header (section 6.2), and
+   entity-header (section 7.1) fields, follow the same generic format as
+   that given in Section 3.1 of RFC 822 [9]. Each header field consists
+   of a name followed by a colon (":") and the field value. Field names
+   are case-insensitive. The field value MAY be preceded by any amount
+   of LWS, though a single SP is preferred. Header fields can be
+   extended over multiple lines by preceding each extra line with at
+   least one SP or HT. Applications ought to follow "common form", where
+   one is known or indicated, when generating HTTP constructs, since
+   there might exist some implementations that fail to accept anything
+
+
+
+Fielding, et al.            Standards Track                    [Page 31]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   beyond the common forms.
+
+       message-header = field-name ":" [ field-value ]
+       field-name     = token
+       field-value    = *( field-content | LWS )
+       field-content  = <the OCTETs making up the field-value
+                        and consisting of either *TEXT or combinations
+                        of token, separators, and quoted-string>
+
+   The field-content does not include any leading or trailing LWS:
+   linear white space occurring before the first non-whitespace
+   character of the field-value or after the last non-whitespace
+   character of the field-value. Such leading or trailing LWS MAY be
+   removed without changing the semantics of the field value. Any LWS
+   that occurs between field-content MAY be replaced with a single SP
+   before interpreting the field value or forwarding the message
+   downstream.
+
+   The order in which header fields with differing field names are
+   received is not significant. However, it is "good practice" to send
+   general-header fields first, followed by request-header or response-
+   header fields, and ending with the entity-header fields.
+
+   Multiple message-header fields with the same field-name MAY be
+   present in a message if and only if the entire field-value for that
+   header field is defined as a comma-separated list [i.e., #(values)].
+   It MUST be possible to combine the multiple header fields into one
+   "field-name: field-value" pair, without changing the semantics of the
+   message, by appending each subsequent field-value to the first, each
+   separated by a comma. The order in which header fields with the same
+   field-name are received is therefore significant to the
+   interpretation of the combined field value, and thus a proxy MUST NOT
+   change the order of these field values when a message is forwarded.
+
+4.3 Message Body
+
+   The message-body (if any) of an HTTP message is used to carry the
+   entity-body associated with the request or response. The message-body
+   differs from the entity-body only when a transfer-coding has been
+   applied, as indicated by the Transfer-Encoding header field (section
+   14.41).
+
+       message-body = entity-body
+                    | <entity-body encoded as per Transfer-Encoding>
+
+   Transfer-Encoding MUST be used to indicate any transfer-codings
+   applied by an application to ensure safe and proper transfer of the
+   message. Transfer-Encoding is a property of the message, not of the
+
+
+
+Fielding, et al.            Standards Track                    [Page 32]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   entity, and thus MAY be added or removed by any application along the
+   request/response chain. (However, section 3.6 places restrictions on
+   when certain transfer-codings may be used.)
+
+   The rules for when a message-body is allowed in a message differ for
+   requests and responses.
+
+   The presence of a message-body in a request is signaled by the
+   inclusion of a Content-Length or Transfer-Encoding header field in
+   the request's message-headers. A message-body MUST NOT be included in
+   a request if the specification of the request method (section 5.1.1)
+   does not allow sending an entity-body in requests. A server SHOULD
+   read and forward a message-body on any request; if the request method
+   does not include defined semantics for an entity-body, then the
+   message-body SHOULD be ignored when handling the request.
+
+   For response messages, whether or not a message-body is included with
+   a message is dependent on both the request method and the response
+   status code (section 6.1.1). All responses to the HEAD request method
+   MUST NOT include a message-body, even though the presence of entity-
+   header fields might lead one to believe they do. All 1xx
+   (informational), 204 (no content), and 304 (not modified) responses
+   MUST NOT include a message-body. All other responses do include a
+   message-body, although it MAY be of zero length.
+
+4.4 Message Length
+
+   The transfer-length of a message is the length of the message-body as
+   it appears in the message; that is, after any transfer-codings have
+   been applied. When a message-body is included with a message, the
+   transfer-length of that body is determined by one of the following
+   (in order of precedence):
+
+   1.Any response message which "MUST NOT" include a message-body (such
+     as the 1xx, 204, and 304 responses and any response to a HEAD
+     request) is always terminated by the first empty line after the
+     header fields, regardless of the entity-header fields present in
+     the message.
+
+   2.If a Transfer-Encoding header field (section 14.41) is present and
+     has any value other than "identity", then the transfer-length is
+     defined by use of the "chunked" transfer-coding (section 3.6),
+     unless the message is terminated by closing the connection.
+
+   3.If a Content-Length header field (section 14.13) is present, its
+     decimal value in OCTETs represents both the entity-length and the
+     transfer-length. The Content-Length header field MUST NOT be sent
+     if these two lengths are different (i.e., if a Transfer-Encoding
+
+
+
+Fielding, et al.            Standards Track                    [Page 33]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+     header field is present). If a message is received with both a
+     Transfer-Encoding header field and a Content-Length header field,
+     the latter MUST be ignored.
+
+   4.If the message uses the media type "multipart/byteranges", and the
+     ransfer-length is not otherwise specified, then this self-
+     elimiting media type defines the transfer-length. This media type
+     UST NOT be used unless the sender knows that the recipient can arse
+     it; the presence in a request of a Range header with ultiple byte-
+     range specifiers from a 1.1 client implies that the lient can parse
+     multipart/byteranges responses.
+
+       A range header might be forwarded by a 1.0 proxy that does not
+       understand multipart/byteranges; in this case the server MUST
+       delimit the message using methods defined in items 1,3 or 5 of
+       this section.
+
+   5.By the server closing the connection. (Closing the connection
+     cannot be used to indicate the end of a request body, since that
+     would leave no possibility for the server to send back a response.)
+
+   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
+   containing a message-body MUST include a valid Content-Length header
+   field unless the server is known to be HTTP/1.1 compliant. If a
+   request contains a message-body and a Content-Length is not given,
+   the server SHOULD respond with 400 (bad request) if it cannot
+   determine the length of the message, or with 411 (length required) if
+   it wishes to insist on receiving a valid Content-Length.
+
+   All HTTP/1.1 applications that receive entities MUST accept the
+   "chunked" transfer-coding (section 3.6), thus allowing this mechanism
+   to be used for messages when the message length cannot be determined
+   in advance.
+
+   Messages MUST NOT include both a Content-Length header field and a
+   non-identity transfer-coding. If the message does include a non-
+   identity transfer-coding, the Content-Length MUST be ignored.
+
+   When a Content-Length is given in a message where a message-body is
+   allowed, its field value MUST exactly match the number of OCTETs in
+   the message-body. HTTP/1.1 user agents MUST notify the user when an
+   invalid length is received and detected.
+
+4.5 General Header Fields
+
+   There are a few header fields which have general applicability for
+   both request and response messages, but which do not apply to the
+   entity being transferred. These header fields apply only to the
+
+
+
+Fielding, et al.            Standards Track                    [Page 34]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   message being transmitted.
+
+       general-header = Cache-Control            ; Section 14.9
+                      | Connection               ; Section 14.10
+                      | Date                     ; Section 14.18
+                      | Pragma                   ; Section 14.32
+                      | Trailer                  ; Section 14.40
+                      | Transfer-Encoding        ; Section 14.41
+                      | Upgrade                  ; Section 14.42
+                      | Via                      ; Section 14.45
+                      | Warning                  ; Section 14.46
+
+   General-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields may be given the semantics of general
+   header fields if all parties in the communication recognize them to
+   be general-header fields. Unrecognized header fields are treated as
+   entity-header fields.
+
+5 Request
+
+   A request message from a client to a server includes, within the
+   first line of that message, the method to be applied to the resource,
+   the identifier of the resource, and the protocol version in use.
+
+        Request       = Request-Line              ; Section 5.1
+                        *(( general-header        ; Section 4.5
+                         | request-header         ; Section 5.3
+                         | entity-header ) CRLF)  ; Section 7.1
+                        CRLF
+                        [ message-body ]          ; Section 4.3
+
+5.1 Request-Line
+
+   The Request-Line begins with a method token, followed by the
+   Request-URI and the protocol version, and ending with CRLF. The
+   elements are separated by SP characters. No CR or LF is allowed
+   except in the final CRLF sequence.
+
+        Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 35]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+5.1.1 Method
+
+   The Method  token indicates the method to be performed on the
+   resource identified by the Request-URI. The method is case-sensitive.
+
+       Method         = "OPTIONS"                ; Section 9.2
+                      | "GET"                    ; Section 9.3
+                      | "HEAD"                   ; Section 9.4
+                      | "POST"                   ; Section 9.5
+                      | "PUT"                    ; Section 9.6
+                      | "DELETE"                 ; Section 9.7
+                      | "TRACE"                  ; Section 9.8
+                      | "CONNECT"                ; Section 9.9
+                      | extension-method
+       extension-method = token
+
+   The list of methods allowed by a resource can be specified in an
+   Allow header field (section 14.7). The return code of the response
+   always notifies the client whether a method is currently allowed on a
+   resource, since the set of allowed methods can change dynamically. An
+   origin server SHOULD return the status code 405 (Method Not Allowed)
+   if the method is known by the origin server but not allowed for the
+   requested resource, and 501 (Not Implemented) if the method is
+   unrecognized or not implemented by the origin server. The methods GET
+   and HEAD MUST be supported by all general-purpose servers. All other
+   methods are OPTIONAL; however, if the above methods are implemented,
+   they MUST be implemented with the same semantics as those specified
+   in section 9.
+
+5.1.2 Request-URI
+
+   The Request-URI is a Uniform Resource Identifier (section 3.2) and
+   identifies the resource upon which to apply the request.
+
+       Request-URI    = "*" | absoluteURI | abs_path | authority
+
+   The four options for Request-URI are dependent on the nature of the
+   request. The asterisk "*" means that the request does not apply to a
+   particular resource, but to the server itself, and is only allowed
+   when the method used does not necessarily apply to a resource. One
+   example would be
+
+       OPTIONS * HTTP/1.1
+
+   The absoluteURI form is REQUIRED when the request is being made to a
+   proxy. The proxy is requested to forward the request or service it
+   from a valid cache, and return the response. Note that the proxy MAY
+   forward the request on to another proxy or directly to the server
+
+
+
+Fielding, et al.            Standards Track                    [Page 36]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   specified by the absoluteURI. In order to avoid request loops, a
+   proxy MUST be able to recognize all of its server names, including
+   any aliases, local variations, and the numeric IP address. An example
+   Request-Line would be:
+
+       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+
+   To allow for transition to absoluteURIs in all requests in future
+   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
+   form in requests, even though HTTP/1.1 clients will only generate
+   them in requests to proxies.
+
+   The authority form is only used by the CONNECT method (section 9.9).
+
+   The most common form of Request-URI is that used to identify a
+   resource on an origin server or gateway. In this case the absolute
+   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
+   the Request-URI, and the network location of the URI (authority) MUST
+   be transmitted in a Host header field. For example, a client wishing
+   to retrieve the resource above directly from the origin server would
+   create a TCP connection to port 80 of the host "www.w3.org" and send
+   the lines:
+
+       GET /pub/WWW/TheProject.html HTTP/1.1
+       Host: www.w3.org
+
+   followed by the remainder of the Request. Note that the absolute path
+   cannot be empty; if none is present in the original URI, it MUST be
+   given as "/" (the server root).
+
+   The Request-URI is transmitted in the format specified in section
+   3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
+   [42], the origin server MUST decode the Request-URI in order to
+   properly interpret the request. Servers SHOULD respond to invalid
+   Request-URIs with an appropriate status code.
+
+   A transparent proxy MUST NOT rewrite the "abs_path" part of the
+   received Request-URI when forwarding it to the next inbound server,
+   except as noted above to replace a null abs_path with "/".
+
+      Note: The "no rewrite" rule prevents the proxy from changing the
+      meaning of the request when the origin server is improperly using
+      a non-reserved URI character for a reserved purpose.  Implementors
+      should be aware that some pre-HTTP/1.1 proxies have been known to
+      rewrite the Request-URI.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 37]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+5.2 The Resource Identified by a Request
+
+   The exact resource identified by an Internet request is determined by
+   examining both the Request-URI and the Host header field.
+
+   An origin server that does not allow resources to differ by the
+   requested host MAY ignore the Host header field value when
+   determining the resource identified by an HTTP/1.1 request. (But see
+   section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
+
+   An origin server that does differentiate resources based on the host
+   requested (sometimes referred to as virtual hosts or vanity host
+   names) MUST use the following rules for determining the requested
+   resource on an HTTP/1.1 request:
+
+   1. If Request-URI is an absoluteURI, the host is part of the
+     Request-URI. Any Host header field value in the request MUST be
+     ignored.
+
+   2. If the Request-URI is not an absoluteURI, and the request includes
+     a Host header field, the host is determined by the Host header
+     field value.
+
+   3. If the host as determined by rule 1 or 2 is not a valid host on
+     the server, the response MUST be a 400 (Bad Request) error message.
+
+   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
+   attempt to use heuristics (e.g., examination of the URI path for
+   something unique to a particular host) in order to determine what
+   exact resource is being requested.
+
+5.3 Request Header Fields
+
+   The request-header fields allow the client to pass additional
+   information about the request, and about the client itself, to the
+   server. These fields act as request modifiers, with semantics
+   equivalent to the parameters on a programming language method
+   invocation.
+
+       request-header = Accept                   ; Section 14.1
+                      | Accept-Charset           ; Section 14.2
+                      | Accept-Encoding          ; Section 14.3
+                      | Accept-Language          ; Section 14.4
+                      | Authorization            ; Section 14.8
+                      | Expect                   ; Section 14.20
+                      | From                     ; Section 14.22
+                      | Host                     ; Section 14.23
+                      | If-Match                 ; Section 14.24
+
+
+
+Fielding, et al.            Standards Track                    [Page 38]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                      | If-Modified-Since        ; Section 14.25
+                      | If-None-Match            ; Section 14.26
+                      | If-Range                 ; Section 14.27
+                      | If-Unmodified-Since      ; Section 14.28
+                      | Max-Forwards             ; Section 14.31
+                      | Proxy-Authorization      ; Section 14.34
+                      | Range                    ; Section 14.35
+                      | Referer                  ; Section 14.36
+                      | TE                       ; Section 14.39
+                      | User-Agent               ; Section 14.43
+
+   Request-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields MAY be given the semantics of request-
+   header fields if all parties in the communication recognize them to
+   be request-header fields. Unrecognized header fields are treated as
+   entity-header fields.
+
+6 Response
+
+   After receiving and interpreting a request message, a server responds
+   with an HTTP response message.
+
+       Response      = Status-Line               ; Section 6.1
+                       *(( general-header        ; Section 4.5
+                        | response-header        ; Section 6.2
+                        | entity-header ) CRLF)  ; Section 7.1
+                       CRLF
+                       [ message-body ]          ; Section 7.2
+
+6.1 Status-Line
+
+   The first line of a Response message is the Status-Line, consisting
+   of the protocol version followed by a numeric status code and its
+   associated textual phrase, with each element separated by SP
+   characters. No CR or LF is allowed except in the final CRLF sequence.
+
+       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+
+6.1.1 Status Code and Reason Phrase
+
+   The Status-Code element is a 3-digit integer result code of the
+   attempt to understand and satisfy the request. These codes are fully
+   defined in section 10. The Reason-Phrase is intended to give a short
+   textual description of the Status-Code. The Status-Code is intended
+   for use by automata and the Reason-Phrase is intended for the human
+   user. The client is not required to examine or display the Reason-
+   Phrase.
+
+
+
+Fielding, et al.            Standards Track                    [Page 39]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The first digit of the Status-Code defines the class of response. The
+   last two digits do not have any categorization role. There are 5
+   values for the first digit:
+
+      - 1xx: Informational - Request received, continuing process
+
+      - 2xx: Success - The action was successfully received,
+        understood, and accepted
+
+      - 3xx: Redirection - Further action must be taken in order to
+        complete the request
+
+      - 4xx: Client Error - The request contains bad syntax or cannot
+        be fulfilled
+
+      - 5xx: Server Error - The server failed to fulfill an apparently
+        valid request
+
+   The individual values of the numeric status codes defined for
+   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
+   presented below. The reason phrases listed here are only
+   recommendations -- they MAY be replaced by local equivalents without
+   affecting the protocol.
+
+      Status-Code    =
+            "100"  ; Section 10.1.1: Continue
+          | "101"  ; Section 10.1.2: Switching Protocols
+          | "200"  ; Section 10.2.1: OK
+          | "201"  ; Section 10.2.2: Created
+          | "202"  ; Section 10.2.3: Accepted
+          | "203"  ; Section 10.2.4: Non-Authoritative Information
+          | "204"  ; Section 10.2.5: No Content
+          | "205"  ; Section 10.2.6: Reset Content
+          | "206"  ; Section 10.2.7: Partial Content
+          | "300"  ; Section 10.3.1: Multiple Choices
+          | "301"  ; Section 10.3.2: Moved Permanently
+          | "302"  ; Section 10.3.3: Found
+          | "303"  ; Section 10.3.4: See Other
+          | "304"  ; Section 10.3.5: Not Modified
+          | "305"  ; Section 10.3.6: Use Proxy
+          | "307"  ; Section 10.3.8: Temporary Redirect
+          | "400"  ; Section 10.4.1: Bad Request
+          | "401"  ; Section 10.4.2: Unauthorized
+          | "402"  ; Section 10.4.3: Payment Required
+          | "403"  ; Section 10.4.4: Forbidden
+          | "404"  ; Section 10.4.5: Not Found
+          | "405"  ; Section 10.4.6: Method Not Allowed
+          | "406"  ; Section 10.4.7: Not Acceptable
+
+
+
+Fielding, et al.            Standards Track                    [Page 40]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+          | "407"  ; Section 10.4.8: Proxy Authentication Required
+          | "408"  ; Section 10.4.9: Request Time-out
+          | "409"  ; Section 10.4.10: Conflict
+          | "410"  ; Section 10.4.11: Gone
+          | "411"  ; Section 10.4.12: Length Required
+          | "412"  ; Section 10.4.13: Precondition Failed
+          | "413"  ; Section 10.4.14: Request Entity Too Large
+          | "414"  ; Section 10.4.15: Request-URI Too Large
+          | "415"  ; Section 10.4.16: Unsupported Media Type
+          | "416"  ; Section 10.4.17: Requested range not satisfiable
+          | "417"  ; Section 10.4.18: Expectation Failed
+          | "500"  ; Section 10.5.1: Internal Server Error
+          | "501"  ; Section 10.5.2: Not Implemented
+          | "502"  ; Section 10.5.3: Bad Gateway
+          | "503"  ; Section 10.5.4: Service Unavailable
+          | "504"  ; Section 10.5.5: Gateway Time-out
+          | "505"  ; Section 10.5.6: HTTP Version not supported
+          | extension-code
+
+      extension-code = 3DIGIT
+      Reason-Phrase  = *<TEXT, excluding CR, LF>
+
+   HTTP status codes are extensible. HTTP applications are not required
+   to understand the meaning of all registered status codes, though such
+   understanding is obviously desirable. However, applications MUST
+   understand the class of any status code, as indicated by the first
+   digit, and treat any unrecognized response as being equivalent to the
+   x00 status code of that class, with the exception that an
+   unrecognized response MUST NOT be cached. For example, if an
+   unrecognized status code of 431 is received by the client, it can
+   safely assume that there was something wrong with its request and
+   treat the response as if it had received a 400 status code. In such
+   cases, user agents SHOULD present to the user the entity returned
+   with the response, since that entity is likely to include human-
+   readable information which will explain the unusual status.
+
+6.2 Response Header Fields
+
+   The response-header fields allow the server to pass additional
+   information about the response which cannot be placed in the Status-
+   Line. These header fields give information about the server and about
+   further access to the resource identified by the Request-URI.
+
+       response-header = Accept-Ranges           ; Section 14.5
+                       | Age                     ; Section 14.6
+                       | ETag                    ; Section 14.19
+                       | Location                ; Section 14.30
+                       | Proxy-Authenticate      ; Section 14.33
+
+
+
+Fielding, et al.            Standards Track                    [Page 41]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                       | Retry-After             ; Section 14.37
+                       | Server                  ; Section 14.38
+                       | Vary                    ; Section 14.44
+                       | WWW-Authenticate        ; Section 14.47
+
+   Response-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields MAY be given the semantics of response-
+   header fields if all parties in the communication recognize them to
+   be response-header fields. Unrecognized header fields are treated as
+   entity-header fields.
+
+7 Entity
+
+   Request and Response messages MAY transfer an entity if not otherwise
+   restricted by the request method or response status code. An entity
+   consists of entity-header fields and an entity-body, although some
+   responses will only include the entity-headers.
+
+   In this section, both sender and recipient refer to either the client
+   or the server, depending on who sends and who receives the entity.
+
+7.1 Entity Header Fields
+
+   Entity-header fields define metainformation about the entity-body or,
+   if no body is present, about the resource identified by the request.
+   Some of this metainformation is OPTIONAL; some might be REQUIRED by
+   portions of this specification.
+
+       entity-header  = Allow                    ; Section 14.7
+                      | Content-Encoding         ; Section 14.11
+                      | Content-Language         ; Section 14.12
+                      | Content-Length           ; Section 14.13
+                      | Content-Location         ; Section 14.14
+                      | Content-MD5              ; Section 14.15
+                      | Content-Range            ; Section 14.16
+                      | Content-Type             ; Section 14.17
+                      | Expires                  ; Section 14.21
+                      | Last-Modified            ; Section 14.29
+                      | extension-header
+
+       extension-header = message-header
+
+   The extension-header mechanism allows additional entity-header fields
+   to be defined without changing the protocol, but these fields cannot
+   be assumed to be recognizable by the recipient. Unrecognized header
+   fields SHOULD be ignored by the recipient and MUST be forwarded by
+   transparent proxies.
+
+
+
+Fielding, et al.            Standards Track                    [Page 42]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+7.2 Entity Body
+
+   The entity-body (if any) sent with an HTTP request or response is in
+   a format and encoding defined by the entity-header fields.
+
+       entity-body    = *OCTET
+
+   An entity-body is only present in a message when a message-body is
+   present, as described in section 4.3. The entity-body is obtained
+   from the message-body by decoding any Transfer-Encoding that might
+   have been applied to ensure safe and proper transfer of the message.
+
+7.2.1 Type
+
+   When an entity-body is included with a message, the data type of that
+   body is determined via the header fields Content-Type and Content-
+   Encoding. These define a two-layer, ordered encoding model:
+
+       entity-body := Content-Encoding( Content-Type( data ) )
+
+   Content-Type specifies the media type of the underlying data.
+   Content-Encoding may be used to indicate any additional content
+   codings applied to the data, usually for the purpose of data
+   compression, that are a property of the requested resource. There is
+   no default encoding.
+
+   Any HTTP/1.1 message containing an entity-body SHOULD include a
+   Content-Type header field defining the media type of that body. If
+   and only if the media type is not given by a Content-Type field, the
+   recipient MAY attempt to guess the media type via inspection of its
+   content and/or the name extension(s) of the URI used to identify the
+   resource. If the media type remains unknown, the recipient SHOULD
+   treat it as type "application/octet-stream".
+
+7.2.2 Entity Length
+
+   The entity-length of a message is the length of the message-body
+   before any transfer-codings have been applied. Section 4.4 defines
+   how the transfer-length of a message-body is determined.
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 43]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8 Connections
+
+8.1 Persistent Connections
+
+8.1.1 Purpose
+
+   Prior to persistent connections, a separate TCP connection was
+   established to fetch each URL, increasing the load on HTTP servers
+   and causing congestion on the Internet. The use of inline images and
+   other associated data often require a client to make multiple
+   requests of the same server in a short amount of time. Analysis of
+   these performance problems and results from a prototype
+   implementation are available [26] [30]. Implementation experience and
+   measurements of actual HTTP/1.1 (RFC 2068) implementations show good
+   results [39]. Alternatives have also been explored, for example,
+   T/TCP [27].
+
+   Persistent HTTP connections have a number of advantages:
+
+      - By opening and closing fewer TCP connections, CPU time is saved
+        in routers and hosts (clients, servers, proxies, gateways,
+        tunnels, or caches), and memory used for TCP protocol control
+        blocks can be saved in hosts.
+
+      - HTTP requests and responses can be pipelined on a connection.
+        Pipelining allows a client to make multiple requests without
+        waiting for each response, allowing a single TCP connection to
+        be used much more efficiently, with much lower elapsed time.
+
+      - Network congestion is reduced by reducing the number of packets
+        caused by TCP opens, and by allowing TCP sufficient time to
+        determine the congestion state of the network.
+
+      - Latency on subsequent requests is reduced since there is no time
+        spent in TCP's connection opening handshake.
+
+      - HTTP can evolve more gracefully, since errors can be reported
+        without the penalty of closing the TCP connection. Clients using
+        future versions of HTTP might optimistically try a new feature,
+        but if communicating with an older server, retry with old
+        semantics after an error is reported.
+
+   HTTP implementations SHOULD implement persistent connections.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 44]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.1.2 Overall Operation
+
+   A significant difference between HTTP/1.1 and earlier versions of
+   HTTP is that persistent connections are the default behavior of any
+   HTTP connection. That is, unless otherwise indicated, the client
+   SHOULD assume that the server will maintain a persistent connection,
+   even after error responses from the server.
+
+   Persistent connections provide a mechanism by which a client and a
+   server can signal the close of a TCP connection. This signaling takes
+   place using the Connection header field (section 14.10). Once a close
+   has been signaled, the client MUST NOT send any more requests on that
+   connection.
+
+8.1.2.1 Negotiation
+
+   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
+   maintain a persistent connection unless a Connection header including
+   the connection-token "close" was sent in the request. If the server
+   chooses to close the connection immediately after sending the
+   response, it SHOULD send a Connection header including the
+   connection-token close.
+
+   An HTTP/1.1 client MAY expect a connection to remain open, but would
+   decide to keep it open based on whether the response from a server
+   contains a Connection header with the connection-token close. In case
+   the client does not want to maintain a connection for more than that
+   request, it SHOULD send a Connection header including the
+   connection-token close.
+
+   If either the client or the server sends the close token in the
+   Connection header, that request becomes the last one for the
+   connection.
+
+   Clients and servers SHOULD NOT assume that a persistent connection is
+   maintained for HTTP versions less than 1.1 unless it is explicitly
+   signaled. See section 19.6.2 for more information on backward
+   compatibility with HTTP/1.0 clients.
+
+   In order to remain persistent, all messages on the connection MUST
+   have a self-defined message length (i.e., one not defined by closure
+   of the connection), as described in section 4.4.
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 45]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.1.2.2 Pipelining
+
+   A client that supports persistent connections MAY "pipeline" its
+   requests (i.e., send multiple requests without waiting for each
+   response). A server MUST send its responses to those requests in the
+   same order that the requests were received.
+
+   Clients which assume persistent connections and pipeline immediately
+   after connection establishment SHOULD be prepared to retry their
+   connection if the first pipelined attempt fails. If a client does
+   such a retry, it MUST NOT pipeline before it knows the connection is
+   persistent. Clients MUST also be prepared to resend their requests if
+   the server closes the connection before sending all of the
+   corresponding responses.
+
+   Clients SHOULD NOT pipeline requests using non-idempotent methods or
+   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
+   premature termination of the transport connection could lead to
+   indeterminate results. A client wishing to send a non-idempotent
+   request SHOULD wait to send that request until it has received the
+   response status for the previous request.
+
+8.1.3 Proxy Servers
+
+   It is especially important that proxies correctly implement the
+   properties of the Connection header field as specified in section
+   14.10.
+
+   The proxy server MUST signal persistent connections separately with
+   its clients and the origin servers (or other proxy servers) that it
+   connects to. Each persistent connection applies to only one transport
+   link.
+
+   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
+   with an HTTP/1.0 client (but see RFC 2068 [33] for information and
+   discussion of the problems with the Keep-Alive header implemented by
+   many HTTP/1.0 clients).
+
+8.1.4 Practical Considerations
+
+   Servers will usually have some time-out value beyond which they will
+   no longer maintain an inactive connection. Proxy servers might make
+   this a higher value since it is likely that the client will be making
+   more connections through the same server. The use of persistent
+   connections places no requirements on the length (or existence) of
+   this time-out for either the client or the server.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 46]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   When a client or server wishes to time-out it SHOULD issue a graceful
+   close on the transport connection. Clients and servers SHOULD both
+   constantly watch for the other side of the transport close, and
+   respond to it as appropriate. If a client or server does not detect
+   the other side's close promptly it could cause unnecessary resource
+   drain on the network.
+
+   A client, server, or proxy MAY close the transport connection at any
+   time. For example, a client might have started to send a new request
+   at the same time that the server has decided to close the "idle"
+   connection. From the server's point of view, the connection is being
+   closed while it was idle, but from the client's point of view, a
+   request is in progress.
+
+   This means that clients, servers, and proxies MUST be able to recover
+   from asynchronous close events. Client software SHOULD reopen the
+   transport connection and retransmit the aborted sequence of requests
+   without user interaction so long as the request sequence is
+   idempotent (see section 9.1.2). Non-idempotent methods or sequences
+   MUST NOT be automatically retried, although user agents MAY offer a
+   human operator the choice of retrying the request(s). Confirmation by
+   user-agent software with semantic understanding of the application
+   MAY substitute for user confirmation. The automatic retry SHOULD NOT
+   be repeated if the second sequence of requests fails.
+
+   Servers SHOULD always respond to at least one request per connection,
+   if at all possible. Servers SHOULD NOT close a connection in the
+   middle of transmitting a response, unless a network or client failure
+   is suspected.
+
+   Clients that use persistent connections SHOULD limit the number of
+   simultaneous connections that they maintain to a given server. A
+   single-user client SHOULD NOT maintain more than 2 connections with
+   any server or proxy. A proxy SHOULD use up to 2*N connections to
+   another server or proxy, where N is the number of simultaneously
+   active users. These guidelines are intended to improve HTTP response
+   times and avoid congestion.
+
+8.2 Message Transmission Requirements
+
+8.2.1 Persistent Connections and Flow Control
+
+   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
+   flow control mechanisms to resolve temporary overloads, rather than
+   terminating connections with the expectation that clients will retry.
+   The latter technique can exacerbate network congestion.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 47]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.2.2 Monitoring Connections for Error Status Messages
+
+   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
+   the network connection for an error status while it is transmitting
+   the request. If the client sees an error status, it SHOULD
+   immediately cease transmitting the body. If the body is being sent
+   using a "chunked" encoding (section 3.6), a zero length chunk and
+   empty trailer MAY be used to prematurely mark the end of the message.
+   If the body was preceded by a Content-Length header, the client MUST
+   close the connection.
+
+8.2.3 Use of the 100 (Continue) Status
+
+   The purpose of the 100 (Continue) status (see section 10.1.1) is to
+   allow a client that is sending a request message with a request body
+   to determine if the origin server is willing to accept the request
+   (based on the request headers) before the client sends the request
+   body. In some cases, it might either be inappropriate or highly
+   inefficient for the client to send the body if the server will reject
+   the message without looking at the body.
+
+   Requirements for HTTP/1.1 clients:
+
+      - If a client will wait for a 100 (Continue) response before
+        sending the request body, it MUST send an Expect request-header
+        field (section 14.20) with the "100-continue" expectation.
+
+      - A client MUST NOT send an Expect request-header field (section
+        14.20) with the "100-continue" expectation if it does not intend
+        to send a request body.
+
+   Because of the presence of older implementations, the protocol allows
+   ambiguous situations in which a client may send "Expect: 100-
+   continue" without receiving either a 417 (Expectation Failed) status
+   or a 100 (Continue) status. Therefore, when a client sends this
+   header field to an origin server (possibly via a proxy) from which it
+   has never seen a 100 (Continue) status, the client SHOULD NOT wait
+   for an indefinite period before sending the request body.
+
+   Requirements for HTTP/1.1 origin servers:
+
+      - Upon receiving a request which includes an Expect request-header
+        field with the "100-continue" expectation, an origin server MUST
+        either respond with 100 (Continue) status and continue to read
+        from the input stream, or respond with a final status code. The
+        origin server MUST NOT wait for the request body before sending
+        the 100 (Continue) response. If it responds with a final status
+        code, it MAY close the transport connection or it MAY continue
+
+
+
+Fielding, et al.            Standards Track                    [Page 48]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+        to read and discard the rest of the request.  It MUST NOT
+        perform the requested method if it returns a final status code.
+
+      - An origin server SHOULD NOT send a 100 (Continue) response if
+        the request message does not include an Expect request-header
+        field with the "100-continue" expectation, and MUST NOT send a
+        100 (Continue) response if such a request comes from an HTTP/1.0
+        (or earlier) client. There is an exception to this rule: for
+        compatibility with RFC 2068, a server MAY send a 100 (Continue)
+        status in response to an HTTP/1.1 PUT or POST request that does
+        not include an Expect request-header field with the "100-
+        continue" expectation. This exception, the purpose of which is
+        to minimize any client processing delays associated with an
+        undeclared wait for 100 (Continue) status, applies only to
+        HTTP/1.1 requests, and not to requests with any other HTTP-
+        version value.
+
+      - An origin server MAY omit a 100 (Continue) response if it has
+        already received some or all of the request body for the
+        corresponding request.
+
+      - An origin server that sends a 100 (Continue) response MUST
+        ultimately send a final status code, once the request body is
+        received and processed, unless it terminates the transport
+        connection prematurely.
+
+      - If an origin server receives a request that does not include an
+        Expect request-header field with the "100-continue" expectation,
+        the request includes a request body, and the server responds
+        with a final status code before reading the entire request body
+        from the transport connection, then the server SHOULD NOT close
+        the transport connection until it has read the entire request,
+        or until the client closes the connection. Otherwise, the client
+        might not reliably receive the response message. However, this
+        requirement is not be construed as preventing a server from
+        defending itself against denial-of-service attacks, or from
+        badly broken client implementations.
+
+   Requirements for HTTP/1.1 proxies:
+
+      - If a proxy receives a request that includes an Expect request-
+        header field with the "100-continue" expectation, and the proxy
+        either knows that the next-hop server complies with HTTP/1.1 or
+        higher, or does not know the HTTP version of the next-hop
+        server, it MUST forward the request, including the Expect header
+        field.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 49]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - If the proxy knows that the version of the next-hop server is
+        HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
+        respond with a 417 (Expectation Failed) status.
+
+      - Proxies SHOULD maintain a cache recording the HTTP version
+        numbers received from recently-referenced next-hop servers.
+
+      - A proxy MUST NOT forward a 100 (Continue) response if the
+        request message was received from an HTTP/1.0 (or earlier)
+        client and did not include an Expect request-header field with
+        the "100-continue" expectation. This requirement overrides the
+        general rule for forwarding of 1xx responses (see section 10.1).
+
+8.2.4 Client Behavior if Server Prematurely Closes Connection
+
+   If an HTTP/1.1 client sends a request which includes a request body,
+   but which does not include an Expect request-header field with the
+   "100-continue" expectation, and if the client is not directly
+   connected to an HTTP/1.1 origin server, and if the client sees the
+   connection close before receiving any status from the server, the
+   client SHOULD retry the request.  If the client does retry this
+   request, it MAY use the following "binary exponential backoff"
+   algorithm to be assured of obtaining a reliable response:
+
+      1. Initiate a new connection to the server
+
+      2. Transmit the request-headers
+
+      3. Initialize a variable R to the estimated round-trip time to the
+         server (e.g., based on the time it took to establish the
+         connection), or to a constant value of 5 seconds if the round-
+         trip time is not available.
+
+      4. Compute T = R * (2**N), where N is the number of previous
+         retries of this request.
+
+      5. Wait either for an error response from the server, or for T
+         seconds (whichever comes first)
+
+      6. If no error response is received, after T seconds transmit the
+         body of the request.
+
+      7. If client sees that the connection is closed prematurely,
+         repeat from step 1 until the request is accepted, an error
+         response is received, or the user becomes impatient and
+         terminates the retry process.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 50]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If at any point an error status is received, the client
+
+      - SHOULD NOT continue and
+
+      - SHOULD close the connection if it has not completed sending the
+        request message.
+
+9 Method Definitions
+
+   The set of common methods for HTTP/1.1 is defined below. Although
+   this set can be expanded, additional methods cannot be assumed to
+   share the same semantics for separately extended clients and servers.
+
+   The Host request-header field (section 14.23) MUST accompany all
+   HTTP/1.1 requests.
+
+9.1 Safe and Idempotent Methods
+
+9.1.1 Safe Methods
+
+   Implementors should be aware that the software represents the user in
+   their interactions over the Internet, and should be careful to allow
+   the user to be aware of any actions they might take which may have an
+   unexpected significance to themselves or others.
+
+   In particular, the convention has been established that the GET and
+   HEAD methods SHOULD NOT have the significance of taking an action
+   other than retrieval. These methods ought to be considered "safe".
+   This allows user agents to represent other methods, such as POST, PUT
+   and DELETE, in a special way, so that the user is made aware of the
+   fact that a possibly unsafe action is being requested.
+
+   Naturally, it is not possible to ensure that the server does not
+   generate side-effects as a result of performing a GET request; in
+   fact, some dynamic resources consider that a feature. The important
+   distinction here is that the user did not request the side-effects,
+   so therefore cannot be held accountable for them.
+
+9.1.2 Idempotent Methods
+
+   Methods can also have the property of "idempotence" in that (aside
+   from error or expiration issues) the side-effects of N > 0 identical
+   requests is the same as for a single request. The methods GET, HEAD,
+   PUT and DELETE share this property. Also, the methods OPTIONS and
+   TRACE SHOULD NOT have side effects, and so are inherently idempotent.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 51]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   However, it is possible that a sequence of several requests is non-
+   idempotent, even if all of the methods executed in that sequence are
+   idempotent. (A sequence is idempotent if a single execution of the
+   entire sequence always yields a result that is not changed by a
+   reexecution of all, or part, of that sequence.) For example, a
+   sequence is non-idempotent if its result depends on a value that is
+   later modified in the same sequence.
+
+   A sequence that never has side effects is idempotent, by definition
+   (provided that no concurrent operations are being executed on the
+   same set of resources).
+
+9.2 OPTIONS
+
+   The OPTIONS method represents a request for information about the
+   communication options available on the request/response chain
+   identified by the Request-URI. This method allows the client to
+   determine the options and/or requirements associated with a resource,
+   or the capabilities of a server, without implying a resource action
+   or initiating a resource retrieval.
+
+   Responses to this method are not cacheable.
+
+   If the OPTIONS request includes an entity-body (as indicated by the
+   presence of Content-Length or Transfer-Encoding), then the media type
+   MUST be indicated by a Content-Type field. Although this
+   specification does not define any use for such a body, future
+   extensions to HTTP might use the OPTIONS body to make more detailed
+   queries on the server. A server that does not support such an
+   extension MAY discard the request body.
+
+   If the Request-URI is an asterisk ("*"), the OPTIONS request is
+   intended to apply to the server in general rather than to a specific
+   resource. Since a server's communication options typically depend on
+   the resource, the "*" request is only useful as a "ping" or "no-op"
+   type of method; it does nothing beyond allowing the client to test
+   the capabilities of the server. For example, this can be used to test
+   a proxy for HTTP/1.1 compliance (or lack thereof).
+
+   If the Request-URI is not an asterisk, the OPTIONS request applies
+   only to the options that are available when communicating with that
+   resource.
+
+   A 200 response SHOULD include any header fields that indicate
+   optional features implemented by the server and applicable to that
+   resource (e.g., Allow), possibly including extensions not defined by
+   this specification. The response body, if any, SHOULD also include
+   information about the communication options. The format for such a
+
+
+
+Fielding, et al.            Standards Track                    [Page 52]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   body is not defined by this specification, but might be defined by
+   future extensions to HTTP. Content negotiation MAY be used to select
+   the appropriate response format. If no response body is included, the
+   response MUST include a Content-Length field with a field-value of
+   "0".
+
+   The Max-Forwards request-header field MAY be used to target a
+   specific proxy in the request chain. When a proxy receives an OPTIONS
+   request on an absoluteURI for which request forwarding is permitted,
+   the proxy MUST check for a Max-Forwards field. If the Max-Forwards
+   field-value is zero ("0"), the proxy MUST NOT forward the message;
+   instead, the proxy SHOULD respond with its own communication options.
+   If the Max-Forwards field-value is an integer greater than zero, the
+   proxy MUST decrement the field-value when it forwards the request. If
+   no Max-Forwards field is present in the request, then the forwarded
+   request MUST NOT include a Max-Forwards field.
+
+9.3 GET
+
+   The GET method means retrieve whatever information (in the form of an
+   entity) is identified by the Request-URI. If the Request-URI refers
+   to a data-producing process, it is the produced data which shall be
+   returned as the entity in the response and not the source text of the
+   process, unless that text happens to be the output of the process.
+
+   The semantics of the GET method change to a "conditional GET" if the
+   request message includes an If-Modified-Since, If-Unmodified-Since,
+   If-Match, If-None-Match, or If-Range header field. A conditional GET
+   method requests that the entity be transferred only under the
+   circumstances described by the conditional header field(s). The
+   conditional GET method is intended to reduce unnecessary network
+   usage by allowing cached entities to be refreshed without requiring
+   multiple requests or transferring data already held by the client.
+
+   The semantics of the GET method change to a "partial GET" if the
+   request message includes a Range header field. A partial GET requests
+   that only part of the entity be transferred, as described in section
+   14.35. The partial GET method is intended to reduce unnecessary
+   network usage by allowing partially-retrieved entities to be
+   completed without transferring data already held by the client.
+
+   The response to a GET request is cacheable if and only if it meets
+   the requirements for HTTP caching described in section 13.
+
+   See section 15.1.3 for security considerations when used for forms.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 53]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+9.4 HEAD
+
+   The HEAD method is identical to GET except that the server MUST NOT
+   return a message-body in the response. The metainformation contained
+   in the HTTP headers in response to a HEAD request SHOULD be identical
+   to the information sent in response to a GET request. This method can
+   be used for obtaining metainformation about the entity implied by the
+   request without transferring the entity-body itself. This method is
+   often used for testing hypertext links for validity, accessibility,
+   and recent modification.
+
+   The response to a HEAD request MAY be cacheable in the sense that the
+   information contained in the response MAY be used to update a
+   previously cached entity from that resource. If the new field values
+   indicate that the cached entity differs from the current entity (as
+   would be indicated by a change in Content-Length, Content-MD5, ETag
+   or Last-Modified), then the cache MUST treat the cache entry as
+   stale.
+
+9.5 POST
+
+   The POST method is used to request that the origin server accept the
+   entity enclosed in the request as a new subordinate of the resource
+   identified by the Request-URI in the Request-Line. POST is designed
+   to allow a uniform method to cover the following functions:
+
+      - Annotation of existing resources;
+
+      - Posting a message to a bulletin board, newsgroup, mailing list,
+        or similar group of articles;
+
+      - Providing a block of data, such as the result of submitting a
+        form, to a data-handling process;
+
+      - Extending a database through an append operation.
+
+   The actual function performed by the POST method is determined by the
+   server and is usually dependent on the Request-URI. The posted entity
+   is subordinate to that URI in the same way that a file is subordinate
+   to a directory containing it, a news article is subordinate to a
+   newsgroup to which it is posted, or a record is subordinate to a
+   database.
+
+   The action performed by the POST method might not result in a
+   resource that can be identified by a URI. In this case, either 200
+   (OK) or 204 (No Content) is the appropriate response status,
+   depending on whether or not the response includes an entity that
+   describes the result.
+
+
+
+Fielding, et al.            Standards Track                    [Page 54]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If a resource has been created on the origin server, the response
+   SHOULD be 201 (Created) and contain an entity which describes the
+   status of the request and refers to the new resource, and a Location
+   header (see section 14.30).
+
+   Responses to this method are not cacheable, unless the response
+   includes appropriate Cache-Control or Expires header fields. However,
+   the 303 (See Other) response can be used to direct the user agent to
+   retrieve a cacheable resource.
+
+   POST requests MUST obey the message transmission requirements set out
+   in section 8.2.
+
+   See section 15.1.3 for security considerations.
+
+9.6 PUT
+
+   The PUT method requests that the enclosed entity be stored under the
+   supplied Request-URI. If the Request-URI refers to an already
+   existing resource, the enclosed entity SHOULD be considered as a
+   modified version of the one residing on the origin server. If the
+   Request-URI does not point to an existing resource, and that URI is
+   capable of being defined as a new resource by the requesting user
+   agent, the origin server can create the resource with that URI. If a
+   new resource is created, the origin server MUST inform the user agent
+   via the 201 (Created) response. If an existing resource is modified,
+   either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
+   to indicate successful completion of the request. If the resource
+   could not be created or modified with the Request-URI, an appropriate
+   error response SHOULD be given that reflects the nature of the
+   problem. The recipient of the entity MUST NOT ignore any Content-*
+   (e.g. Content-Range) headers that it does not understand or implement
+   and MUST return a 501 (Not Implemented) response in such cases.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries SHOULD be
+   treated as stale. Responses to this method are not cacheable.
+
+   The fundamental difference between the POST and PUT requests is
+   reflected in the different meaning of the Request-URI. The URI in a
+   POST request identifies the resource that will handle the enclosed
+   entity. That resource might be a data-accepting process, a gateway to
+   some other protocol, or a separate entity that accepts annotations.
+   In contrast, the URI in a PUT request identifies the entity enclosed
+   with the request -- the user agent knows what URI is intended and the
+   server MUST NOT attempt to apply the request to some other resource.
+   If the server desires that the request be applied to a different URI,
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 55]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   it MUST send a 301 (Moved Permanently) response; the user agent MAY
+   then make its own decision regarding whether or not to redirect the
+   request.
+
+   A single resource MAY be identified by many different URIs. For
+   example, an article might have a URI for identifying "the current
+   version" which is separate from the URI identifying each particular
+   version. In this case, a PUT request on a general URI might result in
+   several other URIs being defined by the origin server.
+
+   HTTP/1.1 does not define how a PUT method affects the state of an
+   origin server.
+
+   PUT requests MUST obey the message transmission requirements set out
+   in section 8.2.
+
+   Unless otherwise specified for a particular entity-header, the
+   entity-headers in the PUT request SHOULD be applied to the resource
+   created or modified by the PUT.
+
+9.7 DELETE
+
+   The DELETE method requests that the origin server delete the resource
+   identified by the Request-URI. This method MAY be overridden by human
+   intervention (or other means) on the origin server. The client cannot
+   be guaranteed that the operation has been carried out, even if the
+   status code returned from the origin server indicates that the action
+   has been completed successfully. However, the server SHOULD NOT
+   indicate success unless, at the time the response is given, it
+   intends to delete the resource or move it to an inaccessible
+   location.
+
+   A successful response SHOULD be 200 (OK) if the response includes an
+   entity describing the status, 202 (Accepted) if the action has not
+   yet been enacted, or 204 (No Content) if the action has been enacted
+   but the response does not include an entity.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries SHOULD be
+   treated as stale. Responses to this method are not cacheable.
+
+9.8 TRACE
+
+   The TRACE method is used to invoke a remote, application-layer loop-
+   back of the request message. The final recipient of the request
+   SHOULD reflect the message received back to the client as the
+   entity-body of a 200 (OK) response. The final recipient is either the
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 56]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   origin server or the first proxy or gateway to receive a Max-Forwards
+   value of zero (0) in the request (see section 14.31). A TRACE request
+   MUST NOT include an entity.
+
+   TRACE allows the client to see what is being received at the other
+   end of the request chain and use that data for testing or diagnostic
+   information. The value of the Via header field (section 14.45) is of
+   particular interest, since it acts as a trace of the request chain.
+   Use of the Max-Forwards header field allows the client to limit the
+   length of the request chain, which is useful for testing a chain of
+   proxies forwarding messages in an infinite loop.
+
+   If the request is valid, the response SHOULD contain the entire
+   request message in the entity-body, with a Content-Type of
+   "message/http". Responses to this method MUST NOT be cached.
+
+9.9 CONNECT
+
+   This specification reserves the method name CONNECT for use with a
+   proxy that can dynamically switch to being a tunnel (e.g. SSL
+   tunneling [44]).
+
+10 Status Code Definitions
+
+   Each Status-Code is described below, including a description of which
+   method(s) it can follow and any metainformation required in the
+   response.
+
+10.1 Informational 1xx
+
+   This class of status code indicates a provisional response,
+   consisting only of the Status-Line and optional headers, and is
+   terminated by an empty line. There are no required headers for this
+   class of status code. Since HTTP/1.0 did not define any 1xx status
+   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
+   except under experimental conditions.
+
+   A client MUST be prepared to accept one or more 1xx status responses
+   prior to a regular response, even if the client does not expect a 100
+   (Continue) status message. Unexpected 1xx status responses MAY be
+   ignored by a user agent.
+
+   Proxies MUST forward 1xx responses, unless the connection between the
+   proxy and its client has been closed, or unless the proxy itself
+   requested the generation of the 1xx response. (For example, if a
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 57]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   proxy adds a "Expect: 100-continue" field when it forwards a request,
+   then it need not forward the corresponding 100 (Continue)
+   response(s).)
+
+10.1.1 100 Continue
+
+   The client SHOULD continue with its request. This interim response is
+   used to inform the client that the initial part of the request has
+   been received and has not yet been rejected by the server. The client
+   SHOULD continue by sending the remainder of the request or, if the
+   request has already been completed, ignore this response. The server
+   MUST send a final response after the request has been completed. See
+   section 8.2.3 for detailed discussion of the use and handling of this
+   status code.
+
+10.1.2 101 Switching Protocols
+
+   The server understands and is willing to comply with the client's
+   request, via the Upgrade message header field (section 14.42), for a
+   change in the application protocol being used on this connection. The
+   server will switch protocols to those defined by the response's
+   Upgrade header field immediately after the empty line which
+   terminates the 101 response.
+
+   The protocol SHOULD be switched only when it is advantageous to do
+   so. For example, switching to a newer version of HTTP is advantageous
+   over older versions, and switching to a real-time, synchronous
+   protocol might be advantageous when delivering resources that use
+   such features.
+
+10.2 Successful 2xx
+
+   This class of status code indicates that the client's request was
+   successfully received, understood, and accepted.
+
+10.2.1 200 OK
+
+   The request has succeeded. The information returned with the response
+   is dependent on the method used in the request, for example:
+
+   GET    an entity corresponding to the requested resource is sent in
+          the response;
+
+   HEAD   the entity-header fields corresponding to the requested
+          resource are sent in the response without any message-body;
+
+   POST   an entity describing or containing the result of the action;
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 58]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   TRACE  an entity containing the request message as received by the
+          end server.
+
+10.2.2 201 Created
+
+   The request has been fulfilled and resulted in a new resource being
+   created. The newly created resource can be referenced by the URI(s)
+   returned in the entity of the response, with the most specific URI
+   for the resource given by a Location header field. The response
+   SHOULD include an entity containing a list of resource
+   characteristics and location(s) from which the user or user agent can
+   choose the one most appropriate. The entity format is specified by
+   the media type given in the Content-Type header field. The origin
+   server MUST create the resource before returning the 201 status code.
+   If the action cannot be carried out immediately, the server SHOULD
+   respond with 202 (Accepted) response instead.
+
+   A 201 response MAY contain an ETag response header field indicating
+   the current value of the entity tag for the requested variant just
+   created, see section 14.19.
+
+10.2.3 202 Accepted
+
+   The request has been accepted for processing, but the processing has
+   not been completed.  The request might or might not eventually be
+   acted upon, as it might be disallowed when processing actually takes
+   place. There is no facility for re-sending a status code from an
+   asynchronous operation such as this.
+
+   The 202 response is intentionally non-committal. Its purpose is to
+   allow a server to accept a request for some other process (perhaps a
+   batch-oriented process that is only run once per day) without
+   requiring that the user agent's connection to the server persist
+   until the process is completed. The entity returned with this
+   response SHOULD include an indication of the request's current status
+   and either a pointer to a status monitor or some estimate of when the
+   user can expect the request to be fulfilled.
+
+10.2.4 203 Non-Authoritative Information
+
+   The returned metainformation in the entity-header is not the
+   definitive set as available from the origin server, but is gathered
+   from a local or a third-party copy. The set presented MAY be a subset
+   or superset of the original version. For example, including local
+   annotation information about the resource might result in a superset
+   of the metainformation known by the origin server. Use of this
+   response code is not required and is only appropriate when the
+   response would otherwise be 200 (OK).
+
+
+
+Fielding, et al.            Standards Track                    [Page 59]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.2.5 204 No Content
+
+   The server has fulfilled the request but does not need to return an
+   entity-body, and might want to return updated metainformation. The
+   response MAY include new or updated metainformation in the form of
+   entity-headers, which if present SHOULD be associated with the
+   requested variant.
+
+   If the client is a user agent, it SHOULD NOT change its document view
+   from that which caused the request to be sent. This response is
+   primarily intended to allow input for actions to take place without
+   causing a change to the user agent's active document view, although
+   any new or updated metainformation SHOULD be applied to the document
+   currently in the user agent's active view.
+
+   The 204 response MUST NOT include a message-body, and thus is always
+   terminated by the first empty line after the header fields.
+
+10.2.6 205 Reset Content
+
+   The server has fulfilled the request and the user agent SHOULD reset
+   the document view which caused the request to be sent. This response
+   is primarily intended to allow input for actions to take place via
+   user input, followed by a clearing of the form in which the input is
+   given so that the user can easily initiate another input action. The
+   response MUST NOT include an entity.
+
+10.2.7 206 Partial Content
+
+   The server has fulfilled the partial GET request for the resource.
+   The request MUST have included a Range header field (section 14.35)
+   indicating the desired range, and MAY have included an If-Range
+   header field (section 14.27) to make the request conditional.
+
+   The response MUST include the following header fields:
+
+      - Either a Content-Range header field (section 14.16) indicating
+        the range included with this response, or a multipart/byteranges
+        Content-Type including Content-Range fields for each part. If a
+        Content-Length header field is present in the response, its
+        value MUST match the actual number of OCTETs transmitted in the
+        message-body.
+
+      - Date
+
+      - ETag and/or Content-Location, if the header would have been sent
+        in a 200 response to the same request
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 60]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - Expires, Cache-Control, and/or Vary, if the field-value might
+        differ from that sent in any previous response for the same
+        variant
+
+   If the 206 response is the result of an If-Range request that used a
+   strong cache validator (see section 13.3.3), the response SHOULD NOT
+   include other entity-headers. If the response is the result of an
+   If-Range request that used a weak validator, the response MUST NOT
+   include other entity-headers; this prevents inconsistencies between
+   cached entity-bodies and updated headers. Otherwise, the response
+   MUST include all of the entity-headers that would have been returned
+   with a 200 (OK) response to the same request.
+
+   A cache MUST NOT combine a 206 response with other previously cached
+   content if the ETag or Last-Modified headers do not match exactly,
+   see 13.5.4.
+
+   A cache that does not support the Range and Content-Range headers
+   MUST NOT cache 206 (Partial) responses.
+
+10.3 Redirection 3xx
+
+   This class of status code indicates that further action needs to be
+   taken by the user agent in order to fulfill the request.  The action
+   required MAY be carried out by the user agent without interaction
+   with the user if and only if the method used in the second request is
+   GET or HEAD. A client SHOULD detect infinite redirection loops, since
+   such loops generate network traffic for each redirection.
+
+      Note: previous versions of this specification recommended a
+      maximum of five redirections. Content developers should be aware
+      that there might be clients that implement such a fixed
+      limitation.
+
+10.3.1 300 Multiple Choices
+
+   The requested resource corresponds to any one of a set of
+   representations, each with its own specific location, and agent-
+   driven negotiation information (section 12) is being provided so that
+   the user (or user agent) can select a preferred representation and
+   redirect its request to that location.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of resource characteristics and location(s) from
+   which the user or user agent can choose the one most appropriate. The
+   entity format is specified by the media type given in the Content-
+   Type header field. Depending upon the format and the capabilities of
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 61]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the user agent, selection of the most appropriate choice MAY be
+   performed automatically. However, this specification does not define
+   any standard for such automatic selection.
+
+   If the server has a preferred choice of representation, it SHOULD
+   include the specific URI for that representation in the Location
+   field; user agents MAY use the Location field value for automatic
+   redirection. This response is cacheable unless indicated otherwise.
+
+10.3.2 301 Moved Permanently
+
+   The requested resource has been assigned a new permanent URI and any
+   future references to this resource SHOULD use one of the returned
+   URIs.  Clients with link editing capabilities ought to automatically
+   re-link references to the Request-URI to one or more of the new
+   references returned by the server, where possible. This response is
+   cacheable unless indicated otherwise.
+
+   The new permanent URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+   If the 301 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+      Note: When automatically redirecting a POST request after
+      receiving a 301 status code, some existing HTTP/1.0 user agents
+      will erroneously change it into a GET request.
+
+10.3.3 302 Found
+
+   The requested resource resides temporarily under a different URI.
+   Since the redirection might be altered on occasion, the client SHOULD
+   continue to use the Request-URI for future requests.  This response
+   is only cacheable if indicated by a Cache-Control or Expires header
+   field.
+
+   The temporary URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 62]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the 302 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
+      to change the method on the redirected request.  However, most
+      existing user agent implementations treat 302 as if it were a 303
+      response, performing a GET on the Location field-value regardless
+      of the original request method. The status codes 303 and 307 have
+      been added for servers that wish to make unambiguously clear which
+      kind of reaction is expected of the client.
+
+10.3.4 303 See Other
+
+   The response to the request can be found under a different URI and
+   SHOULD be retrieved using a GET method on that resource. This method
+   exists primarily to allow the output of a POST-activated script to
+   redirect the user agent to a selected resource. The new URI is not a
+   substitute reference for the originally requested resource. The 303
+   response MUST NOT be cached, but the response to the second
+   (redirected) request might be cacheable.
+
+   The different URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+      Note: Many pre-HTTP/1.1 user agents do not understand the 303
+      status. When interoperability with such clients is a concern, the
+      302 status code may be used instead, since most user agents react
+      to a 302 response as described here for 303.
+
+10.3.5 304 Not Modified
+
+   If the client has performed a conditional GET request and access is
+   allowed, but the document has not been modified, the server SHOULD
+   respond with this status code. The 304 response MUST NOT contain a
+   message-body, and thus is always terminated by the first empty line
+   after the header fields.
+
+   The response MUST include the following header fields:
+
+      - Date, unless its omission is required by section 14.18.1
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 63]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If a clockless origin server obeys these rules, and proxies and
+   clients add their own Date to any response received without one (as
+   already specified by [RFC 2068], section 14.19), caches will operate
+   correctly.
+
+      - ETag and/or Content-Location, if the header would have been sent
+        in a 200 response to the same request
+
+      - Expires, Cache-Control, and/or Vary, if the field-value might
+        differ from that sent in any previous response for the same
+        variant
+
+   If the conditional GET used a strong cache validator (see section
+   13.3.3), the response SHOULD NOT include other entity-headers.
+   Otherwise (i.e., the conditional GET used a weak validator), the
+   response MUST NOT include other entity-headers; this prevents
+   inconsistencies between cached entity-bodies and updated headers.
+
+   If a 304 response indicates an entity not currently cached, then the
+   cache MUST disregard the response and repeat the request without the
+   conditional.
+
+   If a cache uses a received 304 response to update a cache entry, the
+   cache MUST update the entry to reflect any new field values given in
+   the response.
+
+10.3.6 305 Use Proxy
+
+   The requested resource MUST be accessed through the proxy given by
+   the Location field. The Location field gives the URI of the proxy.
+   The recipient is expected to repeat this single request via the
+   proxy. 305 responses MUST only be generated by origin servers.
+
+      Note: RFC 2068 was not clear that 305 was intended to redirect a
+      single request, and to be generated by origin servers only.  Not
+      observing these limitations has significant security consequences.
+
+10.3.7 306 (Unused)
+
+   The 306 status code was used in a previous version of the
+   specification, is no longer used, and the code is reserved.
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 64]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.3.8 307 Temporary Redirect
+
+   The requested resource resides temporarily under a different URI.
+   Since the redirection MAY be altered on occasion, the client SHOULD
+   continue to use the Request-URI for future requests.  This response
+   is only cacheable if indicated by a Cache-Control or Expires header
+   field.
+
+   The temporary URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s) , since many pre-HTTP/1.1 user agents do not
+   understand the 307 status. Therefore, the note SHOULD contain the
+   information necessary for a user to repeat the original request on
+   the new URI.
+
+   If the 307 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+10.4 Client Error 4xx
+
+   The 4xx class of status code is intended for cases in which the
+   client seems to have erred. Except when responding to a HEAD request,
+   the server SHOULD include an entity containing an explanation of the
+   error situation, and whether it is a temporary or permanent
+   condition. These status codes are applicable to any request method.
+   User agents SHOULD display any included entity to the user.
+
+   If the client is sending data, a server implementation using TCP
+   SHOULD be careful to ensure that the client acknowledges receipt of
+   the packet(s) containing the response, before the server closes the
+   input connection. If the client continues sending data to the server
+   after the close, the server's TCP stack will send a reset packet to
+   the client, which may erase the client's unacknowledged input buffers
+   before they can be read and interpreted by the HTTP application.
+
+10.4.1 400 Bad Request
+
+   The request could not be understood by the server due to malformed
+   syntax. The client SHOULD NOT repeat the request without
+   modifications.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 65]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.2 401 Unauthorized
+
+   The request requires user authentication. The response MUST include a
+   WWW-Authenticate header field (section 14.47) containing a challenge
+   applicable to the requested resource. The client MAY repeat the
+   request with a suitable Authorization header field (section 14.8). If
+   the request already included Authorization credentials, then the 401
+   response indicates that authorization has been refused for those
+   credentials. If the 401 response contains the same challenge as the
+   prior response, and the user agent has already attempted
+   authentication at least once, then the user SHOULD be presented the
+   entity that was given in the response, since that entity might
+   include relevant diagnostic information. HTTP access authentication
+   is explained in "HTTP Authentication: Basic and Digest Access
+   Authentication" [43].
+
+10.4.3 402 Payment Required
+
+   This code is reserved for future use.
+
+10.4.4 403 Forbidden
+
+   The server understood the request, but is refusing to fulfill it.
+   Authorization will not help and the request SHOULD NOT be repeated.
+   If the request method was not HEAD and the server wishes to make
+   public why the request has not been fulfilled, it SHOULD describe the
+   reason for the refusal in the entity.  If the server does not wish to
+   make this information available to the client, the status code 404
+   (Not Found) can be used instead.
+
+10.4.5 404 Not Found
+
+   The server has not found anything matching the Request-URI. No
+   indication is given of whether the condition is temporary or
+   permanent. The 410 (Gone) status code SHOULD be used if the server
+   knows, through some internally configurable mechanism, that an old
+   resource is permanently unavailable and has no forwarding address.
+   This status code is commonly used when the server does not wish to
+   reveal exactly why the request has been refused, or when no other
+   response is applicable.
+
+10.4.6 405 Method Not Allowed
+
+   The method specified in the Request-Line is not allowed for the
+   resource identified by the Request-URI. The response MUST include an
+   Allow header containing a list of valid methods for the requested
+   resource.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 66]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.7 406 Not Acceptable
+
+   The resource identified by the request is only capable of generating
+   response entities which have content characteristics not acceptable
+   according to the accept headers sent in the request.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of available entity characteristics and location(s)
+   from which the user or user agent can choose the one most
+   appropriate. The entity format is specified by the media type given
+   in the Content-Type header field. Depending upon the format and the
+   capabilities of the user agent, selection of the most appropriate
+   choice MAY be performed automatically. However, this specification
+   does not define any standard for such automatic selection.
+
+      Note: HTTP/1.1 servers are allowed to return responses which are
+      not acceptable according to the accept headers sent in the
+      request. In some cases, this may even be preferable to sending a
+      406 response. User agents are encouraged to inspect the headers of
+      an incoming response to determine if it is acceptable.
+
+   If the response could be unacceptable, a user agent SHOULD
+   temporarily stop receipt of more data and query the user for a
+   decision on further actions.
+
+10.4.8 407 Proxy Authentication Required
+
+   This code is similar to 401 (Unauthorized), but indicates that the
+   client must first authenticate itself with the proxy. The proxy MUST
+   return a Proxy-Authenticate header field (section 14.33) containing a
+   challenge applicable to the proxy for the requested resource. The
+   client MAY repeat the request with a suitable Proxy-Authorization
+   header field (section 14.34). HTTP access authentication is explained
+   in "HTTP Authentication: Basic and Digest Access Authentication"
+   [43].
+
+10.4.9 408 Request Timeout
+
+   The client did not produce a request within the time that the server
+   was prepared to wait. The client MAY repeat the request without
+   modifications at any later time.
+
+10.4.10 409 Conflict
+
+   The request could not be completed due to a conflict with the current
+   state of the resource. This code is only allowed in situations where
+   it is expected that the user might be able to resolve the conflict
+   and resubmit the request. The response body SHOULD include enough
+
+
+
+Fielding, et al.            Standards Track                    [Page 67]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   information for the user to recognize the source of the conflict.
+   Ideally, the response entity would include enough information for the
+   user or user agent to fix the problem; however, that might not be
+   possible and is not required.
+
+   Conflicts are most likely to occur in response to a PUT request. For
+   example, if versioning were being used and the entity being PUT
+   included changes to a resource which conflict with those made by an
+   earlier (third-party) request, the server might use the 409 response
+   to indicate that it can't complete the request. In this case, the
+   response entity would likely contain a list of the differences
+   between the two versions in a format defined by the response
+   Content-Type.
+
+10.4.11 410 Gone
+
+   The requested resource is no longer available at the server and no
+   forwarding address is known. This condition is expected to be
+   considered permanent. Clients with link editing capabilities SHOULD
+   delete references to the Request-URI after user approval. If the
+   server does not know, or has no facility to determine, whether or not
+   the condition is permanent, the status code 404 (Not Found) SHOULD be
+   used instead. This response is cacheable unless indicated otherwise.
+
+   The 410 response is primarily intended to assist the task of web
+   maintenance by notifying the recipient that the resource is
+   intentionally unavailable and that the server owners desire that
+   remote links to that resource be removed. Such an event is common for
+   limited-time, promotional services and for resources belonging to
+   individuals no longer working at the server's site. It is not
+   necessary to mark all permanently unavailable resources as "gone" or
+   to keep the mark for any length of time -- that is left to the
+   discretion of the server owner.
+
+10.4.12 411 Length Required
+
+   The server refuses to accept the request without a defined Content-
+   Length. The client MAY repeat the request if it adds a valid
+   Content-Length header field containing the length of the message-body
+   in the request message.
+
+10.4.13 412 Precondition Failed
+
+   The precondition given in one or more of the request-header fields
+   evaluated to false when it was tested on the server. This response
+   code allows the client to place preconditions on the current resource
+   metainformation (header field data) and thus prevent the requested
+   method from being applied to a resource other than the one intended.
+
+
+
+Fielding, et al.            Standards Track                    [Page 68]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.14 413 Request Entity Too Large
+
+   The server is refusing to process a request because the request
+   entity is larger than the server is willing or able to process. The
+   server MAY close the connection to prevent the client from continuing
+   the request.
+
+   If the condition is temporary, the server SHOULD include a Retry-
+   After header field to indicate that it is temporary and after what
+   time the client MAY try again.
+
+10.4.15 414 Request-URI Too Long
+
+   The server is refusing to service the request because the Request-URI
+   is longer than the server is willing to interpret. This rare
+   condition is only likely to occur when a client has improperly
+   converted a POST request to a GET request with long query
+   information, when the client has descended into a URI "black hole" of
+   redirection (e.g., a redirected URI prefix that points to a suffix of
+   itself), or when the server is under attack by a client attempting to
+   exploit security holes present in some servers using fixed-length
+   buffers for reading or manipulating the Request-URI.
+
+10.4.16 415 Unsupported Media Type
+
+   The server is refusing to service the request because the entity of
+   the request is in a format not supported by the requested resource
+   for the requested method.
+
+10.4.17 416 Requested Range Not Satisfiable
+
+   A server SHOULD return a response with this status code if a request
+   included a Range request-header field (section 14.35), and none of
+   the range-specifier values in this field overlap the current extent
+   of the selected resource, and the request did not include an If-Range
+   request-header field. (For byte-ranges, this means that the first-
+   byte-pos of all of the byte-range-spec values were greater than the
+   current length of the selected resource.)
+
+   When this status code is returned for a byte-range request, the
+   response SHOULD include a Content-Range entity-header field
+   specifying the current length of the selected resource (see section
+   14.16). This response MUST NOT use the multipart/byteranges content-
+   type.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 69]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.18 417 Expectation Failed
+
+   The expectation given in an Expect request-header field (see section
+   14.20) could not be met by this server, or, if the server is a proxy,
+   the server has unambiguous evidence that the request could not be met
+   by the next-hop server.
+
+10.5 Server Error 5xx
+
+   Response status codes beginning with the digit "5" indicate cases in
+   which the server is aware that it has erred or is incapable of
+   performing the request. Except when responding to a HEAD request, the
+   server SHOULD include an entity containing an explanation of the
+   error situation, and whether it is a temporary or permanent
+   condition. User agents SHOULD display any included entity to the
+   user. These response codes are applicable to any request method.
+
+10.5.1 500 Internal Server Error
+
+   The server encountered an unexpected condition which prevented it
+   from fulfilling the request.
+
+10.5.2 501 Not Implemented
+
+   The server does not support the functionality required to fulfill the
+   request. This is the appropriate response when the server does not
+   recognize the request method and is not capable of supporting it for
+   any resource.
+
+10.5.3 502 Bad Gateway
+
+   The server, while acting as a gateway or proxy, received an invalid
+   response from the upstream server it accessed in attempting to
+   fulfill the request.
+
+10.5.4 503 Service Unavailable
+
+   The server is currently unable to handle the request due to a
+   temporary overloading or maintenance of the server. The implication
+   is that this is a temporary condition which will be alleviated after
+   some delay. If known, the length of the delay MAY be indicated in a
+   Retry-After header. If no Retry-After is given, the client SHOULD
+   handle the response as it would for a 500 response.
+
+      Note: The existence of the 503 status code does not imply that a
+      server must use it when becoming overloaded. Some servers may wish
+      to simply refuse the connection.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 70]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.5.5 504 Gateway Timeout
+
+   The server, while acting as a gateway or proxy, did not receive a
+   timely response from the upstream server specified by the URI (e.g.
+   HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
+   to access in attempting to complete the request.
+
+      Note: Note to implementors: some deployed proxies are known to
+      return 400 or 500 when DNS lookups time out.
+
+10.5.6 505 HTTP Version Not Supported
+
+   The server does not support, or refuses to support, the HTTP protocol
+   version that was used in the request message. The server is
+   indicating that it is unable or unwilling to complete the request
+   using the same major version as the client, as described in section
+   3.1, other than with this error message. The response SHOULD contain
+   an entity describing why that version is not supported and what other
+   protocols are supported by that server.
+
+11 Access Authentication
+
+   HTTP provides several OPTIONAL challenge-response authentication
+   mechanisms which can be used by a server to challenge a client
+   request and by a client to provide authentication information. The
+   general framework for access authentication, and the specification of
+   "basic" and "digest" authentication, are specified in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. This
+   specification adopts the definitions of "challenge" and "credentials"
+   from that specification.
+
+12 Content Negotiation
+
+   Most HTTP responses include an entity which contains information for
+   interpretation by a human user. Naturally, it is desirable to supply
+   the user with the "best available" entity corresponding to the
+   request. Unfortunately for servers and caches, not all users have the
+   same preferences for what is "best," and not all user agents are
+   equally capable of rendering all entity types. For that reason, HTTP
+   has provisions for several mechanisms for "content negotiation" --
+   the process of selecting the best representation for a given response
+   when there are multiple representations available.
+
+      Note: This is not called "format negotiation" because the
+      alternate representations may be of the same media type, but use
+      different capabilities of that type, be in different languages,
+      etc.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 71]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Any response containing an entity-body MAY be subject to negotiation,
+   including error responses.
+
+   There are two kinds of content negotiation which are possible in
+   HTTP: server-driven and agent-driven negotiation. These two kinds of
+   negotiation are orthogonal and thus may be used separately or in
+   combination. One method of combination, referred to as transparent
+   negotiation, occurs when a cache uses the agent-driven negotiation
+   information provided by the origin server in order to provide
+   server-driven negotiation for subsequent requests.
+
+12.1 Server-driven Negotiation
+
+   If the selection of the best representation for a response is made by
+   an algorithm located at the server, it is called server-driven
+   negotiation. Selection is based on the available representations of
+   the response (the dimensions over which it can vary; e.g. language,
+   content-coding, etc.) and the contents of particular header fields in
+   the request message or on other information pertaining to the request
+   (such as the network address of the client).
+
+   Server-driven negotiation is advantageous when the algorithm for
+   selecting from among the available representations is difficult to
+   describe to the user agent, or when the server desires to send its
+   "best guess" to the client along with the first response (hoping to
+   avoid the round-trip delay of a subsequent request if the "best
+   guess" is good enough for the user). In order to improve the server's
+   guess, the user agent MAY include request header fields (Accept,
+   Accept-Language, Accept-Encoding, etc.) which describe its
+   preferences for such a response.
+
+   Server-driven negotiation has disadvantages:
+
+      1. It is impossible for the server to accurately determine what
+         might be "best" for any given user, since that would require
+         complete knowledge of both the capabilities of the user agent
+         and the intended use for the response (e.g., does the user want
+         to view it on screen or print it on paper?).
+
+      2. Having the user agent describe its capabilities in every
+         request can be both very inefficient (given that only a small
+         percentage of responses have multiple representations) and a
+         potential violation of the user's privacy.
+
+      3. It complicates the implementation of an origin server and the
+         algorithms for generating responses to a request.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 72]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      4. It may limit a public cache's ability to use the same response
+         for multiple user's requests.
+
+   HTTP/1.1 includes the following request-header fields for enabling
+   server-driven negotiation through description of user agent
+   capabilities and user preferences: Accept (section 14.1), Accept-
+   Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
+   Language (section 14.4), and User-Agent (section 14.43). However, an
+   origin server is not limited to these dimensions and MAY vary the
+   response based on any aspect of the request, including information
+   outside the request-header fields or within extension header fields
+   not defined by this specification.
+
+   The Vary  header field can be used to express the parameters the
+   server uses to select a representation that is subject to server-
+   driven negotiation. See section 13.6 for use of the Vary header field
+   by caches and section 14.44 for use of the Vary header field by
+   servers.
+
+12.2 Agent-driven Negotiation
+
+   With agent-driven negotiation, selection of the best representation
+   for a response is performed by the user agent after receiving an
+   initial response from the origin server. Selection is based on a list
+   of the available representations of the response included within the
+   header fields or entity-body of the initial response, with each
+   representation identified by its own URI. Selection from among the
+   representations may be performed automatically (if the user agent is
+   capable of doing so) or manually by the user selecting from a
+   generated (possibly hypertext) menu.
+
+   Agent-driven negotiation is advantageous when the response would vary
+   over commonly-used dimensions (such as type, language, or encoding),
+   when the origin server is unable to determine a user agent's
+   capabilities from examining the request, and generally when public
+   caches are used to distribute server load and reduce network usage.
+
+   Agent-driven negotiation suffers from the disadvantage of needing a
+   second request to obtain the best alternate representation. This
+   second request is only efficient when caching is used. In addition,
+   this specification does not define any mechanism for supporting
+   automatic selection, though it also does not prevent any such
+   mechanism from being developed as an extension and used within
+   HTTP/1.1.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 73]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
+   status codes for enabling agent-driven negotiation when the server is
+   unwilling or unable to provide a varying response using server-driven
+   negotiation.
+
+12.3 Transparent Negotiation
+
+   Transparent negotiation is a combination of both server-driven and
+   agent-driven negotiation. When a cache is supplied with a form of the
+   list of available representations of the response (as in agent-driven
+   negotiation) and the dimensions of variance are completely understood
+   by the cache, then the cache becomes capable of performing server-
+   driven negotiation on behalf of the origin server for subsequent
+   requests on that resource.
+
+   Transparent negotiation has the advantage of distributing the
+   negotiation work that would otherwise be required of the origin
+   server and also removing the second request delay of agent-driven
+   negotiation when the cache is able to correctly guess the right
+   response.
+
+   This specification does not define any mechanism for transparent
+   negotiation, though it also does not prevent any such mechanism from
+   being developed as an extension that could be used within HTTP/1.1.
+
+13 Caching in HTTP
+
+   HTTP is typically used for distributed information systems, where
+   performance can be improved by the use of response caches. The
+   HTTP/1.1 protocol includes a number of elements intended to make
+   caching work as well as possible. Because these elements are
+   inextricable from other aspects of the protocol, and because they
+   interact with each other, it is useful to describe the basic caching
+   design of HTTP separately from the detailed descriptions of methods,
+   headers, response codes, etc.
+
+   Caching would be useless if it did not significantly improve
+   performance. The goal of caching in HTTP/1.1 is to eliminate the need
+   to send requests in many cases, and to eliminate the need to send
+   full responses in many other cases. The former reduces the number of
+   network round-trips required for many operations; we use an
+   "expiration" mechanism for this purpose (see section 13.2). The
+   latter reduces network bandwidth requirements; we use a "validation"
+   mechanism for this purpose (see section 13.3).
+
+   Requirements for performance, availability, and disconnected
+   operation require us to be able to relax the goal of semantic
+   transparency. The HTTP/1.1 protocol allows origin servers, caches,
+
+
+
+Fielding, et al.            Standards Track                    [Page 74]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   and clients to explicitly reduce transparency when necessary.
+   However, because non-transparent operation may confuse non-expert
+   users, and might be incompatible with certain server applications
+   (such as those for ordering merchandise), the protocol requires that
+   transparency be relaxed
+
+      - only by an explicit protocol-level request when relaxed by
+        client or origin server
+
+      - only with an explicit warning to the end user when relaxed by
+        cache or client
+
+   Therefore, the HTTP/1.1 protocol provides these important elements:
+
+      1. Protocol features that provide full semantic transparency when
+         this is required by all parties.
+
+      2. Protocol features that allow an origin server or user agent to
+         explicitly request and control non-transparent operation.
+
+      3. Protocol features that allow a cache to attach warnings to
+         responses that do not preserve the requested approximation of
+         semantic transparency.
+
+   A basic principle is that it must be possible for the clients to
+   detect any potential relaxation of semantic transparency.
+
+      Note: The server, cache, or client implementor might be faced with
+      design decisions not explicitly discussed in this specification.
+      If a decision might affect semantic transparency, the implementor
+      ought to err on the side of maintaining transparency unless a
+      careful and complete analysis shows significant benefits in
+      breaking transparency.
+
+13.1.1 Cache Correctness
+
+   A correct cache MUST respond to a request with the most up-to-date
+   response held by the cache that is appropriate to the request (see
+   sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
+   conditions:
+
+      1. It has been checked for equivalence with what the origin server
+         would have returned by revalidating the response with the
+         origin server (section 13.3);
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 75]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      2. It is "fresh enough" (see section 13.2). In the default case,
+         this means it meets the least restrictive freshness requirement
+         of the client, origin server, and cache (see section 14.9); if
+         the origin server so specifies, it is the freshness requirement
+         of the origin server alone.
+
+         If a stored response is not "fresh enough" by the most
+         restrictive freshness requirement of both the client and the
+         origin server, in carefully considered circumstances the cache
+         MAY still return the response with the appropriate Warning
+         header (see section 13.1.5 and 14.46), unless such a response
+         is prohibited (e.g., by a "no-store" cache-directive, or by a
+         "no-cache" cache-request-directive; see section 14.9).
+
+      3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
+         or error (4xx or 5xx) response message.
+
+   If the cache can not communicate with the origin server, then a
+   correct cache SHOULD respond as above if the response can be
+   correctly served from the cache; if not it MUST return an error or
+   warning indicating that there was a communication failure.
+
+   If a cache receives a response (either an entire response, or a 304
+   (Not Modified) response) that it would normally forward to the
+   requesting client, and the received response is no longer fresh, the
+   cache SHOULD forward it to the requesting client without adding a new
+   Warning (but without removing any existing Warning headers). A cache
+   SHOULD NOT attempt to revalidate a response simply because that
+   response became stale in transit; this might lead to an infinite
+   loop. A user agent that receives a stale response without a Warning
+   MAY display a warning indication to the user.
+
+13.1.2 Warnings
+
+   Whenever a cache returns a response that is neither first-hand nor
+   "fresh enough" (in the sense of condition 2 in section 13.1.1), it
+   MUST attach a warning to that effect, using a Warning general-header.
+   The Warning header and the currently defined warnings are described
+   in section 14.46. The warning allows clients to take appropriate
+   action.
+
+   Warnings MAY be used for other purposes, both cache-related and
+   otherwise. The use of a warning, rather than an error status code,
+   distinguish these responses from true failures.
+
+   Warnings are assigned three digit warn-codes. The first digit
+   indicates whether the Warning MUST or MUST NOT be deleted from a
+   stored cache entry after a successful revalidation:
+
+
+
+Fielding, et al.            Standards Track                    [Page 76]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   1xx  Warnings that describe the freshness or revalidation status of
+     the response, and so MUST be deleted after a successful
+     revalidation. 1XX warn-codes MAY be generated by a cache only when
+     validating a cached entry. It MUST NOT be generated by clients.
+
+   2xx  Warnings that describe some aspect of the entity body or entity
+     headers that is not rectified by a revalidation (for example, a
+     lossy compression of the entity bodies) and which MUST NOT be
+     deleted after a successful revalidation.
+
+   See section 14.46 for the definitions of the codes themselves.
+
+   HTTP/1.0 caches will cache all Warnings in responses, without
+   deleting the ones in the first category. Warnings in responses that
+   are passed to HTTP/1.0 caches carry an extra warning-date field,
+   which prevents a future HTTP/1.1 recipient from believing an
+   erroneously cached Warning.
+
+   Warnings also carry a warning text. The text MAY be in any
+   appropriate natural language (perhaps based on the client's Accept
+   headers), and include an OPTIONAL indication of what character set is
+   used.
+
+   Multiple warnings MAY be attached to a response (either by the origin
+   server or by a cache), including multiple warnings with the same code
+   number. For example, a server might provide the same warning with
+   texts in both English and Basque.
+
+   When multiple warnings are attached to a response, it might not be
+   practical or reasonable to display all of them to the user. This
+   version of HTTP does not specify strict priority rules for deciding
+   which warnings to display and in what order, but does suggest some
+   heuristics.
+
+13.1.3 Cache-control Mechanisms
+
+   The basic cache mechanisms in HTTP/1.1 (server-specified expiration
+   times and validators) are implicit directives to caches. In some
+   cases, a server or client might need to provide explicit directives
+   to the HTTP caches. We use the Cache-Control header for this purpose.
+
+   The Cache-Control header allows a client or server to transmit a
+   variety of directives in either requests or responses. These
+   directives typically override the default caching algorithms. As a
+   general rule, if there is any apparent conflict between header
+   values, the most restrictive interpretation is applied (that is, the
+   one that is most likely to preserve semantic transparency). However,
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 77]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   in some cases, cache-control directives are explicitly specified as
+   weakening the approximation of semantic transparency (for example,
+   "max-stale" or "public").
+
+   The cache-control directives are described in detail in section 14.9.
+
+13.1.4 Explicit User Agent Warnings
+
+   Many user agents make it possible for users to override the basic
+   caching mechanisms. For example, the user agent might allow the user
+   to specify that cached entities (even explicitly stale ones) are
+   never validated. Or the user agent might habitually add "Cache-
+   Control: max-stale=3600" to every request. The user agent SHOULD NOT
+   default to either non-transparent behavior, or behavior that results
+   in abnormally ineffective caching, but MAY be explicitly configured
+   to do so by an explicit action of the user.
+
+   If the user has overridden the basic caching mechanisms, the user
+   agent SHOULD explicitly indicate to the user whenever this results in
+   the display of information that might not meet the server's
+   transparency requirements (in particular, if the displayed entity is
+   known to be stale). Since the protocol normally allows the user agent
+   to determine if responses are stale or not, this indication need only
+   be displayed when this actually happens. The indication need not be a
+   dialog box; it could be an icon (for example, a picture of a rotting
+   fish) or some other indicator.
+
+   If the user has overridden the caching mechanisms in a way that would
+   abnormally reduce the effectiveness of caches, the user agent SHOULD
+   continually indicate this state to the user (for example, by a
+   display of a picture of currency in flames) so that the user does not
+   inadvertently consume excess resources or suffer from excessive
+   latency.
+
+13.1.5 Exceptions to the Rules and Warnings
+
+   In some cases, the operator of a cache MAY choose to configure it to
+   return stale responses even when not requested by clients. This
+   decision ought not be made lightly, but may be necessary for reasons
+   of availability or performance, especially when the cache is poorly
+   connected to the origin server. Whenever a cache returns a stale
+   response, it MUST mark it as such (using a Warning header) enabling
+   the client software to alert the user that there might be a potential
+   problem.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 78]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   It also allows the user agent to take steps to obtain a first-hand or
+   fresh response. For this reason, a cache SHOULD NOT return a stale
+   response if the client explicitly requests a first-hand or fresh one,
+   unless it is impossible to comply for technical or policy reasons.
+
+13.1.6 Client-controlled Behavior
+
+   While the origin server (and to a lesser extent, intermediate caches,
+   by their contribution to the age of a response) are the primary
+   source of expiration information, in some cases the client might need
+   to control a cache's decision about whether to return a cached
+   response without validating it. Clients do this using several
+   directives of the Cache-Control header.
+
+   A client's request MAY specify the maximum age it is willing to
+   accept of an unvalidated response; specifying a value of zero forces
+   the cache(s) to revalidate all responses. A client MAY also specify
+   the minimum time remaining before a response expires. Both of these
+   options increase constraints on the behavior of caches, and so cannot
+   further relax the cache's approximation of semantic transparency.
+
+   A client MAY also specify that it will accept stale responses, up to
+   some maximum amount of staleness. This loosens the constraints on the
+   caches, and so might violate the origin server's specified
+   constraints on semantic transparency, but might be necessary to
+   support disconnected operation, or high availability in the face of
+   poor connectivity.
+
+13.2 Expiration Model
+
+13.2.1 Server-Specified Expiration
+
+   HTTP caching works best when caches can entirely avoid making
+   requests to the origin server. The primary mechanism for avoiding
+   requests is for an origin server to provide an explicit expiration
+   time in the future, indicating that a response MAY be used to satisfy
+   subsequent requests. In other words, a cache can return a fresh
+   response without first contacting the server.
+
+   Our expectation is that servers will assign future explicit
+   expiration times to responses in the belief that the entity is not
+   likely to change, in a semantically significant way, before the
+   expiration time is reached. This normally preserves semantic
+   transparency, as long as the server's expiration times are carefully
+   chosen.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 79]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The expiration mechanism applies only to responses taken from a cache
+   and not to first-hand responses forwarded immediately to the
+   requesting client.
+
+   If an origin server wishes to force a semantically transparent cache
+   to validate every request, it MAY assign an explicit expiration time
+   in the past. This means that the response is always stale, and so the
+   cache SHOULD validate it before using it for subsequent requests. See
+   section 14.9.4 for a more restrictive way to force revalidation.
+
+   If an origin server wishes to force any HTTP/1.1 cache, no matter how
+   it is configured, to validate every request, it SHOULD use the "must-
+   revalidate" cache-control directive (see section 14.9).
+
+   Servers specify explicit expiration times using either the Expires
+   header, or the max-age directive of the Cache-Control header.
+
+   An expiration time cannot be used to force a user agent to refresh
+   its display or reload a resource; its semantics apply only to caching
+   mechanisms, and such mechanisms need only check a resource's
+   expiration status when a new request for that resource is initiated.
+   See section 13.13 for an explanation of the difference between caches
+   and history mechanisms.
+
+13.2.2 Heuristic Expiration
+
+   Since origin servers do not always provide explicit expiration times,
+   HTTP caches typically assign heuristic expiration times, employing
+   algorithms that use other header values (such as the Last-Modified
+   time) to estimate a plausible expiration time. The HTTP/1.1
+   specification does not provide specific algorithms, but does impose
+   worst-case constraints on their results. Since heuristic expiration
+   times might compromise semantic transparency, they ought to used
+   cautiously, and we encourage origin servers to provide explicit
+   expiration times as much as possible.
+
+13.2.3 Age Calculations
+
+   In order to know if a cached entry is fresh, a cache needs to know if
+   its age exceeds its freshness lifetime. We discuss how to calculate
+   the latter in section 13.2.4; this section describes how to calculate
+   the age of a response or cache entry.
+
+   In this discussion, we use the term "now" to mean "the current value
+   of the clock at the host performing the calculation." Hosts that use
+   HTTP, but especially hosts running origin servers and caches, SHOULD
+   use NTP [28] or some similar protocol to synchronize their clocks to
+   a globally accurate time standard.
+
+
+
+Fielding, et al.            Standards Track                    [Page 80]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 requires origin servers to send a Date header, if possible,
+   with every response, giving the time at which the response was
+   generated (see section 14.18). We use the term "date_value" to denote
+   the value of the Date header, in a form appropriate for arithmetic
+   operations.
+
+   HTTP/1.1 uses the Age response-header to convey the estimated age of
+   the response message when obtained from a cache. The Age field value
+   is the cache's estimate of the amount of time since the response was
+   generated or revalidated by the origin server.
+
+   In essence, the Age value is the sum of the time that the response
+   has been resident in each of the caches along the path from the
+   origin server, plus the amount of time it has been in transit along
+   network paths.
+
+   We use the term "age_value" to denote the value of the Age header, in
+   a form appropriate for arithmetic operations.
+
+   A response's age can be calculated in two entirely independent ways:
+
+      1. now minus date_value, if the local clock is reasonably well
+         synchronized to the origin server's clock. If the result is
+         negative, the result is replaced by zero.
+
+      2. age_value, if all of the caches along the response path
+         implement HTTP/1.1.
+
+   Given that we have two independent ways to compute the age of a
+   response when it is received, we can combine these as
+
+       corrected_received_age = max(now - date_value, age_value)
+
+   and as long as we have either nearly synchronized clocks or all-
+   HTTP/1.1 paths, one gets a reliable (conservative) result.
+
+   Because of network-imposed delays, some significant interval might
+   pass between the time that a server generates a response and the time
+   it is received at the next outbound cache or client. If uncorrected,
+   this delay could result in improperly low ages.
+
+   Because the request that resulted in the returned Age value must have
+   been initiated prior to that Age value's generation, we can correct
+   for delays imposed by the network by recording the time at which the
+   request was initiated. Then, when an Age value is received, it MUST
+   be interpreted relative to the time the request was initiated, not
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 81]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the time that the response was received. This algorithm results in
+   conservative behavior no matter how much delay is experienced. So, we
+   compute:
+
+      corrected_initial_age = corrected_received_age
+                            + (now - request_time)
+
+   where "request_time" is the time (according to the local clock) when
+   the request that elicited this response was sent.
+
+   Summary of age calculation algorithm, when a cache receives a
+   response:
+
+      /*
+       * age_value
+       *      is the value of Age: header received by the cache with
+       *              this response.
+       * date_value
+       *      is the value of the origin server's Date: header
+       * request_time
+       *      is the (local) time when the cache made the request
+       *              that resulted in this cached response
+       * response_time
+       *      is the (local) time when the cache received the
+       *              response
+       * now
+       *      is the current (local) time
+       */
+
+      apparent_age = max(0, response_time - date_value);
+      corrected_received_age = max(apparent_age, age_value);
+      response_delay = response_time - request_time;
+      corrected_initial_age = corrected_received_age + response_delay;
+      resident_time = now - response_time;
+      current_age   = corrected_initial_age + resident_time;
+
+   The current_age of a cache entry is calculated by adding the amount
+   of time (in seconds) since the cache entry was last validated by the
+   origin server to the corrected_initial_age. When a response is
+   generated from a cache entry, the cache MUST include a single Age
+   header field in the response with a value equal to the cache entry's
+   current_age.
+
+   The presence of an Age header field in a response implies that a
+   response is not first-hand. However, the converse is not true, since
+   the lack of an Age header field in a response does not imply that the
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 82]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   response is first-hand unless all caches along the request path are
+   compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
+   the Age header field).
+
+13.2.4 Expiration Calculations
+
+   In order to decide whether a response is fresh or stale, we need to
+   compare its freshness lifetime to its age. The age is calculated as
+   described in section 13.2.3; this section describes how to calculate
+   the freshness lifetime, and to determine if a response has expired.
+   In the discussion below, the values can be represented in any form
+   appropriate for arithmetic operations.
+
+   We use the term "expires_value" to denote the value of the Expires
+   header. We use the term "max_age_value" to denote an appropriate
+   value of the number of seconds carried by the "max-age" directive of
+   the Cache-Control header in a response (see section 14.9.3).
+
+   The max-age directive takes priority over Expires, so if max-age is
+   present in a response, the calculation is simply:
+
+      freshness_lifetime = max_age_value
+
+   Otherwise, if Expires is present in the response, the calculation is:
+
+      freshness_lifetime = expires_value - date_value
+
+   Note that neither of these calculations is vulnerable to clock skew,
+   since all of the information comes from the origin server.
+
+   If none of Expires, Cache-Control: max-age, or Cache-Control: s-
+   maxage (see section 14.9.3) appears in the response, and the response
+   does not include other restrictions on caching, the cache MAY compute
+   a freshness lifetime using a heuristic. The cache MUST attach Warning
+   113 to any response whose age is more than 24 hours if such warning
+   has not already been added.
+
+   Also, if the response does have a Last-Modified time, the heuristic
+   expiration value SHOULD be no more than some fraction of the interval
+   since that time. A typical setting of this fraction might be 10%.
+
+   The calculation to determine if a response has expired is quite
+   simple:
+
+      response_is_fresh = (freshness_lifetime > current_age)
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 83]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.2.5 Disambiguating Expiration Values
+
+   Because expiration values are assigned optimistically, it is possible
+   for two caches to contain fresh values for the same resource that are
+   different.
+
+   If a client performing a retrieval receives a non-first-hand response
+   for a request that was already fresh in its own cache, and the Date
+   header in its existing cache entry is newer than the Date on the new
+   response, then the client MAY ignore the response. If so, it MAY
+   retry the request with a "Cache-Control: max-age=0" directive (see
+   section 14.9), to force a check with the origin server.
+
+   If a cache has two fresh responses for the same representation with
+   different validators, it MUST use the one with the more recent Date
+   header. This situation might arise because the cache is pooling
+   responses from other caches, or because a client has asked for a
+   reload or a revalidation of an apparently fresh cache entry.
+
+13.2.6 Disambiguating Multiple Responses
+
+   Because a client might be receiving responses via multiple paths, so
+   that some responses flow through one set of caches and other
+   responses flow through a different set of caches, a client might
+   receive responses in an order different from that in which the origin
+   server sent them. We would like the client to use the most recently
+   generated response, even if older responses are still apparently
+   fresh.
+
+   Neither the entity tag nor the expiration value can impose an
+   ordering on responses, since it is possible that a later response
+   intentionally carries an earlier expiration time. The Date values are
+   ordered to a granularity of one second.
+
+   When a client tries to revalidate a cache entry, and the response it
+   receives contains a Date header that appears to be older than the one
+   for the existing entry, then the client SHOULD repeat the request
+   unconditionally, and include
+
+       Cache-Control: max-age=0
+
+   to force any intermediate caches to validate their copies directly
+   with the origin server, or
+
+       Cache-Control: no-cache
+
+   to force any intermediate caches to obtain a new copy from the origin
+   server.
+
+
+
+Fielding, et al.            Standards Track                    [Page 84]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the Date values are equal, then the client MAY use either response
+   (or MAY, if it is being extremely prudent, request a new response).
+   Servers MUST NOT depend on clients being able to choose
+   deterministically between responses generated during the same second,
+   if their expiration times overlap.
+
+13.3 Validation Model
+
+   When a cache has a stale entry that it would like to use as a
+   response to a client's request, it first has to check with the origin
+   server (or possibly an intermediate cache with a fresh response) to
+   see if its cached entry is still usable. We call this "validating"
+   the cache entry. Since we do not want to have to pay the overhead of
+   retransmitting the full response if the cached entry is good, and we
+   do not want to pay the overhead of an extra round trip if the cached
+   entry is invalid, the HTTP/1.1 protocol supports the use of
+   conditional methods.
+
+   The key protocol features for supporting conditional methods are
+   those concerned with "cache validators." When an origin server
+   generates a full response, it attaches some sort of validator to it,
+   which is kept with the cache entry. When a client (user agent or
+   proxy cache) makes a conditional request for a resource for which it
+   has a cache entry, it includes the associated validator in the
+   request.
+
+   The server then checks that validator against the current validator
+   for the entity, and, if they match (see section 13.3.3), it responds
+   with a special status code (usually, 304 (Not Modified)) and no
+   entity-body. Otherwise, it returns a full response (including
+   entity-body). Thus, we avoid transmitting the full response if the
+   validator matches, and we avoid an extra round trip if it does not
+   match.
+
+   In HTTP/1.1, a conditional request looks exactly the same as a normal
+   request for the same resource, except that it carries a special
+   header (which includes the validator) that implicitly turns the
+   method (usually, GET) into a conditional.
+
+   The protocol includes both positive and negative senses of cache-
+   validating conditions. That is, it is possible to request either that
+   a method be performed if and only if a validator matches or if and
+   only if no validators match.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 85]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      Note: a response that lacks a validator may still be cached, and
+      served from cache until it expires, unless this is explicitly
+      prohibited by a cache-control directive. However, a cache cannot
+      do a conditional retrieval if it does not have a validator for the
+      entity, which means it will not be refreshable after it expires.
+
+13.3.1 Last-Modified Dates
+
+   The Last-Modified entity-header field value is often used as a cache
+   validator. In simple terms, a cache entry is considered to be valid
+   if the entity has not been modified since the Last-Modified value.
+
+13.3.2 Entity Tag Cache Validators
+
+   The ETag response-header field value, an entity tag, provides for an
+   "opaque" cache validator. This might allow more reliable validation
+   in situations where it is inconvenient to store modification dates,
+   where the one-second resolution of HTTP date values is not
+   sufficient, or where the origin server wishes to avoid certain
+   paradoxes that might arise from the use of modification dates.
+
+   Entity Tags are described in section 3.11. The headers used with
+   entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
+
+13.3.3 Weak and Strong Validators
+
+   Since both origin servers and caches will compare two validators to
+   decide if they represent the same or different entities, one normally
+   would expect that if the entity (the entity-body or any entity-
+   headers) changes in any way, then the associated validator would
+   change as well. If this is true, then we call this validator a
+   "strong validator."
+
+   However, there might be cases when a server prefers to change the
+   validator only on semantically significant changes, and not when
+   insignificant aspects of the entity change. A validator that does not
+   always change when the resource changes is a "weak validator."
+
+   Entity tags are normally "strong validators," but the protocol
+   provides a mechanism to tag an entity tag as "weak." One can think of
+   a strong validator as one that changes whenever the bits of an entity
+   changes, while a weak value changes whenever the meaning of an entity
+   changes. Alternatively, one can think of a strong validator as part
+   of an identifier for a specific entity, while a weak validator is
+   part of an identifier for a set of semantically equivalent entities.
+
+      Note: One example of a strong validator is an integer that is
+      incremented in stable storage every time an entity is changed.
+
+
+
+Fielding, et al.            Standards Track                    [Page 86]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      An entity's modification time, if represented with one-second
+      resolution, could be a weak validator, since it is possible that
+      the resource might be modified twice during a single second.
+
+      Support for weak validators is optional. However, weak validators
+      allow for more efficient caching of equivalent objects; for
+      example, a hit counter on a site is probably good enough if it is
+      updated every few days or weeks, and any value during that period
+      is likely "good enough" to be equivalent.
+
+   A "use" of a validator is either when a client generates a request
+   and includes the validator in a validating header field, or when a
+   server compares two validators.
+
+   Strong validators are usable in any context. Weak validators are only
+   usable in contexts that do not depend on exact equality of an entity.
+   For example, either kind is usable for a conditional GET of a full
+   entity. However, only a strong validator is usable for a sub-range
+   retrieval, since otherwise the client might end up with an internally
+   inconsistent entity.
+
+   Clients MAY issue simple (non-subrange) GET requests with either weak
+   validators or strong validators. Clients MUST NOT use weak validators
+   in other forms of request.
+
+   The only function that the HTTP/1.1 protocol defines on validators is
+   comparison. There are two validator comparison functions, depending
+   on whether the comparison context allows the use of weak validators
+   or not:
+
+      - The strong comparison function: in order to be considered equal,
+        both validators MUST be identical in every way, and both MUST
+        NOT be weak.
+
+      - The weak comparison function: in order to be considered equal,
+        both validators MUST be identical in every way, but either or
+        both of them MAY be tagged as "weak" without affecting the
+        result.
+
+   An entity tag is strong unless it is explicitly tagged as weak.
+   Section 3.11 gives the syntax for entity tags.
+
+   A Last-Modified time, when used as a validator in a request, is
+   implicitly weak unless it is possible to deduce that it is strong,
+   using the following rules:
+
+      - The validator is being compared by an origin server to the
+        actual current validator for the entity and,
+
+
+
+Fielding, et al.            Standards Track                    [Page 87]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - That origin server reliably knows that the associated entity did
+        not change twice during the second covered by the presented
+        validator.
+
+   or
+
+      - The validator is about to be used by a client in an If-
+        Modified-Since or If-Unmodified-Since header, because the client
+        has a cache entry for the associated entity, and
+
+      - That cache entry includes a Date value, which gives the time
+        when the origin server sent the original response, and
+
+      - The presented Last-Modified time is at least 60 seconds before
+        the Date value.
+
+   or
+
+      - The validator is being compared by an intermediate cache to the
+        validator stored in its cache entry for the entity, and
+
+      - That cache entry includes a Date value, which gives the time
+        when the origin server sent the original response, and
+
+      - The presented Last-Modified time is at least 60 seconds before
+        the Date value.
+
+   This method relies on the fact that if two different responses were
+   sent by the origin server during the same second, but both had the
+   same Last-Modified time, then at least one of those responses would
+   have a Date value equal to its Last-Modified time. The arbitrary 60-
+   second limit guards against the possibility that the Date and Last-
+   Modified values are generated from different clocks, or at somewhat
+   different times during the preparation of the response. An
+   implementation MAY use a value larger than 60 seconds, if it is
+   believed that 60 seconds is too short.
+
+   If a client wishes to perform a sub-range retrieval on a value for
+   which it has only a Last-Modified time and no opaque validator, it
+   MAY do this only if the Last-Modified time is strong in the sense
+   described here.
+
+   A cache or origin server receiving a conditional request, other than
+   a full-body GET request, MUST use the strong comparison function to
+   evaluate the condition.
+
+   These rules allow HTTP/1.1 caches and clients to safely perform sub-
+   range retrievals on values that have been obtained from HTTP/1.0
+
+
+
+Fielding, et al.            Standards Track                    [Page 88]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   servers.
+
+13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
+
+   We adopt a set of rules and recommendations for origin servers,
+   clients, and caches regarding when various validator types ought to
+   be used, and for what purposes.
+
+   HTTP/1.1 origin servers:
+
+      - SHOULD send an entity tag validator unless it is not feasible to
+        generate one.
+
+      - MAY send a weak entity tag instead of a strong entity tag, if
+        performance considerations support the use of weak entity tags,
+        or if it is unfeasible to send a strong entity tag.
+
+      - SHOULD send a Last-Modified value if it is feasible to send one,
+        unless the risk of a breakdown in semantic transparency that
+        could result from using this date in an If-Modified-Since header
+        would lead to serious problems.
+
+   In other words, the preferred behavior for an HTTP/1.1 origin server
+   is to send both a strong entity tag and a Last-Modified value.
+
+   In order to be legal, a strong entity tag MUST change whenever the
+   associated entity value changes in any way. A weak entity tag SHOULD
+   change whenever the associated entity changes in a semantically
+   significant way.
+
+      Note: in order to provide semantically transparent caching, an
+      origin server must avoid reusing a specific strong entity tag
+      value for two different entities, or reusing a specific weak
+      entity tag value for two semantically different entities. Cache
+      entries might persist for arbitrarily long periods, regardless of
+      expiration times, so it might be inappropriate to expect that a
+      cache will never again attempt to validate an entry using a
+      validator that it obtained at some point in the past.
+
+   HTTP/1.1 clients:
+
+      - If an entity tag has been provided by the origin server, MUST
+        use that entity tag in any cache-conditional request (using If-
+        Match or If-None-Match).
+
+      - If only a Last-Modified value has been provided by the origin
+        server, SHOULD use that value in non-subrange cache-conditional
+        requests (using If-Modified-Since).
+
+
+
+Fielding, et al.            Standards Track                    [Page 89]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - If only a Last-Modified value has been provided by an HTTP/1.0
+        origin server, MAY use that value in subrange cache-conditional
+        requests (using If-Unmodified-Since:). The user agent SHOULD
+        provide a way to disable this, in case of difficulty.
+
+      - If both an entity tag and a Last-Modified value have been
+        provided by the origin server, SHOULD use both validators in
+        cache-conditional requests. This allows both HTTP/1.0 and
+        HTTP/1.1 caches to respond appropriately.
+
+   An HTTP/1.1 origin server, upon receiving a conditional request that
+   includes both a Last-Modified date (e.g., in an If-Modified-Since or
+   If-Unmodified-Since header field) and one or more entity tags (e.g.,
+   in an If-Match, If-None-Match, or If-Range header field) as cache
+   validators, MUST NOT return a response status of 304 (Not Modified)
+   unless doing so is consistent with all of the conditional header
+   fields in the request.
+
+   An HTTP/1.1 caching proxy, upon receiving a conditional request that
+   includes both a Last-Modified date and one or more entity tags as
+   cache validators, MUST NOT return a locally cached response to the
+   client unless that cached response is consistent with all of the
+   conditional header fields in the request.
+
+      Note: The general principle behind these rules is that HTTP/1.1
+      servers and clients should transmit as much non-redundant
+      information as is available in their responses and requests.
+      HTTP/1.1 systems receiving this information will make the most
+      conservative assumptions about the validators they receive.
+
+      HTTP/1.0 clients and caches will ignore entity tags. Generally,
+      last-modified values received or used by these systems will
+      support transparent and efficient caching, and so HTTP/1.1 origin
+      servers should provide Last-Modified values. In those rare cases
+      where the use of a Last-Modified value as a validator by an
+      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
+      origin servers should not provide one.
+
+13.3.5 Non-validating Conditionals
+
+   The principle behind entity tags is that only the service author
+   knows the semantics of a resource well enough to select an
+   appropriate cache validation mechanism, and the specification of any
+   validator comparison function more complex than byte-equality would
+   open up a can of worms. Thus, comparisons of any other headers
+   (except Last-Modified, for compatibility with HTTP/1.0) are never
+   used for purposes of validating a cache entry.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 90]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.4 Response Cacheability
+
+   Unless specifically constrained by a cache-control (section 14.9)
+   directive, a caching system MAY always store a successful response
+   (see section 13.8) as a cache entry, MAY return it without validation
+   if it is fresh, and MAY return it after successful validation. If
+   there is neither a cache validator nor an explicit expiration time
+   associated with a response, we do not expect it to be cached, but
+   certain caches MAY violate this expectation (for example, when little
+   or no network connectivity is available). A client can usually detect
+   that such a response was taken from a cache by comparing the Date
+   header to the current time.
+
+      Note: some HTTP/1.0 caches are known to violate this expectation
+      without providing any Warning.
+
+   However, in some cases it might be inappropriate for a cache to
+   retain an entity, or to return it in response to a subsequent
+   request. This might be because absolute semantic transparency is
+   deemed necessary by the service author, or because of security or
+   privacy considerations. Certain cache-control directives are
+   therefore provided so that the server can indicate that certain
+   resource entities, or portions thereof, are not to be cached
+   regardless of other considerations.
+
+   Note that section 14.8 normally prevents a shared cache from saving
+   and returning a response to a previous request if that request
+   included an Authorization header.
+
+   A response received with a status code of 200, 203, 206, 300, 301 or
+   410 MAY be stored by a cache and used in reply to a subsequent
+   request, subject to the expiration mechanism, unless a cache-control
+   directive prohibits caching. However, a cache that does not support
+   the Range and Content-Range headers MUST NOT cache 206 (Partial
+   Content) responses.
+
+   A response received with any other status code (e.g. status codes 302
+   and 307) MUST NOT be returned in a reply to a subsequent request
+   unless there are cache-control directives or another header(s) that
+   explicitly allow it. For example, these include the following: an
+   Expires header (section 14.21); a "max-age", "s-maxage",  "must-
+   revalidate", "proxy-revalidate", "public" or "private" cache-control
+   directive (section 14.9).
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 91]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5 Constructing Responses From Caches
+
+   The purpose of an HTTP cache is to store information received in
+   response to requests for use in responding to future requests. In
+   many cases, a cache simply returns the appropriate parts of a
+   response to the requester. However, if the cache holds a cache entry
+   based on a previous response, it might have to combine parts of a new
+   response with what is held in the cache entry.
+
+13.5.1 End-to-end and Hop-by-hop Headers
+
+   For the purpose of defining the behavior of caches and non-caching
+   proxies, we divide HTTP headers into two categories:
+
+      - End-to-end headers, which are  transmitted to the ultimate
+        recipient of a request or response. End-to-end headers in
+        responses MUST be stored as part of a cache entry and MUST be
+        transmitted in any response formed from a cache entry.
+
+      - Hop-by-hop headers, which are meaningful only for a single
+        transport-level connection, and are not stored by caches or
+        forwarded by proxies.
+
+   The following HTTP/1.1 headers are hop-by-hop headers:
+
+      - Connection
+      - Keep-Alive
+      - Proxy-Authenticate
+      - Proxy-Authorization
+      - TE
+      - Trailers
+      - Transfer-Encoding
+      - Upgrade
+
+   All other headers defined by HTTP/1.1 are end-to-end headers.
+
+   Other hop-by-hop headers MUST be listed in a Connection header,
+   (section 14.10) to be introduced into HTTP/1.1 (or later).
+
+13.5.2 Non-modifiable Headers
+
+   Some features of the HTTP/1.1 protocol, such as Digest
+   Authentication, depend on the value of certain end-to-end headers. A
+   transparent proxy SHOULD NOT modify an end-to-end header unless the
+   definition of that header requires or specifically allows that.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 92]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A transparent proxy MUST NOT modify any of the following fields in a
+   request or response, and it MUST NOT add any of these fields if not
+   already present:
+
+      - Content-Location
+
+      - Content-MD5
+
+      - ETag
+
+      - Last-Modified
+
+   A transparent proxy MUST NOT modify any of the following fields in a
+   response:
+
+      - Expires
+
+   but it MAY add any of these fields if not already present. If an
+   Expires header is added, it MUST be given a field-value identical to
+   that of the Date header in that response.
+
+   A  proxy MUST NOT modify or add any of the following fields in a
+   message that contains the no-transform cache-control directive, or in
+   any request:
+
+      - Content-Encoding
+
+      - Content-Range
+
+      - Content-Type
+
+   A non-transparent proxy MAY modify or add these fields to a message
+   that does not include no-transform, but if it does so, it MUST add a
+   Warning 214 (Transformation applied) if one does not already appear
+   in the message (see section 14.46).
+
+      Warning: unnecessary modification of end-to-end headers might
+      cause authentication failures if stronger authentication
+      mechanisms are introduced in later versions of HTTP. Such
+      authentication mechanisms MAY rely on the values of header fields
+      not listed here.
+
+   The Content-Length field of a request or response is added or deleted
+   according to the rules in section 4.4. A transparent proxy MUST
+   preserve the entity-length (section 7.2.2) of the entity-body,
+   although it MAY change the transfer-length (section 4.4).
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 93]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5.3 Combining Headers
+
+   When a cache makes a validating request to a server, and the server
+   provides a 304 (Not Modified) response or a 206 (Partial Content)
+   response, the cache then constructs a response to send to the
+   requesting client.
+
+   If the status code is 304 (Not Modified), the cache uses the entity-
+   body stored in the cache entry as the entity-body of this outgoing
+   response. If the status code is 206 (Partial Content) and the ETag or
+   Last-Modified headers match exactly, the cache MAY combine the
+   contents stored in the cache entry with the new contents received in
+   the response and use the result as the entity-body of this outgoing
+   response, (see 13.5.4).
+
+   The end-to-end headers stored in the cache entry are used for the
+   constructed response, except that
+
+      - any stored Warning headers with warn-code 1xx (see section
+        14.46) MUST be deleted from the cache entry and the forwarded
+        response.
+
+      - any stored Warning headers with warn-code 2xx MUST be retained
+        in the cache entry and the forwarded response.
+
+      - any end-to-end headers provided in the 304 or 206 response MUST
+        replace the corresponding headers from the cache entry.
+
+   Unless the cache decides to remove the cache entry, it MUST also
+   replace the end-to-end headers stored with the cache entry with
+   corresponding headers received in the incoming response, except for
+   Warning headers as described immediately above. If a header field-
+   name in the incoming response matches more than one header in the
+   cache entry, all such old headers MUST be replaced.
+
+   In other words, the set of end-to-end headers received in the
+   incoming response overrides all corresponding end-to-end headers
+   stored with the cache entry (except for stored Warning headers with
+   warn-code 1xx, which are deleted even if not overridden).
+
+      Note: this rule allows an origin server to use a 304 (Not
+      Modified) or a 206 (Partial Content) response to update any header
+      associated with a previous response for the same entity or sub-
+      ranges thereof, although it might not always be meaningful or
+      correct to do so. This rule does not allow an origin server to use
+      a 304 (Not Modified) or a 206 (Partial Content) response to
+      entirely delete a header that it had provided with a previous
+      response.
+
+
+
+Fielding, et al.            Standards Track                    [Page 94]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5.4 Combining Byte Ranges
+
+   A response might transfer only a subrange of the bytes of an entity-
+   body, either because the request included one or more Range
+   specifications, or because a connection was broken prematurely. After
+   several such transfers, a cache might have received several ranges of
+   the same entity-body.
+
+   If a cache has a stored non-empty set of subranges for an entity, and
+   an incoming response transfers another subrange, the cache MAY
+   combine the new subrange with the existing set if both the following
+   conditions are met:
+
+      - Both the incoming response and the cache entry have a cache
+        validator.
+
+      - The two cache validators match using the strong comparison
+        function (see section 13.3.3).
+
+   If either requirement is not met, the cache MUST use only the most
+   recent partial response (based on the Date values transmitted with
+   every response, and using the incoming response if these values are
+   equal or missing), and MUST discard the other partial information.
+
+13.6 Caching Negotiated Responses
+
+   Use of server-driven content negotiation (section 12.1), as indicated
+   by the presence of a Vary header field in a response, alters the
+   conditions and procedure by which a cache can use the response for
+   subsequent requests. See section 14.44 for use of the Vary header
+   field by servers.
+
+   A server SHOULD use the Vary header field to inform a cache of what
+   request-header fields were used to select among multiple
+   representations of a cacheable response subject to server-driven
+   negotiation. The set of header fields named by the Vary field value
+   is known as the "selecting" request-headers.
+
+   When the cache receives a subsequent request whose Request-URI
+   specifies one or more cache entries including a Vary header field,
+   the cache MUST NOT use such a cache entry to construct a response to
+   the new request unless all of the selecting request-headers present
+   in the new request match the corresponding stored request-headers in
+   the original request.
+
+   The selecting request-headers from two requests are defined to match
+   if and only if the selecting request-headers in the first request can
+   be transformed to the selecting request-headers in the second request
+
+
+
+Fielding, et al.            Standards Track                    [Page 95]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   by adding or removing linear white space (LWS) at places where this
+   is allowed by the corresponding BNF, and/or combining multiple
+   message-header fields with the same field name following the rules
+   about message headers in section 4.2.
+
+   A Vary header field-value of "*" always fails to match and subsequent
+   requests on that resource can only be properly interpreted by the
+   origin server.
+
+   If the selecting request header fields for the cached entry do not
+   match the selecting request header fields of the new request, then
+   the cache MUST NOT use a cached entry to satisfy the request unless
+   it first relays the new request to the origin server in a conditional
+   request and the server responds with 304 (Not Modified), including an
+   entity tag or Content-Location that indicates the entity to be used.
+
+   If an entity tag was assigned to a cached representation, the
+   forwarded request SHOULD be conditional and include the entity tags
+   in an If-None-Match header field from all its cache entries for the
+   resource. This conveys to the server the set of entities currently
+   held by the cache, so that if any one of these entities matches the
+   requested entity, the server can use the ETag header field in its 304
+   (Not Modified) response to tell the cache which entry is appropriate.
+   If the entity-tag of the new response matches that of an existing
+   entry, the new response SHOULD be used to update the header fields of
+   the existing entry, and the result MUST be returned to the client.
+
+   If any of the existing cache entries contains only partial content
+   for the associated entity, its entity-tag SHOULD NOT be included in
+   the If-None-Match header field unless the request is for a range that
+   would be fully satisfied by that entry.
+
+   If a cache receives a successful response whose Content-Location
+   field matches that of an existing cache entry for the same Request-
+   ]URI, whose entity-tag differs from that of the existing entry, and
+   whose Date is more recent than that of the existing entry, the
+   existing entry SHOULD NOT be returned in response to future requests
+   and SHOULD be deleted from the cache.
+
+13.7 Shared and Non-Shared Caches
+
+   For reasons of security and privacy, it is necessary to make a
+   distinction between "shared" and "non-shared" caches. A non-shared
+   cache is one that is accessible only to a single user. Accessibility
+   in this case SHOULD be enforced by appropriate security mechanisms.
+   All other caches are considered to be "shared." Other sections of
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 96]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   this specification place certain constraints on the operation of
+   shared caches in order to prevent loss of privacy or failure of
+   access controls.
+
+13.8 Errors or Incomplete Response Cache Behavior
+
+   A cache that receives an incomplete response (for example, with fewer
+   bytes of data than specified in a Content-Length header) MAY store
+   the response. However, the cache MUST treat this as a partial
+   response. Partial responses MAY be combined as described in section
+   13.5.4; the result might be a full response or might still be
+   partial. A cache MUST NOT return a partial response to a client
+   without explicitly marking it as such, using the 206 (Partial
+   Content) status code. A cache MUST NOT return a partial response
+   using a status code of 200 (OK).
+
+   If a cache receives a 5xx response while attempting to revalidate an
+   entry, it MAY either forward this response to the requesting client,
+   or act as if the server failed to respond. In the latter case, it MAY
+   return a previously received response unless the cached entry
+   includes the "must-revalidate" cache-control directive (see section
+   14.9).
+
+13.9 Side Effects of GET and HEAD
+
+   Unless the origin server explicitly prohibits the caching of their
+   responses, the application of GET and HEAD methods to any resources
+   SHOULD NOT have side effects that would lead to erroneous behavior if
+   these responses are taken from a cache. They MAY still have side
+   effects, but a cache is not required to consider such side effects in
+   its caching decisions. Caches are always expected to observe an
+   origin server's explicit restrictions on caching.
+
+   We note one exception to this rule: since some applications have
+   traditionally used GETs and HEADs with query URLs (those containing a
+   "?" in the rel_path part) to perform operations with significant side
+   effects, caches MUST NOT treat responses to such URIs as fresh unless
+   the server provides an explicit expiration time. This specifically
+   means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
+   be taken from a cache. See section 9.1.1 for related information.
+
+13.10 Invalidation After Updates or Deletions
+
+   The effect of certain methods performed on a resource at the origin
+   server might cause one or more existing cache entries to become non-
+   transparently invalid. That is, although they might continue to be
+   "fresh," they do not accurately reflect what the origin server would
+   return for a new request on that resource.
+
+
+
+Fielding, et al.            Standards Track                    [Page 97]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   There is no way for the HTTP protocol to guarantee that all such
+   cache entries are marked invalid. For example, the request that
+   caused the change at the origin server might not have gone through
+   the proxy where a cache entry is stored. However, several rules help
+   reduce the likelihood of erroneous behavior.
+
+   In this section, the phrase "invalidate an entity" means that the
+   cache will either remove all instances of that entity from its
+   storage, or will mark these as "invalid" and in need of a mandatory
+   revalidation before they can be returned in response to a subsequent
+   request.
+
+   Some HTTP methods MUST cause a cache to invalidate an entity. This is
+   either the entity referred to by the Request-URI, or by the Location
+   or Content-Location headers (if present). These methods are:
+
+      - PUT
+
+      - DELETE
+
+      - POST
+
+   In order to prevent denial of service attacks, an invalidation based
+   on the URI in a Location or Content-Location header MUST only be
+   performed if the host part is the same as in the Request-URI.
+
+   A cache that passes through requests for methods it does not
+   understand SHOULD invalidate any entities referred to by the
+   Request-URI.
+
+13.11 Write-Through Mandatory
+
+   All methods that might be expected to cause modifications to the
+   origin server's resources MUST be written through to the origin
+   server. This currently includes all methods except for GET and HEAD.
+   A cache MUST NOT reply to such a request from a client before having
+   transmitted the request to the inbound server, and having received a
+   corresponding response from the inbound server. This does not prevent
+   a proxy cache from sending a 100 (Continue) response before the
+   inbound server has sent its final reply.
+
+   The alternative (known as "write-back" or "copy-back" caching) is not
+   allowed in HTTP/1.1, due to the difficulty of providing consistent
+   updates and the problems arising from server, cache, or network
+   failure prior to write-back.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 98]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.12 Cache Replacement
+
+   If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
+   response is received from a resource while any existing responses for
+   the same resource are cached, the cache SHOULD use the new response
+   to reply to the current request. It MAY insert it into cache storage
+   and MAY, if it meets all other requirements, use it to respond to any
+   future requests that would previously have caused the old response to
+   be returned. If it inserts the new response into cache storage  the
+   rules in section 13.5.3 apply.
+
+      Note: a new response that has an older Date header value than
+      existing cached responses is not cacheable.
+
+13.13 History Lists
+
+   User agents often have history mechanisms, such as "Back" buttons and
+   history lists, which can be used to redisplay an entity retrieved
+   earlier in a session.
+
+   History mechanisms and caches are different. In particular history
+   mechanisms SHOULD NOT try to show a semantically transparent view of
+   the current state of a resource. Rather, a history mechanism is meant
+   to show exactly what the user saw at the time when the resource was
+   retrieved.
+
+   By default, an expiration time does not apply to history mechanisms.
+   If the entity is still in storage, a history mechanism SHOULD display
+   it even if the entity has expired, unless the user has specifically
+   configured the agent to refresh expired history documents.
+
+   This is not to be construed to prohibit the history mechanism from
+   telling the user that a view might be stale.
+
+      Note: if history list mechanisms unnecessarily prevent users from
+      viewing stale resources, this will tend to force service authors
+      to avoid using HTTP expiration controls and cache controls when
+      they would otherwise like to. Service authors may consider it
+      important that users not be presented with error messages or
+      warning messages when they use navigation controls (such as BACK)
+      to view previously fetched resources. Even though sometimes such
+      resources ought not to cached, or ought to expire quickly, user
+      interface considerations may force service authors to resort to
+      other means of preventing caching (e.g. "once-only" URLs) in order
+      not to suffer the effects of improperly functioning history
+      mechanisms.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 99]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14 Header Field Definitions
+
+   This section defines the syntax and semantics of all standard
+   HTTP/1.1 header fields. For entity-header fields, both sender and
+   recipient refer to either the client or the server, depending on who
+   sends and who receives the entity.
+
+14.1 Accept
+
+   The Accept request-header field can be used to specify certain media
+   types which are acceptable for the response. Accept headers can be
+   used to indicate that the request is specifically limited to a small
+   set of desired types, as in the case of a request for an in-line
+   image.
+
+       Accept         = "Accept" ":"
+                        #( media-range [ accept-params ] )
+
+       media-range    = ( "*/*"
+                        | ( type "/" "*" )
+                        | ( type "/" subtype )
+                        ) *( ";" parameter )
+       accept-params  = ";" "q" "=" qvalue *( accept-extension )
+       accept-extension = ";" token [ "=" ( token | quoted-string ) ]
+
+   The asterisk "*" character is used to group media types into ranges,
+   with "*/*" indicating all media types and "type/*" indicating all
+   subtypes of that type. The media-range MAY include media type
+   parameters that are applicable to that range.
+
+   Each media-range MAY be followed by one or more accept-params,
+   beginning with the "q" parameter for indicating a relative quality
+   factor. The first "q" parameter (if any) separates the media-range
+   parameter(s) from the accept-params. Quality factors allow the user
+   or user agent to indicate the relative degree of preference for that
+   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
+   default value is q=1.
+
+      Note: Use of the "q" parameter name to separate media type
+      parameters from Accept extension parameters is due to historical
+      practice. Although this prevents any media type parameter named
+      "q" from being used with a media range, such an event is believed
+      to be unlikely given the lack of any "q" parameters in the IANA
+      media type registry and the rare usage of any media type
+      parameters in Accept. Future media types are discouraged from
+      registering any parameter named "q".
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 100]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The example
+
+       Accept: audio/*; q=0.2, audio/basic
+
+   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
+   type if it is the best available after an 80% mark-down in quality."
+
+   If no Accept header field is present, then it is assumed that the
+   client accepts all media types. If an Accept header field is present,
+   and if the server cannot send a response which is acceptable
+   according to the combined Accept field value, then the server SHOULD
+   send a 406 (not acceptable) response.
+
+   A more elaborate example is
+
+       Accept: text/plain; q=0.5, text/html,
+               text/x-dvi; q=0.8, text/x-c
+
+   Verbally, this would be interpreted as "text/html and text/x-c are
+   the preferred media types, but if they do not exist, then send the
+   text/x-dvi entity, and if that does not exist, send the text/plain
+   entity."
+
+   Media ranges can be overridden by more specific media ranges or
+   specific media types. If more than one media range applies to a given
+   type, the most specific reference has precedence. For example,
+
+       Accept: text/*, text/html, text/html;level=1, */*
+
+   have the following precedence:
+
+       1) text/html;level=1
+       2) text/html
+       3) text/*
+       4) */*
+
+   The media type quality factor associated with a given type is
+   determined by finding the media range with the highest precedence
+   which matches that type. For example,
+
+       Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+               text/html;level=2;q=0.4, */*;q=0.5
+
+   would cause the following values to be associated:
+
+       text/html;level=1         = 1
+       text/html                 = 0.7
+       text/plain                = 0.3
+
+
+
+Fielding, et al.            Standards Track                   [Page 101]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       image/jpeg                = 0.5
+       text/html;level=2         = 0.4
+       text/html;level=3         = 0.7
+
+      Note: A user agent might be provided with a default set of quality
+      values for certain media ranges. However, unless the user agent is
+      a closed system which cannot interact with other rendering agents,
+      this default set ought to be configurable by the user.
+
+14.2 Accept-Charset
+
+   The Accept-Charset request-header field can be used to indicate what
+   character sets are acceptable for the response. This field allows
+   clients capable of understanding more comprehensive or special-
+   purpose character sets to signal that capability to a server which is
+   capable of representing documents in those character sets.
+
+      Accept-Charset = "Accept-Charset" ":"
+              1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
+
+
+   Character set values are described in section 3.4. Each charset MAY
+   be given an associated quality value which represents the user's
+   preference for that charset. The default value is q=1. An example is
+
+      Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+
+   The special value "*", if present in the Accept-Charset field,
+   matches every character set (including ISO-8859-1) which is not
+   mentioned elsewhere in the Accept-Charset field. If no "*" is present
+   in an Accept-Charset field, then all character sets not explicitly
+   mentioned get a quality value of 0, except for ISO-8859-1, which gets
+   a quality value of 1 if not explicitly mentioned.
+
+   If no Accept-Charset header is present, the default is that any
+   character set is acceptable. If an Accept-Charset header is present,
+   and if the server cannot send a response which is acceptable
+   according to the Accept-Charset header, then the server SHOULD send
+   an error response with the 406 (not acceptable) status code, though
+   the sending of an unacceptable response is also allowed.
+
+14.3 Accept-Encoding
+
+   The Accept-Encoding request-header field is similar to Accept, but
+   restricts the content-codings (section 3.5) that are acceptable in
+   the response.
+
+       Accept-Encoding  = "Accept-Encoding" ":"
+
+
+
+Fielding, et al.            Standards Track                   [Page 102]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                          1#( codings [ ";" "q" "=" qvalue ] )
+       codings          = ( content-coding | "*" )
+
+   Examples of its use are:
+
+       Accept-Encoding: compress, gzip
+       Accept-Encoding:
+       Accept-Encoding: *
+       Accept-Encoding: compress;q=0.5, gzip;q=1.0
+       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
+
+   A server tests whether a content-coding is acceptable, according to
+   an Accept-Encoding field, using these rules:
+
+      1. If the content-coding is one of the content-codings listed in
+         the Accept-Encoding field, then it is acceptable, unless it is
+         accompanied by a qvalue of 0. (As defined in section 3.9, a
+         qvalue of 0 means "not acceptable.")
+
+      2. The special "*" symbol in an Accept-Encoding field matches any
+         available content-coding not explicitly listed in the header
+         field.
+
+      3. If multiple content-codings are acceptable, then the acceptable
+         content-coding with the highest non-zero qvalue is preferred.
+
+      4. The "identity" content-coding is always acceptable, unless
+         specifically refused because the Accept-Encoding field includes
+         "identity;q=0", or because the field includes "*;q=0" and does
+         not explicitly include the "identity" content-coding. If the
+         Accept-Encoding field-value is empty, then only the "identity"
+         encoding is acceptable.
+
+   If an Accept-Encoding field is present in a request, and if the
+   server cannot send a response which is acceptable according to the
+   Accept-Encoding header, then the server SHOULD send an error response
+   with the 406 (Not Acceptable) status code.
+
+   If no Accept-Encoding field is present in a request, the server MAY
+   assume that the client will accept any content coding. In this case,
+   if "identity" is one of the available content-codings, then the
+   server SHOULD use the "identity" content-coding, unless it has
+   additional information that a different content-coding is meaningful
+   to the client.
+
+      Note: If the request does not include an Accept-Encoding field,
+      and if the "identity" content-coding is unavailable, then
+      content-codings commonly understood by HTTP/1.0 clients (i.e.,
+
+
+
+Fielding, et al.            Standards Track                   [Page 103]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      "gzip" and "compress") are preferred; some older clients
+      improperly display messages sent with other content-codings.  The
+      server might also make this decision based on information about
+      the particular user-agent or client.
+
+      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
+      associated with content-codings. This means that qvalues will not
+      work and are not permitted with x-gzip or x-compress.
+
+14.4 Accept-Language
+
+   The Accept-Language request-header field is similar to Accept, but
+   restricts the set of natural languages that are preferred as a
+   response to the request. Language tags are defined in section 3.10.
+
+       Accept-Language = "Accept-Language" ":"
+                         1#( language-range [ ";" "q" "=" qvalue ] )
+       language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
+
+   Each language-range MAY be given an associated quality value which
+   represents an estimate of the user's preference for the languages
+   specified by that range. The quality value defaults to "q=1". For
+   example,
+
+       Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+   would mean: "I prefer Danish, but will accept British English and
+   other types of English." A language-range matches a language-tag if
+   it exactly equals the tag, or if it exactly equals a prefix of the
+   tag such that the first tag character following the prefix is "-".
+   The special range "*", if present in the Accept-Language field,
+   matches every tag not matched by any other range present in the
+   Accept-Language field.
+
+      Note: This use of a prefix matching rule does not imply that
+      language tags are assigned to languages in such a way that it is
+      always true that if a user understands a language with a certain
+      tag, then this user will also understand all languages with tags
+      for which this tag is a prefix. The prefix rule simply allows the
+      use of prefix tags if this is the case.
+
+   The language quality factor assigned to a language-tag by the
+   Accept-Language field is the quality value of the longest language-
+   range in the field that matches the language-tag. If no language-
+   range in the field matches the tag, the language quality factor
+   assigned is 0. If no Accept-Language header is present in the
+   request, the server
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 104]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   SHOULD assume that all languages are equally acceptable. If an
+   Accept-Language header is present, then all languages which are
+   assigned a quality factor greater than 0 are acceptable.
+
+   It might be contrary to the privacy expectations of the user to send
+   an Accept-Language header with the complete linguistic preferences of
+   the user in every request. For a discussion of this issue, see
+   section 15.1.4.
+
+   As intelligibility is highly dependent on the individual user, it is
+   recommended that client applications make the choice of linguistic
+   preference available to the user. If the choice is not made
+   available, then the Accept-Language header field MUST NOT be given in
+   the request.
+
+      Note: When making the choice of linguistic preference available to
+      the user, we remind implementors of  the fact that users are not
+      familiar with the details of language matching as described above,
+      and should provide appropriate guidance. As an example, users
+      might assume that on selecting "en-gb", they will be served any
+      kind of English document if British English is not available. A
+      user agent might suggest in such a case to add "en" to get the
+      best matching behavior.
+
+14.5 Accept-Ranges
+
+      The Accept-Ranges response-header field allows the server to
+      indicate its acceptance of range requests for a resource:
+
+          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
+          acceptable-ranges = 1#range-unit | "none"
+
+      Origin servers that accept byte-range requests MAY send
+
+          Accept-Ranges: bytes
+
+      but are not required to do so. Clients MAY generate byte-range
+      requests without having received this header for the resource
+      involved. Range units are defined in section 3.12.
+
+      Servers that do not accept any kind of range request for a
+      resource MAY send
+
+          Accept-Ranges: none
+
+      to advise the client not to attempt a range request.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 105]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.6 Age
+
+      The Age response-header field conveys the sender's estimate of the
+      amount of time since the response (or its revalidation) was
+      generated at the origin server. A cached response is "fresh" if
+      its age does not exceed its freshness lifetime. Age values are
+      calculated as specified in section 13.2.3.
+
+           Age = "Age" ":" age-value
+           age-value = delta-seconds
+
+      Age values are non-negative decimal integers, representing time in
+      seconds.
+
+      If a cache receives a value larger than the largest positive
+      integer it can represent, or if any of its age calculations
+      overflows, it MUST transmit an Age header with a value of
+      2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
+      include an Age header field in every response generated from its
+      own cache. Caches SHOULD use an arithmetic type of at least 31
+      bits of range.
+
+14.7 Allow
+
+      The Allow entity-header field lists the set of methods supported
+      by the resource identified by the Request-URI. The purpose of this
+      field is strictly to inform the recipient of valid methods
+      associated with the resource. An Allow header field MUST be
+      present in a 405 (Method Not Allowed) response.
+
+          Allow   = "Allow" ":" #Method
+
+      Example of use:
+
+          Allow: GET, HEAD, PUT
+
+      This field cannot prevent a client from trying other methods.
+      However, the indications given by the Allow header field value
+      SHOULD be followed. The actual set of allowed methods is defined
+      by the origin server at the time of each request.
+
+      The Allow header field MAY be provided with a PUT request to
+      recommend the methods to be supported by the new or modified
+      resource. The server is not required to support these methods and
+      SHOULD include an Allow header in the response giving the actual
+      supported methods.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 106]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      A proxy MUST NOT modify the Allow header field even if it does not
+      understand all the methods specified, since the user agent might
+      have other means of communicating with the origin server.
+
+14.8 Authorization
+
+      A user agent that wishes to authenticate itself with a server--
+      usually, but not necessarily, after receiving a 401 response--does
+      so by including an Authorization request-header field with the
+      request.  The Authorization field value consists of credentials
+      containing the authentication information of the user agent for
+      the realm of the resource being requested.
+
+          Authorization  = "Authorization" ":" credentials
+
+      HTTP access authentication is described in "HTTP Authentication:
+      Basic and Digest Access Authentication" [43]. If a request is
+      authenticated and a realm specified, the same credentials SHOULD
+      be valid for all other requests within this realm (assuming that
+      the authentication scheme itself does not require otherwise, such
+      as credentials that vary according to a challenge value or using
+      synchronized clocks).
+
+      When a shared cache (see section 13.7) receives a request
+      containing an Authorization field, it MUST NOT return the
+      corresponding response as a reply to any other request, unless one
+      of the following specific exceptions holds:
+
+      1. If the response includes the "s-maxage" cache-control
+         directive, the cache MAY use that response in replying to a
+         subsequent request. But (if the specified maximum age has
+         passed) a proxy cache MUST first revalidate it with the origin
+         server, using the request-headers from the new request to allow
+         the origin server to authenticate the new request. (This is the
+         defined behavior for s-maxage.) If the response includes "s-
+         maxage=0", the proxy MUST always revalidate it before re-using
+         it.
+
+      2. If the response includes the "must-revalidate" cache-control
+         directive, the cache MAY use that response in replying to a
+         subsequent request. But if the response is stale, all caches
+         MUST first revalidate it with the origin server, using the
+         request-headers from the new request to allow the origin server
+         to authenticate the new request.
+
+      3. If the response includes the "public" cache-control directive,
+         it MAY be returned in reply to any subsequent request.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 107]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.9 Cache-Control
+
+   The Cache-Control general-header field is used to specify directives
+   that MUST be obeyed by all caching mechanisms along the
+   request/response chain. The directives specify behavior intended to
+   prevent caches from adversely interfering with the request or
+   response. These directives typically override the default caching
+   algorithms. Cache directives are unidirectional in that the presence
+   of a directive in a request does not imply that the same directive is
+   to be given in the response.
+
+      Note that HTTP/1.0 caches might not implement Cache-Control and
+      might only implement Pragma: no-cache (see section 14.32).
+
+   Cache directives MUST be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives might be applicable to all recipients along the
+   request/response chain. It is not possible to specify a cache-
+   directive for a specific cache.
+
+    Cache-Control   = "Cache-Control" ":" 1#cache-directive
+
+    cache-directive = cache-request-directive
+         | cache-response-directive
+
+    cache-request-directive =
+           "no-cache"                          ; Section 14.9.1
+         | "no-store"                          ; Section 14.9.2
+         | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4
+         | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3
+         | "min-fresh" "=" delta-seconds       ; Section 14.9.3
+         | "no-transform"                      ; Section 14.9.5
+         | "only-if-cached"                    ; Section 14.9.4
+         | cache-extension                     ; Section 14.9.6
+
+     cache-response-directive =
+           "public"                               ; Section 14.9.1
+         | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
+         | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
+         | "no-store"                             ; Section 14.9.2
+         | "no-transform"                         ; Section 14.9.5
+         | "must-revalidate"                      ; Section 14.9.4
+         | "proxy-revalidate"                     ; Section 14.9.4
+         | "max-age" "=" delta-seconds            ; Section 14.9.3
+         | "s-maxage" "=" delta-seconds           ; Section 14.9.3
+         | cache-extension                        ; Section 14.9.6
+
+    cache-extension = token [ "=" ( token | quoted-string ) ]
+
+
+
+Fielding, et al.            Standards Track                   [Page 108]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   When a directive appears without any 1#field-name parameter, the
+   directive applies to the entire request or response. When such a
+   directive appears with a 1#field-name parameter, it applies only to
+   the named field or fields, and not to the rest of the request or
+   response. This mechanism supports extensibility; implementations of
+   future versions of the HTTP protocol might apply these directives to
+   header fields not defined in HTTP/1.1.
+
+   The cache-control directives can be broken down into these general
+   categories:
+
+      - Restrictions on what are cacheable; these may only be imposed by
+        the origin server.
+
+      - Restrictions on what may be stored by a cache; these may be
+        imposed by either the origin server or the user agent.
+
+      - Modifications of the basic expiration mechanism; these may be
+        imposed by either the origin server or the user agent.
+
+      - Controls over cache revalidation and reload; these may only be
+        imposed by a user agent.
+
+      - Control over transformation of entities.
+
+      - Extensions to the caching system.
+
+14.9.1 What is Cacheable
+
+   By default, a response is cacheable if the requirements of the
+   request method, request header fields, and the response status
+   indicate that it is cacheable. Section 13.4 summarizes these defaults
+   for cacheability. The following Cache-Control response directives
+   allow an origin server to override the default cacheability of a
+   response:
+
+   public
+      Indicates that the response MAY be cached by any cache, even if it
+      would normally be non-cacheable or cacheable only within a non-
+      shared cache. (See also Authorization, section 14.8, for
+      additional details.)
+
+   private
+      Indicates that all or part of the response message is intended for
+      a single user and MUST NOT be cached by a shared cache. This
+      allows an origin server to state that the specified parts of the
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 109]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      response are intended for only one user and are not a valid
+      response for requests by other users. A private (non-shared) cache
+      MAY cache the response.
+
+       Note: This usage of the word private only controls where the
+       response may be cached, and cannot ensure the privacy of the
+       message content.
+
+   no-cache
+       If the no-cache directive does not specify a field-name, then a
+      cache MUST NOT use the response to satisfy a subsequent request
+      without successful revalidation with the origin server. This
+      allows an origin server to prevent caching even by caches that
+      have been configured to return stale responses to client requests.
+
+      If the no-cache directive does specify one or more field-names,
+      then a cache MAY use the response to satisfy a subsequent request,
+      subject to any other restrictions on caching. However, the
+      specified field-name(s) MUST NOT be sent in the response to a
+      subsequent request without successful revalidation with the origin
+      server. This allows an origin server to prevent the re-use of
+      certain header fields in a response, while still allowing caching
+      of the rest of the response.
+
+       Note: Most HTTP/1.0 caches will not recognize or obey this
+       directive.
+
+14.9.2 What May be Stored by Caches
+
+   no-store
+      The purpose of the no-store directive is to prevent the
+      inadvertent release or retention of sensitive information (for
+      example, on backup tapes). The no-store directive applies to the
+      entire message, and MAY be sent either in a response or in a
+      request. If sent in a request, a cache MUST NOT store any part of
+      either this request or any response to it. If sent in a response,
+      a cache MUST NOT store any part of either this response or the
+      request that elicited it. This directive applies to both non-
+      shared and shared caches. "MUST NOT store" in this context means
+      that the cache MUST NOT intentionally store the information in
+      non-volatile storage, and MUST make a best-effort attempt to
+      remove the information from volatile storage as promptly as
+      possible after forwarding it.
+
+      Even when this directive is associated with a response, users
+      might explicitly store such a response outside of the caching
+      system (e.g., with a "Save As" dialog). History buffers MAY store
+      such responses as part of their normal operation.
+
+
+
+Fielding, et al.            Standards Track                   [Page 110]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      The purpose of this directive is to meet the stated requirements
+      of certain users and service authors who are concerned about
+      accidental releases of information via unanticipated accesses to
+      cache data structures. While the use of this directive might
+      improve privacy in some cases, we caution that it is NOT in any
+      way a reliable or sufficient mechanism for ensuring privacy. In
+      particular, malicious or compromised caches might not recognize or
+      obey this directive, and communications networks might be
+      vulnerable to eavesdropping.
+
+14.9.3 Modifications of the Basic Expiration Mechanism
+
+   The expiration time of an entity MAY be specified by the origin
+   server using the Expires header (see section 14.21). Alternatively,
+   it MAY be specified using the max-age directive in a response. When
+   the max-age cache-control directive is present in a cached response,
+   the response is stale if its current age is greater than the age
+   value given (in seconds) at the time of a new request for that
+   resource. The max-age directive on a response implies that the
+   response is cacheable (i.e., "public") unless some other, more
+   restrictive cache directive is also present.
+
+   If a response includes both an Expires header and a max-age
+   directive, the max-age directive overrides the Expires header, even
+   if the Expires header is more restrictive. This rule allows an origin
+   server to provide, for a given response, a longer expiration time to
+   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
+   useful if certain HTTP/1.0 caches improperly calculate ages or
+   expiration times, perhaps due to desynchronized clocks.
+
+   Many HTTP/1.0 cache implementations will treat an Expires value that
+   is less than or equal to the response Date value as being equivalent
+   to the Cache-Control response directive "no-cache". If an HTTP/1.1
+   cache receives such a response, and the response does not include a
+   Cache-Control header field, it SHOULD consider the response to be
+   non-cacheable in order to retain compatibility with HTTP/1.0 servers.
+
+       Note: An origin server might wish to use a relatively new HTTP
+       cache control feature, such as the "private" directive, on a
+       network including older caches that do not understand that
+       feature. The origin server will need to combine the new feature
+       with an Expires field whose value is less than or equal to the
+       Date value. This will prevent older caches from improperly
+       caching the response.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 111]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   s-maxage
+       If a response includes an s-maxage directive, then for a shared
+       cache (but not for a private cache), the maximum age specified by
+       this directive overrides the maximum age specified by either the
+       max-age directive or the Expires header. The s-maxage directive
+       also implies the semantics of the proxy-revalidate directive (see
+       section 14.9.4), i.e., that the shared cache must not use the
+       entry after it becomes stale to respond to a subsequent request
+       without first revalidating it with the origin server. The s-
+       maxage directive is always ignored by a private cache.
+
+   Note that most older caches, not compliant with this specification,
+   do not implement any cache-control directives. An origin server
+   wishing to use a cache-control directive that restricts, but does not
+   prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
+   requirement that the max-age directive overrides the Expires header,
+   and the fact that pre-HTTP/1.1-compliant caches do not observe the
+   max-age directive.
+
+   Other directives allow a user agent to modify the basic expiration
+   mechanism. These directives MAY be specified on a request:
+
+   max-age
+      Indicates that the client is willing to accept a response whose
+      age is no greater than the specified time in seconds. Unless max-
+      stale directive is also included, the client is not willing to
+      accept a stale response.
+
+   min-fresh
+      Indicates that the client is willing to accept a response whose
+      freshness lifetime is no less than its current age plus the
+      specified time in seconds. That is, the client wants a response
+      that will still be fresh for at least the specified number of
+      seconds.
+
+   max-stale
+      Indicates that the client is willing to accept a response that has
+      exceeded its expiration time. If max-stale is assigned a value,
+      then the client is willing to accept a response that has exceeded
+      its expiration time by no more than the specified number of
+      seconds. If no value is assigned to max-stale, then the client is
+      willing to accept a stale response of any age.
+
+   If a cache returns a stale response, either because of a max-stale
+   directive on a request, or because the cache is configured to
+   override the expiration time of a response, the cache MUST attach a
+   Warning header to the stale response, using Warning 110 (Response is
+   stale).
+
+
+
+Fielding, et al.            Standards Track                   [Page 112]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A cache MAY be configured to return stale responses without
+   validation, but only if this does not conflict with any "MUST"-level
+   requirements concerning cache validation (e.g., a "must-revalidate"
+   cache-control directive).
+
+   If both the new request and the cached entry include "max-age"
+   directives, then the lesser of the two values is used for determining
+   the freshness of the cached entry for that request.
+
+14.9.4 Cache Revalidation and Reload Controls
+
+   Sometimes a user agent might want or need to insist that a cache
+   revalidate its cache entry with the origin server (and not just with
+   the next cache along the path to the origin server), or to reload its
+   cache entry from the origin server. End-to-end revalidation might be
+   necessary if either the cache or the origin server has overestimated
+   the expiration time of the cached response. End-to-end reload may be
+   necessary if the cache entry has become corrupted for some reason.
+
+   End-to-end revalidation may be requested either when the client does
+   not have its own local cached copy, in which case we call it
+   "unspecified end-to-end revalidation", or when the client does have a
+   local cached copy, in which case we call it "specific end-to-end
+   revalidation."
+
+   The client can specify these three kinds of action using Cache-
+   Control request directives:
+
+   End-to-end reload
+      The request includes a "no-cache" cache-control directive or, for
+      compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
+      names MUST NOT be included with the no-cache directive in a
+      request. The server MUST NOT use a cached copy when responding to
+      such a request.
+
+   Specific end-to-end revalidation
+      The request includes a "max-age=0" cache-control directive, which
+      forces each cache along the path to the origin server to
+      revalidate its own entry, if any, with the next cache or server.
+      The initial request includes a cache-validating conditional with
+      the client's current validator.
+
+   Unspecified end-to-end revalidation
+      The request includes "max-age=0" cache-control directive, which
+      forces each cache along the path to the origin server to
+      revalidate its own entry, if any, with the next cache or server.
+      The initial request does not include a cache-validating
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 113]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      conditional; the first cache along the path (if any) that holds a
+      cache entry for this resource includes a cache-validating
+      conditional with its current validator.
+
+   max-age
+      When an intermediate cache is forced, by means of a max-age=0
+      directive, to revalidate its own cache entry, and the client has
+      supplied its own validator in the request, the supplied validator
+      might differ from the validator currently stored with the cache
+      entry. In this case, the cache MAY use either validator in making
+      its own request without affecting semantic transparency.
+
+      However, the choice of validator might affect performance. The
+      best approach is for the intermediate cache to use its own
+      validator when making its request. If the server replies with 304
+      (Not Modified), then the cache can return its now validated copy
+      to the client with a 200 (OK) response. If the server replies with
+      a new entity and cache validator, however, the intermediate cache
+      can compare the returned validator with the one provided in the
+      client's request, using the strong comparison function. If the
+      client's validator is equal to the origin server's, then the
+      intermediate cache simply returns 304 (Not Modified). Otherwise,
+      it returns the new entity with a 200 (OK) response.
+
+      If a request includes the no-cache directive, it SHOULD NOT
+      include min-fresh, max-stale, or max-age.
+
+   only-if-cached
+      In some cases, such as times of extremely poor network
+      connectivity, a client may want a cache to return only those
+      responses that it currently has stored, and not to reload or
+      revalidate with the origin server. To do this, the client may
+      include the only-if-cached directive in a request. If it receives
+      this directive, a cache SHOULD either respond using a cached entry
+      that is consistent with the other constraints of the request, or
+      respond with a 504 (Gateway Timeout) status. However, if a group
+      of caches is being operated as a unified system with good internal
+      connectivity, such a request MAY be forwarded within that group of
+      caches.
+
+   must-revalidate
+      Because a cache MAY be configured to ignore a server's specified
+      expiration time, and because a client request MAY include a max-
+      stale directive (which has a similar effect), the protocol also
+      includes a mechanism for the origin server to require revalidation
+      of a cache entry on any subsequent use. When the must-revalidate
+      directive is present in a response received by a cache, that cache
+      MUST NOT use the entry after it becomes stale to respond to a
+
+
+
+Fielding, et al.            Standards Track                   [Page 114]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      subsequent request without first revalidating it with the origin
+      server. (I.e., the cache MUST do an end-to-end revalidation every
+      time, if, based solely on the origin server's Expires or max-age
+      value, the cached response is stale.)
+
+      The must-revalidate directive is necessary to support reliable
+      operation for certain protocol features. In all circumstances an
+      HTTP/1.1 cache MUST obey the must-revalidate directive; in
+      particular, if the cache cannot reach the origin server for any
+      reason, it MUST generate a 504 (Gateway Timeout) response.
+
+      Servers SHOULD send the must-revalidate directive if and only if
+      failure to revalidate a request on the entity could result in
+      incorrect operation, such as a silently unexecuted financial
+      transaction. Recipients MUST NOT take any automated action that
+      violates this directive, and MUST NOT automatically provide an
+      unvalidated copy of the entity if revalidation fails.
+
+      Although this is not recommended, user agents operating under
+      severe connectivity constraints MAY violate this directive but, if
+      so, MUST explicitly warn the user that an unvalidated response has
+      been provided. The warning MUST be provided on each unvalidated
+      access, and SHOULD require explicit user confirmation.
+
+   proxy-revalidate
+      The proxy-revalidate directive has the same meaning as the must-
+      revalidate directive, except that it does not apply to non-shared
+      user agent caches. It can be used on a response to an
+      authenticated request to permit the user's cache to store and
+      later return the response without needing to revalidate it (since
+      it has already been authenticated once by that user), while still
+      requiring proxies that service many users to revalidate each time
+      (in order to make sure that each user has been authenticated).
+      Note that such authenticated responses also need the public cache
+      control directive in order to allow them to be cached at all.
+
+14.9.5 No-Transform Directive
+
+   no-transform
+      Implementors of intermediate caches (proxies) have found it useful
+      to convert the media type of certain entity bodies. A non-
+      transparent proxy might, for example, convert between image
+      formats in order to save cache space or to reduce the amount of
+      traffic on a slow link.
+
+      Serious operational problems occur, however, when these
+      transformations are applied to entity bodies intended for certain
+      kinds of applications. For example, applications for medical
+
+
+
+Fielding, et al.            Standards Track                   [Page 115]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      imaging, scientific data analysis and those using end-to-end
+      authentication, all depend on receiving an entity body that is bit
+      for bit identical to the original entity-body.
+
+      Therefore, if a message includes the no-transform directive, an
+      intermediate cache or proxy MUST NOT change those headers that are
+      listed in section 13.5.2 as being subject to the no-transform
+      directive. This implies that the cache or proxy MUST NOT change
+      any aspect of the entity-body that is specified by these headers,
+      including the value of the entity-body itself.
+
+14.9.6 Cache Control Extensions
+
+   The Cache-Control header field can be extended through the use of one
+   or more cache-extension tokens, each with an optional assigned value.
+   Informational extensions (those which do not require a change in
+   cache behavior) MAY be added without changing the semantics of other
+   directives. Behavioral extensions are designed to work by acting as
+   modifiers to the existing base of cache directives. Both the new
+   directive and the standard directive are supplied, such that
+   applications which do not understand the new directive will default
+   to the behavior specified by the standard directive, and those that
+   understand the new directive will recognize it as modifying the
+   requirements associated with the standard directive. In this way,
+   extensions to the cache-control directives can be made without
+   requiring changes to the base protocol.
+
+   This extension mechanism depends on an HTTP cache obeying all of the
+   cache-control directives defined for its native HTTP-version, obeying
+   certain extensions, and ignoring all directives that it does not
+   understand.
+
+   For example, consider a hypothetical new response directive called
+   community which acts as a modifier to the private directive. We
+   define this new directive to mean that, in addition to any non-shared
+   cache, any cache which is shared only by members of the community
+   named within its value may cache the response. An origin server
+   wishing to allow the UCI community to use an otherwise private
+   response in their shared cache(s) could do so by including
+
+       Cache-Control: private, community="UCI"
+
+   A cache seeing this header field will act correctly even if the cache
+   does not understand the community cache-extension, since it will also
+   see and understand the private directive and thus default to the safe
+   behavior.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 116]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Unrecognized cache-directives MUST be ignored; it is assumed that any
+   cache-directive likely to be unrecognized by an HTTP/1.1 cache will
+   be combined with standard directives (or the response's default
+   cacheability) such that the cache behavior will remain minimally
+   correct even if the cache does not understand the extension(s).
+
+14.10 Connection
+
+   The Connection general-header field allows the sender to specify
+   options that are desired for that particular connection and MUST NOT
+   be communicated by proxies over further connections.
+
+   The Connection header has the following grammar:
+
+       Connection = "Connection" ":" 1#(connection-token)
+       connection-token  = token
+
+   HTTP/1.1 proxies MUST parse the Connection header field before a
+   message is forwarded and, for each connection-token in this field,
+   remove any header field(s) from the message with the same name as the
+   connection-token. Connection options are signaled by the presence of
+   a connection-token in the Connection header field, not by any
+   corresponding additional header field(s), since the additional header
+   field may not be sent if there are no parameters associated with that
+   connection option.
+
+   Message headers listed in the Connection header MUST NOT include
+   end-to-end headers, such as Cache-Control.
+
+   HTTP/1.1 defines the "close" connection option for the sender to
+   signal that the connection will be closed after completion of the
+   response. For example,
+
+       Connection: close
+
+   in either the request or the response header fields indicates that
+   the connection SHOULD NOT be considered `persistent' (section 8.1)
+   after the current request/response is complete.
+
+   HTTP/1.1 applications that do not support persistent connections MUST
+   include the "close" connection option in every message.
+
+   A system receiving an HTTP/1.0 (or lower-version) message that
+   includes a Connection header MUST, for each connection-token in this
+   field, remove and ignore any header field(s) from the message with
+   the same name as the connection-token. This protects against mistaken
+   forwarding of such header fields by pre-HTTP/1.1 proxies. See section
+   19.6.2.
+
+
+
+Fielding, et al.            Standards Track                   [Page 117]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.11 Content-Encoding
+
+   The Content-Encoding entity-header field is used as a modifier to the
+   media-type. When present, its value indicates what additional content
+   codings have been applied to the entity-body, and thus what decoding
+   mechanisms must be applied in order to obtain the media-type
+   referenced by the Content-Type header field. Content-Encoding is
+   primarily used to allow a document to be compressed without losing
+   the identity of its underlying media type.
+
+       Content-Encoding  = "Content-Encoding" ":" 1#content-coding
+
+   Content codings are defined in section 3.5. An example of its use is
+
+       Content-Encoding: gzip
+
+   The content-coding is a characteristic of the entity identified by
+   the Request-URI. Typically, the entity-body is stored with this
+   encoding and is only decoded before rendering or analogous usage.
+   However, a non-transparent proxy MAY modify the content-coding if the
+   new coding is known to be acceptable to the recipient, unless the
+   "no-transform" cache-control directive is present in the message.
+
+   If the content-coding of an entity is not "identity", then the
+   response MUST include a Content-Encoding entity-header (section
+   14.11) that lists the non-identity content-coding(s) used.
+
+   If the content-coding of an entity in a request message is not
+   acceptable to the origin server, the server SHOULD respond with a
+   status code of 415 (Unsupported Media Type).
+
+   If multiple encodings have been applied to an entity, the content
+   codings MUST be listed in the order in which they were applied.
+   Additional information about the encoding parameters MAY be provided
+   by other entity-header fields not defined by this specification.
+
+14.12 Content-Language
+
+   The Content-Language entity-header field describes the natural
+   language(s) of the intended audience for the enclosed entity. Note
+   that this might not be equivalent to all the languages used within
+   the entity-body.
+
+       Content-Language  = "Content-Language" ":" 1#language-tag
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 118]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Language tags are defined in section 3.10. The primary purpose of
+   Content-Language is to allow a user to identify and differentiate
+   entities according to the user's own preferred language. Thus, if the
+   body content is intended only for a Danish-literate audience, the
+   appropriate field is
+
+       Content-Language: da
+
+   If no Content-Language is specified, the default is that the content
+   is intended for all language audiences. This might mean that the
+   sender does not consider it to be specific to any natural language,
+   or that the sender does not know for which language it is intended.
+
+   Multiple languages MAY be listed for content that is intended for
+   multiple audiences. For example, a rendition of the "Treaty of
+   Waitangi," presented simultaneously in the original Maori and English
+   versions, would call for
+
+       Content-Language: mi, en
+
+   However, just because multiple languages are present within an entity
+   does not mean that it is intended for multiple linguistic audiences.
+   An example would be a beginner's language primer, such as "A First
+   Lesson in Latin," which is clearly intended to be used by an
+   English-literate audience. In this case, the Content-Language would
+   properly only include "en".
+
+   Content-Language MAY be applied to any media type -- it is not
+   limited to textual documents.
+
+14.13 Content-Length
+
+   The Content-Length entity-header field indicates the size of the
+   entity-body, in decimal number of OCTETs, sent to the recipient or,
+   in the case of the HEAD method, the size of the entity-body that
+   would have been sent had the request been a GET.
+
+       Content-Length    = "Content-Length" ":" 1*DIGIT
+
+   An example is
+
+       Content-Length: 3495
+
+   Applications SHOULD use this field to indicate the transfer-length of
+   the message-body, unless this is prohibited by the rules in section
+   4.4.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 119]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Any Content-Length greater than or equal to zero is a valid value.
+   Section 4.4 describes how to determine the length of a message-body
+   if a Content-Length is not given.
+
+   Note that the meaning of this field is significantly different from
+   the corresponding definition in MIME, where it is an optional field
+   used within the "message/external-body" content-type. In HTTP, it
+   SHOULD be sent whenever the message's length can be determined prior
+   to being transferred, unless this is prohibited by the rules in
+   section 4.4.
+
+14.14 Content-Location
+
+   The Content-Location entity-header field MAY be used to supply the
+   resource location for the entity enclosed in the message when that
+   entity is accessible from a location separate from the requested
+   resource's URI. A server SHOULD provide a Content-Location for the
+   variant corresponding to the response entity; especially in the case
+   where a resource has multiple entities associated with it, and those
+   entities actually have separate locations by which they might be
+   individually accessed, the server SHOULD provide a Content-Location
+   for the particular variant which is returned.
+
+       Content-Location = "Content-Location" ":"
+                         ( absoluteURI | relativeURI )
+
+   The value of Content-Location also defines the base URI for the
+   entity.
+
+   The Content-Location value is not a replacement for the original
+   requested URI; it is only a statement of the location of the resource
+   corresponding to this particular entity at the time of the request.
+   Future requests MAY specify the Content-Location URI as the request-
+   URI if the desire is to identify the source of that particular
+   entity.
+
+   A cache cannot assume that an entity with a Content-Location
+   different from the URI used to retrieve it can be used to respond to
+   later requests on that Content-Location URI. However, the Content-
+   Location can be used to differentiate between multiple entities
+   retrieved from a single requested resource, as described in section
+   13.6.
+
+   If the Content-Location is a relative URI, the relative URI is
+   interpreted relative to the Request-URI.
+
+   The meaning of the Content-Location header in PUT or POST requests is
+   undefined; servers are free to ignore it in those cases.
+
+
+
+Fielding, et al.            Standards Track                   [Page 120]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.15 Content-MD5
+
+   The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
+   an MD5 digest of the entity-body for the purpose of providing an
+   end-to-end message integrity check (MIC) of the entity-body. (Note: a
+   MIC is good for detecting accidental modification of the entity-body
+   in transit, but is not proof against malicious attacks.)
+
+        Content-MD5   = "Content-MD5" ":" md5-digest
+        md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>
+
+   The Content-MD5 header field MAY be generated by an origin server or
+   client to function as an integrity check of the entity-body. Only
+   origin servers or clients MAY generate the Content-MD5 header field;
+   proxies and gateways MUST NOT generate it, as this would defeat its
+   value as an end-to-end integrity check. Any recipient of the entity-
+   body, including gateways and proxies, MAY check that the digest value
+   in this header field matches that of the entity-body as received.
+
+   The MD5 digest is computed based on the content of the entity-body,
+   including any content-coding that has been applied, but not including
+   any transfer-encoding applied to the message-body. If the message is
+   received with a transfer-encoding, that encoding MUST be removed
+   prior to checking the Content-MD5 value against the received entity.
+
+   This has the result that the digest is computed on the octets of the
+   entity-body exactly as, and in the order that, they would be sent if
+   no transfer-encoding were being applied.
+
+   HTTP extends RFC 1864 to permit the digest to be computed for MIME
+   composite media-types (e.g., multipart/* and message/rfc822), but
+   this does not change how the digest is computed as defined in the
+   preceding paragraph.
+
+   There are several consequences of this. The entity-body for composite
+   types MAY contain many body-parts, each with its own MIME and HTTP
+   headers (including Content-MD5, Content-Transfer-Encoding, and
+   Content-Encoding headers). If a body-part has a Content-Transfer-
+   Encoding or Content-Encoding header, it is assumed that the content
+   of the body-part has had the encoding applied, and the body-part is
+   included in the Content-MD5 digest as is -- i.e., after the
+   application. The Transfer-Encoding header field is not allowed within
+   body-parts.
+
+   Conversion of all line breaks to CRLF MUST NOT be done before
+   computing or checking the digest: the line break convention used in
+   the text actually transmitted MUST be left unaltered when computing
+   the digest.
+
+
+
+Fielding, et al.            Standards Track                   [Page 121]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      Note: while the definition of Content-MD5 is exactly the same for
+      HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
+      in which the application of Content-MD5 to HTTP entity-bodies
+      differs from its application to MIME entity-bodies. One is that
+      HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
+      does use Transfer-Encoding and Content-Encoding. Another is that
+      HTTP more frequently uses binary content types than MIME, so it is
+      worth noting that, in such cases, the byte order used to compute
+      the digest is the transmission byte order defined for the type.
+      Lastly, HTTP allows transmission of text types with any of several
+      line break conventions and not just the canonical form using CRLF.
+
+14.16 Content-Range
+
+   The Content-Range entity-header is sent with a partial entity-body to
+   specify where in the full entity-body the partial body should be
+   applied. Range units are defined in section 3.12.
+
+       Content-Range = "Content-Range" ":" content-range-spec
+
+       content-range-spec      = byte-content-range-spec
+       byte-content-range-spec = bytes-unit SP
+                                 byte-range-resp-spec "/"
+                                 ( instance-length | "*" )
+
+       byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
+                                      | "*"
+       instance-length           = 1*DIGIT
+
+   The header SHOULD indicate the total length of the full entity-body,
+   unless this length is unknown or difficult to determine. The asterisk
+   "*" character means that the instance-length is unknown at the time
+   when the response was generated.
+
+   Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
+   range-resp-spec MUST only specify one range, and MUST contain
+   absolute byte positions for both the first and last byte of the
+   range.
+
+   A byte-content-range-spec with a byte-range-resp-spec whose last-
+   byte-pos value is less than its first-byte-pos value, or whose
+   instance-length value is less than or equal to its last-byte-pos
+   value, is invalid. The recipient of an invalid byte-content-range-
+   spec MUST ignore it and any content transferred along with it.
+
+   A server sending a response with status code 416 (Requested range not
+   satisfiable) SHOULD include a Content-Range field with a byte-range-
+   resp-spec of "*". The instance-length specifies the current length of
+
+
+
+Fielding, et al.            Standards Track                   [Page 122]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the selected resource. A response with status code 206 (Partial
+   Content) MUST NOT include a Content-Range field with a byte-range-
+   resp-spec of "*".
+
+   Examples of byte-content-range-spec values, assuming that the entity
+   contains a total of 1234 bytes:
+
+      . The first 500 bytes:
+       bytes 0-499/1234
+
+      . The second 500 bytes:
+       bytes 500-999/1234
+
+      . All except for the first 500 bytes:
+       bytes 500-1233/1234
+
+      . The last 500 bytes:
+       bytes 734-1233/1234
+
+   When an HTTP message includes the content of a single range (for
+   example, a response to a request for a single range, or to a request
+   for a set of ranges that overlap without any holes), this content is
+   transmitted with a Content-Range header, and a Content-Length header
+   showing the number of bytes actually transferred. For example,
+
+       HTTP/1.1 206 Partial content
+       Date: Wed, 15 Nov 1995 06:25:24 GMT
+       Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+       Content-Range: bytes 21010-47021/47022
+       Content-Length: 26012
+       Content-Type: image/gif
+
+   When an HTTP message includes the content of multiple ranges (for
+   example, a response to a request for multiple non-overlapping
+   ranges), these are transmitted as a multipart message. The multipart
+   media type used for this purpose is "multipart/byteranges" as defined
+   in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
+
+   A response to a request for a single range MUST NOT be sent using the
+   multipart/byteranges media type.  A response to a request for
+   multiple ranges, whose result is a single range, MAY be sent as a
+   multipart/byteranges media type with one part. A client that cannot
+   decode a multipart/byteranges message MUST NOT ask for multiple
+   byte-ranges in a single request.
+
+   When a client requests multiple byte-ranges in one request, the
+   server SHOULD return them in the order that they appeared in the
+   request.
+
+
+
+Fielding, et al.            Standards Track                   [Page 123]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the server ignores a byte-range-spec because it is syntactically
+   invalid, the server SHOULD treat the request as if the invalid Range
+   header field did not exist. (Normally, this means return a 200
+   response containing the full entity).
+
+   If the server receives a request (other than one including an If-
+   Range request-header field) with an unsatisfiable Range request-
+   header field (that is, all of whose byte-range-spec values have a
+   first-byte-pos value greater than the current length of the selected
+   resource), it SHOULD return a response code of 416 (Requested range
+   not satisfiable) (section 10.4.17).
+
+      Note: clients cannot depend on servers to send a 416 (Requested
+      range not satisfiable) response instead of a 200 (OK) response for
+      an unsatisfiable Range request-header, since not all servers
+      implement this request-header.
+
+14.17 Content-Type
+
+   The Content-Type entity-header field indicates the media type of the
+   entity-body sent to the recipient or, in the case of the HEAD method,
+   the media type that would have been sent had the request been a GET.
+
+       Content-Type   = "Content-Type" ":" media-type
+
+   Media types are defined in section 3.7. An example of the field is
+
+       Content-Type: text/html; charset=ISO-8859-4
+
+   Further discussion of methods for identifying the media type of an
+   entity is provided in section 7.2.1.
+
+14.18 Date
+
+   The Date general-header field represents the date and time at which
+   the message was originated, having the same semantics as orig-date in
+   RFC 822. The field value is an HTTP-date, as described in section
+   3.3.1; it MUST be sent in RFC 1123 [8]-date format.
+
+       Date  = "Date" ":" HTTP-date
+
+   An example is
+
+       Date: Tue, 15 Nov 1994 08:12:31 GMT
+
+   Origin servers MUST include a Date header field in all responses,
+   except in these cases:
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 124]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      1. If the response status code is 100 (Continue) or 101 (Switching
+         Protocols), the response MAY include a Date header field, at
+         the server's option.
+
+      2. If the response status code conveys a server error, e.g. 500
+         (Internal Server Error) or 503 (Service Unavailable), and it is
+         inconvenient or impossible to generate a valid Date.
+
+      3. If the server does not have a clock that can provide a
+         reasonable approximation of the current time, its responses
+         MUST NOT include a Date header field. In this case, the rules
+         in section 14.18.1 MUST be followed.
+
+   A received message that does not have a Date header field MUST be
+   assigned one by the recipient if the message will be cached by that
+   recipient or gatewayed via a protocol which requires a Date. An HTTP
+   implementation without a clock MUST NOT cache responses without
+   revalidating them on every use. An HTTP cache, especially a shared
+   cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
+   clock with a reliable external standard.
+
+   Clients SHOULD only send a Date header field in messages that include
+   an entity-body, as in the case of the PUT and POST requests, and even
+   then it is optional. A client without a clock MUST NOT send a Date
+   header field in a request.
+
+   The HTTP-date sent in a Date header SHOULD NOT represent a date and
+   time subsequent to the generation of the message. It SHOULD represent
+   the best available approximation of the date and time of message
+   generation, unless the implementation has no means of generating a
+   reasonably accurate date and time. In theory, the date ought to
+   represent the moment just before the entity is generated. In
+   practice, the date can be generated at any time during the message
+   origination without affecting its semantic value.
+
+14.18.1 Clockless Origin Server Operation
+
+   Some origin server implementations might not have a clock available.
+   An origin server without a clock MUST NOT assign Expires or Last-
+   Modified values to a response, unless these values were associated
+   with the resource by a system or user with a reliable clock. It MAY
+   assign an Expires value that is known, at or before server
+   configuration time, to be in the past (this allows "pre-expiration"
+   of responses without storing separate Expires values for each
+   resource).
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 125]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.19 ETag
+
+   The ETag response-header field provides the current value of the
+   entity tag for the requested variant. The headers used with entity
+   tags are described in sections 14.24, 14.26 and 14.44. The entity tag
+   MAY be used for comparison with other entities from the same resource
+   (see section 13.3.3).
+
+      ETag = "ETag" ":" entity-tag
+
+   Examples:
+
+      ETag: "xyzzy"
+      ETag: W/"xyzzy"
+      ETag: ""
+
+14.20 Expect
+
+   The Expect request-header field is used to indicate that particular
+   server behaviors are required by the client.
+
+      Expect       =  "Expect" ":" 1#expectation
+
+      expectation  =  "100-continue" | expectation-extension
+      expectation-extension =  token [ "=" ( token | quoted-string )
+                               *expect-params ]
+      expect-params =  ";" token [ "=" ( token | quoted-string ) ]
+
+
+   A server that does not understand or is unable to comply with any of
+   the expectation values in the Expect field of a request MUST respond
+   with appropriate error status. The server MUST respond with a 417
+   (Expectation Failed) status if any of the expectations cannot be met
+   or, if there are other problems with the request, some other 4xx
+   status.
+
+   This header field is defined with extensible syntax to allow for
+   future extensions. If a server receives a request containing an
+   Expect field that includes an expectation-extension that it does not
+   support, it MUST respond with a 417 (Expectation Failed) status.
+
+   Comparison of expectation values is case-insensitive for unquoted
+   tokens (including the 100-continue token), and is case-sensitive for
+   quoted-string expectation-extensions.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 126]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
+   return a 417 (Expectation Failed) status if it receives a request
+   with an expectation that it cannot meet. However, the Expect
+   request-header itself is end-to-end; it MUST be forwarded if the
+   request is forwarded.
+
+   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
+   Expect header.
+
+   See section 8.2.3 for the use of the 100 (continue) status.
+
+14.21 Expires
+
+   The Expires entity-header field gives the date/time after which the
+   response is considered stale. A stale cache entry may not normally be
+   returned by a cache (either a proxy cache or a user agent cache)
+   unless it is first validated with the origin server (or with an
+   intermediate cache that has a fresh copy of the entity). See section
+   13.2 for further discussion of the expiration model.
+
+   The presence of an Expires field does not imply that the original
+   resource will change or cease to exist at, before, or after that
+   time.
+
+   The format is an absolute date and time as defined by HTTP-date in
+   section 3.3.1; it MUST be in RFC 1123 date format:
+
+      Expires = "Expires" ":" HTTP-date
+
+   An example of its use is
+
+      Expires: Thu, 01 Dec 1994 16:00:00 GMT
+
+      Note: if a response includes a Cache-Control field with the max-
+      age directive (see section 14.9.3), that directive overrides the
+      Expires field.
+
+   HTTP/1.1 clients and caches MUST treat other invalid date formats,
+   especially including the value "0", as in the past (i.e., "already
+   expired").
+
+   To mark a response as "already expired," an origin server sends an
+   Expires date that is equal to the Date header value. (See the rules
+   for expiration calculations in section 13.2.4.)
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 127]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   To mark a response as "never expires," an origin server sends an
+   Expires date approximately one year from the time the response is
+   sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
+   year in the future.
+
+   The presence of an Expires header field with a date value of some
+   time in the future on a response that otherwise would by default be
+   non-cacheable indicates that the response is cacheable, unless
+   indicated otherwise by a Cache-Control header field (section 14.9).
+
+14.22 From
+
+   The From request-header field, if given, SHOULD contain an Internet
+   e-mail address for the human user who controls the requesting user
+   agent. The address SHOULD be machine-usable, as defined by "mailbox"
+   in RFC 822 [9] as updated by RFC 1123 [8]:
+
+       From   = "From" ":" mailbox
+
+   An example is:
+
+       From: webmaster@w3.org
+
+   This header field MAY be used for logging purposes and as a means for
+   identifying the source of invalid or unwanted requests. It SHOULD NOT
+   be used as an insecure form of access protection. The interpretation
+   of this field is that the request is being performed on behalf of the
+   person given, who accepts responsibility for the method performed. In
+   particular, robot agents SHOULD include this header so that the
+   person responsible for running the robot can be contacted if problems
+   occur on the receiving end.
+
+   The Internet e-mail address in this field MAY be separate from the
+   Internet host which issued the request. For example, when a request
+   is passed through a proxy the original issuer's address SHOULD be
+   used.
+
+   The client SHOULD NOT send the From header field without the user's
+   approval, as it might conflict with the user's privacy interests or
+   their site's security policy. It is strongly recommended that the
+   user be able to disable, enable, and modify the value of this field
+   at any time prior to a request.
+
+14.23 Host
+
+   The Host request-header field specifies the Internet host and port
+   number of the resource being requested, as obtained from the original
+   URI given by the user or referring resource (generally an HTTP URL,
+
+
+
+Fielding, et al.            Standards Track                   [Page 128]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   as described in section 3.2.2). The Host field value MUST represent
+   the naming authority of the origin server or gateway given by the
+   original URL. This allows the origin server or gateway to
+   differentiate between internally-ambiguous URLs, such as the root "/"
+   URL of a server for multiple host names on a single IP address.
+
+       Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
+
+   A "host" without any trailing port information implies the default
+   port for the service requested (e.g., "80" for an HTTP URL). For
+   example, a request on the origin server for
+   <http://www.w3.org/pub/WWW/> would properly include:
+
+       GET /pub/WWW/ HTTP/1.1
+       Host: www.w3.org
+
+   A client MUST include a Host header field in all HTTP/1.1 request
+   messages . If the requested URI does not include an Internet host
+   name for the service being requested, then the Host header field MUST
+   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
+   request message it forwards does contain an appropriate Host header
+   field that identifies the service being requested by the proxy. All
+   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
+   status code to any HTTP/1.1 request message which lacks a Host header
+   field.
+
+   See sections 5.2 and 19.6.1.1 for other requirements relating to
+   Host.
+
+14.24 If-Match
+
+   The If-Match request-header field is used with a method to make it
+   conditional. A client that has one or more entities previously
+   obtained from the resource can verify that one of those entities is
+   current by including a list of their associated entity tags in the
+   If-Match header field. Entity tags are defined in section 3.11. The
+   purpose of this feature is to allow efficient updates of cached
+   information with a minimum amount of transaction overhead. It is also
+   used, on updating requests, to prevent inadvertent modification of
+   the wrong version of a resource. As a special case, the value "*"
+   matches any current entity of the resource.
+
+       If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-Match header) on that resource, or if "*" is given
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 129]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   and any current entity exists for that resource, then the server MAY
+   perform the requested method as if the If-Match header field did not
+   exist.
+
+   A server MUST use the strong comparison function (see section 13.3.3)
+   to compare the entity tags in If-Match.
+
+   If none of the entity tags match, or if "*" is given and no current
+   entity exists, the server MUST NOT perform the requested method, and
+   MUST return a 412 (Precondition Failed) response. This behavior is
+   most useful when the client wants to prevent an updating method, such
+   as PUT, from modifying a resource that has changed since the client
+   last retrieved it.
+
+   If the request would, without the If-Match header field, result in
+   anything other than a 2xx or 412 status, then the If-Match header
+   MUST be ignored.
+
+   The meaning of "If-Match: *" is that the method SHOULD be performed
+   if the representation selected by the origin server (or by a cache,
+   possibly using the Vary mechanism, see section 14.44) exists, and
+   MUST NOT be performed if the representation does not exist.
+
+   A request intended to update a resource (e.g., a PUT) MAY include an
+   If-Match header field to signal that the request method MUST NOT be
+   applied if the entity corresponding to the If-Match value (a single
+   entity tag) is no longer a representation of that resource. This
+   allows the user to indicate that they do not wish the request to be
+   successful if the resource has been changed without their knowledge.
+   Examples:
+
+       If-Match: "xyzzy"
+       If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+       If-Match: *
+
+   The result of a request having both an If-Match header field and
+   either an If-None-Match or an If-Modified-Since header fields is
+   undefined by this specification.
+
+14.25 If-Modified-Since
+
+   The If-Modified-Since request-header field is used with a method to
+   make it conditional: if the requested variant has not been modified
+   since the time specified in this field, an entity will not be
+   returned from the server; instead, a 304 (not modified) response will
+   be returned without any message-body.
+
+       If-Modified-Since = "If-Modified-Since" ":" HTTP-date
+
+
+
+Fielding, et al.            Standards Track                   [Page 130]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   An example of the field is:
+
+       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+   A GET method with an If-Modified-Since header and no Range header
+   requests that the identified entity be transferred only if it has
+   been modified since the date given by the If-Modified-Since header.
+   The algorithm for determining this includes the following cases:
+
+      a) If the request would normally result in anything other than a
+         200 (OK) status, or if the passed If-Modified-Since date is
+         invalid, the response is exactly the same as for a normal GET.
+         A date which is later than the server's current time is
+         invalid.
+
+      b) If the variant has been modified since the If-Modified-Since
+         date, the response is exactly the same as for a normal GET.
+
+      c) If the variant has not been modified since a valid If-
+         Modified-Since date, the server SHOULD return a 304 (Not
+         Modified) response.
+
+   The purpose of this feature is to allow efficient updates of cached
+   information with a minimum amount of transaction overhead.
+
+      Note: The Range request-header field modifies the meaning of If-
+      Modified-Since; see section 14.35 for full details.
+
+      Note: If-Modified-Since times are interpreted by the server, whose
+      clock might not be synchronized with the client.
+
+      Note: When handling an If-Modified-Since header field, some
+      servers will use an exact date comparison function, rather than a
+      less-than function, for deciding whether to send a 304 (Not
+      Modified) response. To get best results when sending an If-
+      Modified-Since header field for cache validation, clients are
+      advised to use the exact date string received in a previous Last-
+      Modified header field whenever possible.
+
+      Note: If a client uses an arbitrary date in the If-Modified-Since
+      header instead of a date taken from the Last-Modified header for
+      the same request, the client should be aware of the fact that this
+      date is interpreted in the server's understanding of time. The
+      client should consider unsynchronized clocks and rounding problems
+      due to the different encodings of time between the client and
+      server. This includes the possibility of race conditions if the
+      document has changed between the time it was first requested and
+      the If-Modified-Since date of a subsequent request, and the
+
+
+
+Fielding, et al.            Standards Track                   [Page 131]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      possibility of clock-skew-related problems if the If-Modified-
+      Since date is derived from the client's clock without correction
+      to the server's clock. Corrections for different time bases
+      between client and server are at best approximate due to network
+      latency.
+
+   The result of a request having both an If-Modified-Since header field
+   and either an If-Match or an If-Unmodified-Since header fields is
+   undefined by this specification.
+
+14.26 If-None-Match
+
+   The If-None-Match request-header field is used with a method to make
+   it conditional. A client that has one or more entities previously
+   obtained from the resource can verify that none of those entities is
+   current by including a list of their associated entity tags in the
+   If-None-Match header field. The purpose of this feature is to allow
+   efficient updates of cached information with a minimum amount of
+   transaction overhead. It is also used to prevent a method (e.g. PUT)
+   from inadvertently modifying an existing resource when the client
+   believes that the resource does not exist.
+
+   As a special case, the value "*" matches any current entity of the
+   resource.
+
+       If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-None-Match header) on that resource, or if "*" is
+   given and any current entity exists for that resource, then the
+   server MUST NOT perform the requested method, unless required to do
+   so because the resource's modification date fails to match that
+   supplied in an If-Modified-Since header field in the request.
+   Instead, if the request method was GET or HEAD, the server SHOULD
+   respond with a 304 (Not Modified) response, including the cache-
+   related header fields (particularly ETag) of one of the entities that
+   matched. For all other request methods, the server MUST respond with
+   a status of 412 (Precondition Failed).
+
+   See section 13.3.3 for rules on how to determine if two entities tags
+   match. The weak comparison function can only be used with GET or HEAD
+   requests.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 132]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If none of the entity tags match, then the server MAY perform the
+   requested method as if the If-None-Match header field did not exist,
+   but MUST also ignore any If-Modified-Since header field(s) in the
+   request. That is, if no entity tags match, then the server MUST NOT
+   return a 304 (Not Modified) response.
+
+   If the request would, without the If-None-Match header field, result
+   in anything other than a 2xx or 304 status, then the If-None-Match
+   header MUST be ignored. (See section 13.3.4 for a discussion of
+   server behavior when both If-Modified-Since and If-None-Match appear
+   in the same request.)
+
+   The meaning of "If-None-Match: *" is that the method MUST NOT be
+   performed if the representation selected by the origin server (or by
+   a cache, possibly using the Vary mechanism, see section 14.44)
+   exists, and SHOULD be performed if the representation does not exist.
+   This feature is intended to be useful in preventing races between PUT
+   operations.
+
+   Examples:
+
+       If-None-Match: "xyzzy"
+       If-None-Match: W/"xyzzy"
+       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
+       If-None-Match: *
+
+   The result of a request having both an If-None-Match header field and
+   either an If-Match or an If-Unmodified-Since header fields is
+   undefined by this specification.
+
+14.27 If-Range
+
+   If a client has a partial copy of an entity in its cache, and wishes
+   to have an up-to-date copy of the entire entity in its cache, it
+   could use the Range request-header with a conditional GET (using
+   either or both of If-Unmodified-Since and If-Match.) However, if the
+   condition fails because the entity has been modified, the client
+   would then have to make a second request to obtain the entire current
+   entity-body.
+
+   The If-Range header allows a client to "short-circuit" the second
+   request. Informally, its meaning is `if the entity is unchanged, send
+   me the part(s) that I am missing; otherwise, send me the entire new
+   entity'.
+
+        If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 133]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the client has no entity tag for an entity, but does have a Last-
+   Modified date, it MAY use that date in an If-Range header. (The
+   server can distinguish between a valid HTTP-date and any form of
+   entity-tag by examining no more than two characters.) The If-Range
+   header SHOULD only be used together with a Range header, and MUST be
+   ignored if the request does not include a Range header, or if the
+   server does not support the sub-range operation.
+
+   If the entity tag given in the If-Range header matches the current
+   entity tag for the entity, then the server SHOULD provide the
+   specified sub-range of the entity using a 206 (Partial content)
+   response. If the entity tag does not match, then the server SHOULD
+   return the entire entity using a 200 (OK) response.
+
+14.28 If-Unmodified-Since
+
+   The If-Unmodified-Since request-header field is used with a method to
+   make it conditional. If the requested resource has not been modified
+   since the time specified in this field, the server SHOULD perform the
+   requested operation as if the If-Unmodified-Since header were not
+   present.
+
+   If the requested variant has been modified since the specified time,
+   the server MUST NOT perform the requested operation, and MUST return
+   a 412 (Precondition Failed).
+
+      If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
+
+   An example of the field is:
+
+       If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+   If the request normally (i.e., without the If-Unmodified-Since
+   header) would result in anything other than a 2xx or 412 status, the
+   If-Unmodified-Since header SHOULD be ignored.
+
+   If the specified date is invalid, the header is ignored.
+
+   The result of a request having both an If-Unmodified-Since header
+   field and either an If-None-Match or an If-Modified-Since header
+   fields is undefined by this specification.
+
+14.29 Last-Modified
+
+   The Last-Modified entity-header field indicates the date and time at
+   which the origin server believes the variant was last modified.
+
+       Last-Modified  = "Last-Modified" ":" HTTP-date
+
+
+
+Fielding, et al.            Standards Track                   [Page 134]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   An example of its use is
+
+       Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
+
+   The exact meaning of this header field depends on the implementation
+   of the origin server and the nature of the original resource. For
+   files, it may be just the file system last-modified time. For
+   entities with dynamically included parts, it may be the most recent
+   of the set of last-modify times for its component parts. For database
+   gateways, it may be the last-update time stamp of the record. For
+   virtual objects, it may be the last time the internal state changed.
+
+   An origin server MUST NOT send a Last-Modified date which is later
+   than the server's time of message origination. In such cases, where
+   the resource's last modification would indicate some time in the
+   future, the server MUST replace that date with the message
+   origination date.
+
+   An origin server SHOULD obtain the Last-Modified value of the entity
+   as close as possible to the time that it generates the Date value of
+   its response. This allows a recipient to make an accurate assessment
+   of the entity's modification time, especially if the entity changes
+   near the time that the response is generated.
+
+   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
+
+14.30 Location
+
+   The Location response-header field is used to redirect the recipient
+   to a location other than the Request-URI for completion of the
+   request or identification of a new resource. For 201 (Created)
+   responses, the Location is that of the new resource which was created
+   by the request. For 3xx responses, the location SHOULD indicate the
+   server's preferred URI for automatic redirection to the resource. The
+   field value consists of a single absolute URI.
+
+       Location       = "Location" ":" absoluteURI
+
+   An example is:
+
+       Location: http://www.w3.org/pub/WWW/People.html
+
+      Note: The Content-Location header field (section 14.14) differs
+      from Location in that the Content-Location identifies the original
+      location of the entity enclosed in the request. It is therefore
+      possible for a response to contain header fields for both Location
+      and Content-Location. Also see section 13.10 for cache
+      requirements of some methods.
+
+
+
+Fielding, et al.            Standards Track                   [Page 135]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.31 Max-Forwards
+
+   The Max-Forwards request-header field provides a mechanism with the
+   TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
+   number of proxies or gateways that can forward the request to the
+   next inbound server. This can be useful when the client is attempting
+   to trace a request chain which appears to be failing or looping in
+   mid-chain.
+
+       Max-Forwards   = "Max-Forwards" ":" 1*DIGIT
+
+   The Max-Forwards value is a decimal integer indicating the remaining
+   number of times this request message may be forwarded.
+
+   Each proxy or gateway recipient of a TRACE or OPTIONS request
+   containing a Max-Forwards header field MUST check and update its
+   value prior to forwarding the request. If the received value is zero
+   (0), the recipient MUST NOT forward the request; instead, it MUST
+   respond as the final recipient. If the received Max-Forwards value is
+   greater than zero, then the forwarded message MUST contain an updated
+   Max-Forwards field with a value decremented by one (1).
+
+   The Max-Forwards header field MAY be ignored for all other methods
+   defined by this specification and for any extension methods for which
+   it is not explicitly referred to as part of that method definition.
+
+14.32 Pragma
+
+   The Pragma general-header field is used to include implementation-
+   specific directives that might apply to any recipient along the
+   request/response chain. All pragma directives specify optional
+   behavior from the viewpoint of the protocol; however, some systems
+   MAY require that behavior be consistent with the directives.
+
+       Pragma            = "Pragma" ":" 1#pragma-directive
+       pragma-directive  = "no-cache" | extension-pragma
+       extension-pragma  = token [ "=" ( token | quoted-string ) ]
+
+   When the no-cache directive is present in a request message, an
+   application SHOULD forward the request toward the origin server even
+   if it has a cached copy of what is being requested. This pragma
+   directive has the same semantics as the no-cache cache-directive (see
+   section 14.9) and is defined here for backward compatibility with
+   HTTP/1.0. Clients SHOULD include both header fields when a no-cache
+   request is sent to a server not known to be HTTP/1.1 compliant.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 136]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Pragma directives MUST be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives might be applicable to all recipients along the
+   request/response chain. It is not possible to specify a pragma for a
+   specific recipient; however, any pragma directive not relevant to a
+   recipient SHOULD be ignored by that recipient.
+
+   HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
+   sent "Cache-Control: no-cache". No new Pragma directives will be
+   defined in HTTP.
+
+      Note: because the meaning of "Pragma: no-cache as a response
+      header field is not actually specified, it does not provide a
+      reliable replacement for "Cache-Control: no-cache" in a response
+
+14.33 Proxy-Authenticate
+
+   The Proxy-Authenticate response-header field MUST be included as part
+   of a 407 (Proxy Authentication Required) response. The field value
+   consists of a challenge that indicates the authentication scheme and
+   parameters applicable to the proxy for this Request-URI.
+
+       Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. Unlike
+   WWW-Authenticate, the Proxy-Authenticate header field applies only to
+   the current connection and SHOULD NOT be passed on to downstream
+   clients. However, an intermediate proxy might need to obtain its own
+   credentials by requesting them from the downstream client, which in
+   some circumstances will appear as if the proxy is forwarding the
+   Proxy-Authenticate header field.
+
+14.34 Proxy-Authorization
+
+   The Proxy-Authorization request-header field allows the client to
+   identify itself (or its user) to a proxy which requires
+   authentication. The Proxy-Authorization field value consists of
+   credentials containing the authentication information of the user
+   agent for the proxy and/or realm of the resource being requested.
+
+       Proxy-Authorization     = "Proxy-Authorization" ":" credentials
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43] . Unlike
+   Authorization, the Proxy-Authorization header field applies only to
+   the next outbound proxy that demanded authentication using the Proxy-
+   Authenticate field. When multiple proxies are used in a chain, the
+
+
+
+Fielding, et al.            Standards Track                   [Page 137]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Proxy-Authorization header field is consumed by the first outbound
+   proxy that was expecting to receive credentials. A proxy MAY relay
+   the credentials from the client request to the next proxy if that is
+   the mechanism by which the proxies cooperatively authenticate a given
+   request.
+
+14.35 Range
+
+14.35.1 Byte Ranges
+
+   Since all HTTP entities are represented in HTTP messages as sequences
+   of bytes, the concept of a byte range is meaningful for any HTTP
+   entity. (However, not all clients and servers need to support byte-
+   range operations.)
+
+   Byte range specifications in HTTP apply to the sequence of bytes in
+   the entity-body (not necessarily the same as the message-body).
+
+   A byte range operation MAY specify a single range of bytes, or a set
+   of ranges within a single entity.
+
+       ranges-specifier = byte-ranges-specifier
+       byte-ranges-specifier = bytes-unit "=" byte-range-set
+       byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
+       byte-range-spec = first-byte-pos "-" [last-byte-pos]
+       first-byte-pos  = 1*DIGIT
+       last-byte-pos   = 1*DIGIT
+
+   The first-byte-pos value in a byte-range-spec gives the byte-offset
+   of the first byte in a range. The last-byte-pos value gives the
+   byte-offset of the last byte in the range; that is, the byte
+   positions specified are inclusive. Byte offsets start at zero.
+
+   If the last-byte-pos value is present, it MUST be greater than or
+   equal to the first-byte-pos in that byte-range-spec, or the byte-
+   range-spec is syntactically invalid. The recipient of a byte-range-
+   set that includes one or more syntactically invalid byte-range-spec
+   values MUST ignore the header field that includes that byte-range-
+   set.
+
+   If the last-byte-pos value is absent, or if the value is greater than
+   or equal to the current length of the entity-body, last-byte-pos is
+   taken to be equal to one less than the current length of the entity-
+   body in bytes.
+
+   By its choice of last-byte-pos, a client can limit the number of
+   bytes retrieved without knowing the size of the entity.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 138]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       suffix-byte-range-spec = "-" suffix-length
+       suffix-length = 1*DIGIT
+
+   A suffix-byte-range-spec is used to specify the suffix of the
+   entity-body, of a length given by the suffix-length value. (That is,
+   this form specifies the last N bytes of an entity-body.) If the
+   entity is shorter than the specified suffix-length, the entire
+   entity-body is used.
+
+   If a syntactically valid byte-range-set includes at least one byte-
+   range-spec whose first-byte-pos is less than the current length of
+   the entity-body, or at least one suffix-byte-range-spec with a non-
+   zero suffix-length, then the byte-range-set is satisfiable.
+   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
+   is unsatisfiable, the server SHOULD return a response with a status
+   of 416 (Requested range not satisfiable). Otherwise, the server
+   SHOULD return a response with a status of 206 (Partial Content)
+   containing the satisfiable ranges of the entity-body.
+
+   Examples of byte-ranges-specifier values (assuming an entity-body of
+   length 10000):
+
+      - The first 500 bytes (byte offsets 0-499, inclusive):  bytes=0-
+        499
+
+      - The second 500 bytes (byte offsets 500-999, inclusive):
+        bytes=500-999
+
+      - The final 500 bytes (byte offsets 9500-9999, inclusive):
+        bytes=-500
+
+      - Or bytes=9500-
+
+      - The first and last bytes only (bytes 0 and 9999):  bytes=0-0,-1
+
+      - Several legal but not canonical specifications of the second 500
+        bytes (byte offsets 500-999, inclusive):
+         bytes=500-600,601-999
+         bytes=500-700,601-999
+
+14.35.2 Range Retrieval Requests
+
+   HTTP retrieval requests using conditional or unconditional GET
+   methods MAY request one or more sub-ranges of the entity, instead of
+   the entire entity, using the Range request header, which applies to
+   the entity returned as the result of the request:
+
+      Range = "Range" ":" ranges-specifier
+
+
+
+Fielding, et al.            Standards Track                   [Page 139]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A server MAY ignore the Range header. However, HTTP/1.1 origin
+   servers and intermediate caches ought to support byte ranges when
+   possible, since Range supports efficient recovery from partially
+   failed transfers, and supports efficient partial retrieval of large
+   entities.
+
+   If the server supports the Range header and the specified range or
+   ranges are appropriate for the entity:
+
+      - The presence of a Range header in an unconditional GET modifies
+        what is returned if the GET is otherwise successful. In other
+        words, the response carries a status code of 206 (Partial
+        Content) instead of 200 (OK).
+
+      - The presence of a Range header in a conditional GET (a request
+        using one or both of If-Modified-Since and If-None-Match, or
+        one or both of If-Unmodified-Since and If-Match) modifies what
+        is returned if the GET is otherwise successful and the
+        condition is true. It does not affect the 304 (Not Modified)
+        response returned if the conditional is false.
+
+   In some cases, it might be more appropriate to use the If-Range
+   header (see section 14.27) in addition to the Range header.
+
+   If a proxy that supports ranges receives a Range request, forwards
+   the request to an inbound server, and receives an entire entity in
+   reply, it SHOULD only return the requested range to its client. It
+   SHOULD store the entire received response in its cache if that is
+   consistent with its cache allocation policies.
+
+14.36 Referer
+
+   The Referer[sic] request-header field allows the client to specify,
+   for the server's benefit, the address (URI) of the resource from
+   which the Request-URI was obtained (the "referrer", although the
+   header field is misspelled.) The Referer request-header allows a
+   server to generate lists of back-links to resources for interest,
+   logging, optimized caching, etc. It also allows obsolete or mistyped
+   links to be traced for maintenance. The Referer field MUST NOT be
+   sent if the Request-URI was obtained from a source that does not have
+   its own URI, such as input from the user keyboard.
+
+       Referer        = "Referer" ":" ( absoluteURI | relativeURI )
+
+   Example:
+
+       Referer: http://www.w3.org/hypertext/DataSources/Overview.html
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 140]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the field value is a relative URI, it SHOULD be interpreted
+   relative to the Request-URI. The URI MUST NOT include a fragment. See
+   section 15.1.3 for security considerations.
+
+14.37 Retry-After
+
+   The Retry-After response-header field can be used with a 503 (Service
+   Unavailable) response to indicate how long the service is expected to
+   be unavailable to the requesting client. This field MAY also be used
+   with any 3xx (Redirection) response to indicate the minimum time the
+   user-agent is asked wait before issuing the redirected request. The
+   value of this field can be either an HTTP-date or an integer number
+   of seconds (in decimal) after the time of the response.
+
+       Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )
+
+   Two examples of its use are
+
+       Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
+       Retry-After: 120
+
+   In the latter example, the delay is 2 minutes.
+
+14.38 Server
+
+   The Server response-header field contains information about the
+   software used by the origin server to handle the request. The field
+   can contain multiple product tokens (section 3.8) and comments
+   identifying the server and any significant subproducts. The product
+   tokens are listed in order of their significance for identifying the
+   application.
+
+       Server         = "Server" ":" 1*( product | comment )
+
+   Example:
+
+       Server: CERN/3.0 libwww/2.17
+
+   If the response is being forwarded through a proxy, the proxy
+   application MUST NOT modify the Server response-header. Instead, it
+   SHOULD include a Via field (as described in section 14.45).
+
+      Note: Revealing the specific software version of the server might
+      allow the server machine to become more vulnerable to attacks
+      against software that is known to contain security holes. Server
+      implementors are encouraged to make this field a configurable
+      option.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 141]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.39 TE
+
+   The TE request-header field indicates what extension transfer-codings
+   it is willing to accept in the response and whether or not it is
+   willing to accept trailer fields in a chunked transfer-coding. Its
+   value may consist of the keyword "trailers" and/or a comma-separated
+   list of extension transfer-coding names with optional accept
+   parameters (as described in section 3.6).
+
+       TE        = "TE" ":" #( t-codings )
+       t-codings = "trailers" | ( transfer-extension [ accept-params ] )
+
+   The presence of the keyword "trailers" indicates that the client is
+   willing to accept trailer fields in a chunked transfer-coding, as
+   defined in section 3.6.1. This keyword is reserved for use with
+   transfer-coding values even though it does not itself represent a
+   transfer-coding.
+
+   Examples of its use are:
+
+       TE: deflate
+       TE:
+       TE: trailers, deflate;q=0.5
+
+   The TE header field only applies to the immediate connection.
+   Therefore, the keyword MUST be supplied within a Connection header
+   field (section 14.10) whenever TE is present in an HTTP/1.1 message.
+
+   A server tests whether a transfer-coding is acceptable, according to
+   a TE field, using these rules:
+
+      1. The "chunked" transfer-coding is always acceptable. If the
+         keyword "trailers" is listed, the client indicates that it is
+         willing to accept trailer fields in the chunked response on
+         behalf of itself and any downstream clients. The implication is
+         that, if given, the client is stating that either all
+         downstream clients are willing to accept trailer fields in the
+         forwarded response, or that it will attempt to buffer the
+         response on behalf of downstream recipients.
+
+         Note: HTTP/1.1 does not define any means to limit the size of a
+         chunked response such that a client can be assured of buffering
+         the entire response.
+
+      2. If the transfer-coding being tested is one of the transfer-
+         codings listed in the TE field, then it is acceptable unless it
+         is accompanied by a qvalue of 0. (As defined in section 3.9, a
+         qvalue of 0 means "not acceptable.")
+
+
+
+Fielding, et al.            Standards Track                   [Page 142]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      3. If multiple transfer-codings are acceptable, then the
+         acceptable transfer-coding with the highest non-zero qvalue is
+         preferred.  The "chunked" transfer-coding always has a qvalue
+         of 1.
+
+   If the TE field-value is empty or if no TE field is present, the only
+   transfer-coding  is "chunked". A message with no transfer-coding is
+   always acceptable.
+
+14.40 Trailer
+
+   The Trailer general field value indicates that the given set of
+   header fields is present in the trailer of a message encoded with
+   chunked transfer-coding.
+
+       Trailer  = "Trailer" ":" 1#field-name
+
+   An HTTP/1.1 message SHOULD include a Trailer header field in a
+   message using chunked transfer-coding with a non-empty trailer. Doing
+   so allows the recipient to know which header fields to expect in the
+   trailer.
+
+   If no Trailer header field is present, the trailer SHOULD NOT include
+   any header fields. See section 3.6.1 for restrictions on the use of
+   trailer fields in a "chunked" transfer-coding.
+
+   Message header fields listed in the Trailer header field MUST NOT
+   include the following header fields:
+
+      . Transfer-Encoding
+
+      . Content-Length
+
+      . Trailer
+
+14.41 Transfer-Encoding
+
+   The Transfer-Encoding general-header field indicates what (if any)
+   type of transformation has been applied to the message body in order
+   to safely transfer it between the sender and the recipient. This
+   differs from the content-coding in that the transfer-coding is a
+   property of the message, not of the entity.
+
+     Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding
+
+   Transfer-codings are defined in section 3.6. An example is:
+
+     Transfer-Encoding: chunked
+
+
+
+Fielding, et al.            Standards Track                   [Page 143]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If multiple encodings have been applied to an entity, the transfer-
+   codings MUST be listed in the order in which they were applied.
+   Additional information about the encoding parameters MAY be provided
+   by other entity-header fields not defined by this specification.
+
+   Many older HTTP/1.0 applications do not understand the Transfer-
+   Encoding header.
+
+14.42 Upgrade
+
+   The Upgrade general-header allows the client to specify what
+   additional communication protocols it supports and would like to use
+   if the server finds it appropriate to switch protocols. The server
+   MUST use the Upgrade header field within a 101 (Switching Protocols)
+   response to indicate which protocol(s) are being switched.
+
+       Upgrade        = "Upgrade" ":" 1#product
+
+   For example,
+
+       Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+
+   The Upgrade header field is intended to provide a simple mechanism
+   for transition from HTTP/1.1 to some other, incompatible protocol. It
+   does so by allowing the client to advertise its desire to use another
+   protocol, such as a later version of HTTP with a higher major version
+   number, even though the current request has been made using HTTP/1.1.
+   This eases the difficult transition between incompatible protocols by
+   allowing the client to initiate a request in the more commonly
+   supported protocol while indicating to the server that it would like
+   to use a "better" protocol if available (where "better" is determined
+   by the server, possibly according to the nature of the method and/or
+   resource being requested).
+
+   The Upgrade header field only applies to switching application-layer
+   protocols upon the existing transport-layer connection. Upgrade
+   cannot be used to insist on a protocol change; its acceptance and use
+   by the server is optional. The capabilities and nature of the
+   application-layer communication after the protocol change is entirely
+   dependent upon the new protocol chosen, although the first action
+   after changing the protocol MUST be a response to the initial HTTP
+   request containing the Upgrade header field.
+
+   The Upgrade header field only applies to the immediate connection.
+   Therefore, the upgrade keyword MUST be supplied within a Connection
+   header field (section 14.10) whenever Upgrade is present in an
+   HTTP/1.1 message.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 144]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Upgrade header field cannot be used to indicate a switch to a
+   protocol on a different connection. For that purpose, it is more
+   appropriate to use a 301, 302, 303, or 305 redirection response.
+
+   This specification only defines the protocol name "HTTP" for use by
+   the family of Hypertext Transfer Protocols, as defined by the HTTP
+   version rules of section 3.1 and future updates to this
+   specification. Any token can be used as a protocol name; however, it
+   will only be useful if both the client and server associate the name
+   with the same protocol.
+
+14.43 User-Agent
+
+   The User-Agent request-header field contains information about the
+   user agent originating the request. This is for statistical purposes,
+   the tracing of protocol violations, and automated recognition of user
+   agents for the sake of tailoring responses to avoid particular user
+   agent limitations. User agents SHOULD include this field with
+   requests. The field can contain multiple product tokens (section 3.8)
+   and comments identifying the agent and any subproducts which form a
+   significant part of the user agent. By convention, the product tokens
+   are listed in order of their significance for identifying the
+   application.
+
+       User-Agent     = "User-Agent" ":" 1*( product | comment )
+
+   Example:
+
+       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+
+14.44 Vary
+
+   The Vary field value indicates the set of request-header fields that
+   fully determines, while the response is fresh, whether a cache is
+   permitted to use the response to reply to a subsequent request
+   without revalidation. For uncacheable or stale responses, the Vary
+   field value advises the user agent about the criteria that were used
+   to select the representation. A Vary field value of "*" implies that
+   a cache cannot determine from the request headers of a subsequent
+   request whether this response is the appropriate representation. See
+   section 13.6 for use of the Vary header field by caches.
+
+       Vary  = "Vary" ":" ( "*" | 1#field-name )
+
+   An HTTP/1.1 server SHOULD include a Vary header field with any
+   cacheable response that is subject to server-driven negotiation.
+   Doing so allows a cache to properly interpret future requests on that
+   resource and informs the user agent about the presence of negotiation
+
+
+
+Fielding, et al.            Standards Track                   [Page 145]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   on that resource. A server MAY include a Vary header field with a
+   non-cacheable response that is subject to server-driven negotiation,
+   since this might provide the user agent with useful information about
+   the dimensions over which the response varies at the time of the
+   response.
+
+   A Vary field value consisting of a list of field-names signals that
+   the representation selected for the response is based on a selection
+   algorithm which considers ONLY the listed request-header field values
+   in selecting the most appropriate representation. A cache MAY assume
+   that the same selection will be made for future requests with the
+   same values for the listed field names, for the duration of time for
+   which the response is fresh.
+
+   The field-names given are not limited to the set of standard
+   request-header fields defined by this specification. Field names are
+   case-insensitive.
+
+   A Vary field value of "*" signals that unspecified parameters not
+   limited to the request-headers (e.g., the network address of the
+   client), play a role in the selection of the response representation.
+   The "*" value MUST NOT be generated by a proxy server; it may only be
+   generated by an origin server.
+
+14.45  Via
+
+   The Via general-header field MUST be used by gateways and proxies to
+   indicate the intermediate protocols and recipients between the user
+   agent and the server on requests, and between the origin server and
+   the client on responses. It is analogous to the "Received" field of
+   RFC 822 [9] and is intended to be used for tracking message forwards,
+   avoiding request loops, and identifying the protocol capabilities of
+   all senders along the request/response chain.
+
+      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
+      received-protocol = [ protocol-name "/" ] protocol-version
+      protocol-name     = token
+      protocol-version  = token
+      received-by       = ( host [ ":" port ] ) | pseudonym
+      pseudonym         = token
+
+   The received-protocol indicates the protocol version of the message
+   received by the server or client along each segment of the
+   request/response chain. The received-protocol version is appended to
+   the Via field value when the message is forwarded so that information
+   about the protocol capabilities of upstream applications remains
+   visible to all recipients.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 146]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The protocol-name is optional if and only if it would be "HTTP". The
+   received-by field is normally the host and optional port number of a
+   recipient server or client that subsequently forwarded the message.
+   However, if the real host is considered to be sensitive information,
+   it MAY be replaced by a pseudonym. If the port is not given, it MAY
+   be assumed to be the default port of the received-protocol.
+
+   Multiple Via field values represents each proxy or gateway that has
+   forwarded the message. Each recipient MUST append its information
+   such that the end result is ordered according to the sequence of
+   forwarding applications.
+
+   Comments MAY be used in the Via header field to identify the software
+   of the recipient proxy or gateway, analogous to the User-Agent and
+   Server header fields. However, all comments in the Via field are
+   optional and MAY be removed by any recipient prior to forwarding the
+   message.
+
+   For example, a request message could be sent from an HTTP/1.0 user
+   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
+   forward the request to a public proxy at nowhere.com, which completes
+   the request by forwarding it to the origin server at www.ics.uci.edu.
+   The request received by www.ics.uci.edu would then have the following
+   Via header field:
+
+       Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
+
+   Proxies and gateways used as a portal through a network firewall
+   SHOULD NOT, by default, forward the names and ports of hosts within
+   the firewall region. This information SHOULD only be propagated if
+   explicitly enabled. If not enabled, the received-by host of any host
+   behind the firewall SHOULD be replaced by an appropriate pseudonym
+   for that host.
+
+   For organizations that have strong privacy requirements for hiding
+   internal structures, a proxy MAY combine an ordered subsequence of
+   Via header field entries with identical received-protocol values into
+   a single such entry. For example,
+
+       Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+
+        could be collapsed to
+
+       Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 147]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Applications SHOULD NOT combine multiple entries unless they are all
+   under the same organizational control and the hosts have already been
+   replaced by pseudonyms. Applications MUST NOT combine entries which
+   have different received-protocol values.
+
+14.46 Warning
+
+   The Warning general-header field is used to carry additional
+   information about the status or transformation of a message which
+   might not be reflected in the message. This information is typically
+   used to warn about a possible lack of semantic transparency from
+   caching operations or transformations applied to the entity body of
+   the message.
+
+   Warning headers are sent with responses using:
+
+       Warning    = "Warning" ":" 1#warning-value
+
+       warning-value = warn-code SP warn-agent SP warn-text
+                                             [SP warn-date]
+
+       warn-code  = 3DIGIT
+       warn-agent = ( host [ ":" port ] ) | pseudonym
+                       ; the name or pseudonym of the server adding
+                       ; the Warning header, for use in debugging
+       warn-text  = quoted-string
+       warn-date  = <"> HTTP-date <">
+
+   A response MAY carry more than one Warning header.
+
+   The warn-text SHOULD be in a natural language and character set that
+   is most likely to be intelligible to the human user receiving the
+   response. This decision MAY be based on any available knowledge, such
+   as the location of the cache or user, the Accept-Language field in a
+   request, the Content-Language field in a response, etc. The default
+   language is English and the default character set is ISO-8859-1.
+
+   If a character set other than ISO-8859-1 is used, it MUST be encoded
+   in the warn-text using the method described in RFC 2047 [14].
+
+   Warning headers can in general be applied to any message, however
+   some specific warn-codes are specific to caches and can only be
+   applied to response messages. New Warning headers SHOULD be added
+   after any existing Warning headers. A cache MUST NOT delete any
+   Warning header that it received with a message. However, if a cache
+   successfully validates a cache entry, it SHOULD remove any Warning
+   headers previously attached to that entry except as specified for
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 148]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   specific Warning codes. It MUST then add any Warning headers received
+   in the validating response. In other words, Warning headers are those
+   that would be attached to the most recent relevant response.
+
+   When multiple Warning headers are attached to a response, the user
+   agent ought to inform the user of as many of them as possible, in the
+   order that they appear in the response. If it is not possible to
+   inform the user of all of the warnings, the user agent SHOULD follow
+   these heuristics:
+
+      - Warnings that appear early in the response take priority over
+        those appearing later in the response.
+
+      - Warnings in the user's preferred character set take priority
+        over warnings in other character sets but with identical warn-
+        codes and warn-agents.
+
+   Systems that generate multiple Warning headers SHOULD order them with
+   this user agent behavior in mind.
+
+   Requirements for the behavior of caches with respect to Warnings are
+   stated in section 13.1.2.
+
+   This is a list of the currently-defined warn-codes, each with a
+   recommended warn-text in English, and a description of its meaning.
+
+   110 Response is stale
+     MUST be included whenever the returned response is stale.
+
+   111 Revalidation failed
+     MUST be included if a cache returns a stale response because an
+     attempt to revalidate the response failed, due to an inability to
+     reach the server.
+
+   112 Disconnected operation
+     SHOULD be included if the cache is intentionally disconnected from
+     the rest of the network for a period of time.
+
+   113 Heuristic expiration
+     MUST be included if the cache heuristically chose a freshness
+     lifetime greater than 24 hours and the response's age is greater
+     than 24 hours.
+
+   199 Miscellaneous warning
+     The warning text MAY include arbitrary information to be presented
+     to a human user, or logged. A system receiving this warning MUST
+     NOT take any automated action, besides presenting the warning to
+     the user.
+
+
+
+Fielding, et al.            Standards Track                   [Page 149]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   214 Transformation applied
+     MUST be added by an intermediate cache or proxy if it applies any
+     transformation changing the content-coding (as specified in the
+     Content-Encoding header) or media-type (as specified in the
+     Content-Type header) of the response, or the entity-body of the
+     response, unless this Warning code already appears in the response.
+
+   299 Miscellaneous persistent warning
+     The warning text MAY include arbitrary information to be presented
+     to a human user, or logged. A system receiving this warning MUST
+     NOT take any automated action.
+
+   If an implementation sends a message with one or more Warning headers
+   whose version is HTTP/1.0 or lower, then the sender MUST include in
+   each warning-value a warn-date that matches the date in the response.
+
+   If an implementation receives a message with a warning-value that
+   includes a warn-date, and that warn-date is different from the Date
+   value in the response, then that warning-value MUST be deleted from
+   the message before storing, forwarding, or using it. (This prevents
+   bad consequences of naive caching of Warning header fields.) If all
+   of the warning-values are deleted for this reason, the Warning header
+   MUST be deleted as well.
+
+14.47 WWW-Authenticate
+
+   The WWW-Authenticate response-header field MUST be included in 401
+   (Unauthorized) response messages. The field value consists of at
+   least one challenge that indicates the authentication scheme(s) and
+   parameters applicable to the Request-URI.
+
+       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. User
+   agents are advised to take special care in parsing the WWW-
+   Authenticate field value as it might contain more than one challenge,
+   or if more than one WWW-Authenticate header field is provided, the
+   contents of a challenge itself can contain a comma-separated list of
+   authentication parameters.
+
+15 Security Considerations
+
+   This section is meant to inform application developers, information
+   providers, and users of the security limitations in HTTP/1.1 as
+   described by this document. The discussion does not include
+   definitive solutions to the problems revealed, though it does make
+   some suggestions for reducing security risks.
+
+
+
+Fielding, et al.            Standards Track                   [Page 150]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.1 Personal Information
+
+   HTTP clients are often privy to large amounts of personal information
+   (e.g. the user's name, location, mail address, passwords, encryption
+   keys, etc.), and SHOULD be very careful to prevent unintentional
+   leakage of this information via the HTTP protocol to other sources.
+   We very strongly recommend that a convenient interface be provided
+   for the user to control dissemination of such information, and that
+   designers and implementors be particularly careful in this area.
+   History shows that errors in this area often create serious security
+   and/or privacy problems and generate highly adverse publicity for the
+   implementor's company.
+
+15.1.1 Abuse of Server Log Information
+
+   A server is in the position to save personal data about a user's
+   requests which might identify their reading patterns or subjects of
+   interest. This information is clearly confidential in nature and its
+   handling can be constrained by law in certain countries. People using
+   the HTTP protocol to provide data are responsible for ensuring that
+   such material is not distributed without the permission of any
+   individuals that are identifiable by the published results.
+
+15.1.2 Transfer of Sensitive Information
+
+   Like any generic data transfer protocol, HTTP cannot regulate the
+   content of the data that is transferred, nor is there any a priori
+   method of determining the sensitivity of any particular piece of
+   information within the context of any given request. Therefore,
+   applications SHOULD supply as much control over this information as
+   possible to the provider of that information. Four header fields are
+   worth special mention in this context: Server, Via, Referer and From.
+
+   Revealing the specific software version of the server might allow the
+   server machine to become more vulnerable to attacks against software
+   that is known to contain security holes. Implementors SHOULD make the
+   Server header field a configurable option.
+
+   Proxies which serve as a portal through a network firewall SHOULD
+   take special precautions regarding the transfer of header information
+   that identifies the hosts behind the firewall. In particular, they
+   SHOULD remove, or replace with sanitized versions, any Via fields
+   generated behind the firewall.
+
+   The Referer header allows reading patterns to be studied and reverse
+   links drawn. Although it can be very useful, its power can be abused
+   if user details are not separated from the information contained in
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 151]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the Referer. Even when the personal information has been removed, the
+   Referer header might indicate a private document's URI whose
+   publication would be inappropriate.
+
+   The information sent in the From field might conflict with the user's
+   privacy interests or their site's security policy, and hence it
+   SHOULD NOT be transmitted without the user being able to disable,
+   enable, and modify the contents of the field. The user MUST be able
+   to set the contents of this field within a user preference or
+   application defaults configuration.
+
+   We suggest, though do not require, that a convenient toggle interface
+   be provided for the user to enable or disable the sending of From and
+   Referer information.
+
+   The User-Agent (section 14.43) or Server (section 14.38) header
+   fields can sometimes be used to determine that a specific client or
+   server have a particular security hole which might be exploited.
+   Unfortunately, this same information is often used for other valuable
+   purposes for which HTTP currently has no better mechanism.
+
+15.1.3 Encoding Sensitive Information in URI's
+
+   Because the source of a link might be private information or might
+   reveal an otherwise private information source, it is strongly
+   recommended that the user be able to select whether or not the
+   Referer field is sent. For example, a browser client could have a
+   toggle switch for browsing openly/anonymously, which would
+   respectively enable/disable the sending of Referer and From
+   information.
+
+   Clients SHOULD NOT include a Referer header field in a (non-secure)
+   HTTP request if the referring page was transferred with a secure
+   protocol.
+
+   Authors of services which use the HTTP protocol SHOULD NOT use GET
+   based forms for the submission of sensitive data, because this will
+   cause this data to be encoded in the Request-URI. Many existing
+   servers, proxies, and user agents will log the request URI in some
+   place where it might be visible to third parties. Servers can use
+   POST-based form submission instead
+
+15.1.4 Privacy Issues Connected to Accept Headers
+
+   Accept request-headers can reveal information about the user to all
+   servers which are accessed. The Accept-Language header in particular
+   can reveal information the user would consider to be of a private
+   nature, because the understanding of particular languages is often
+
+
+
+Fielding, et al.            Standards Track                   [Page 152]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   strongly correlated to the membership of a particular ethnic group.
+   User agents which offer the option to configure the contents of an
+   Accept-Language header to be sent in every request are strongly
+   encouraged to let the configuration process include a message which
+   makes the user aware of the loss of privacy involved.
+
+   An approach that limits the loss of privacy would be for a user agent
+   to omit the sending of Accept-Language headers by default, and to ask
+   the user whether or not to start sending Accept-Language headers to a
+   server if it detects, by looking for any Vary response-header fields
+   generated by the server, that such sending could improve the quality
+   of service.
+
+   Elaborate user-customized accept header fields sent in every request,
+   in particular if these include quality values, can be used by servers
+   as relatively reliable and long-lived user identifiers. Such user
+   identifiers would allow content providers to do click-trail tracking,
+   and would allow collaborating content providers to match cross-server
+   click-trails or form submissions of individual users. Note that for
+   many users not behind a proxy, the network address of the host
+   running the user agent will also serve as a long-lived user
+   identifier. In environments where proxies are used to enhance
+   privacy, user agents ought to be conservative in offering accept
+   header configuration options to end users. As an extreme privacy
+   measure, proxies could filter the accept headers in relayed requests.
+   General purpose user agents which provide a high degree of header
+   configurability SHOULD warn users about the loss of privacy which can
+   be involved.
+
+15.2 Attacks Based On File and Path Names
+
+   Implementations of HTTP origin servers SHOULD be careful to restrict
+   the documents returned by HTTP requests to be only those that were
+   intended by the server administrators. If an HTTP server translates
+   HTTP URIs directly into file system calls, the server MUST take
+   special care not to serve files that were not intended to be
+   delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
+   other operating systems use ".." as a path component to indicate a
+   directory level above the current one. On such a system, an HTTP
+   server MUST disallow any such construct in the Request-URI if it
+   would otherwise allow access to a resource outside those intended to
+   be accessible via the HTTP server. Similarly, files intended for
+   reference only internally to the server (such as access control
+   files, configuration files, and script code) MUST be protected from
+   inappropriate retrieval, since they might contain sensitive
+   information. Experience has shown that minor bugs in such HTTP server
+   implementations have turned into security risks.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 153]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.3 DNS Spoofing
+
+   Clients using HTTP rely heavily on the Domain Name Service, and are
+   thus generally prone to security attacks based on the deliberate
+   mis-association of IP addresses and DNS names. Clients need to be
+   cautious in assuming the continuing validity of an IP number/DNS name
+   association.
+
+   In particular, HTTP clients SHOULD rely on their name resolver for
+   confirmation of an IP number/DNS name association, rather than
+   caching the result of previous host name lookups. Many platforms
+   already can cache host name lookups locally when appropriate, and
+   they SHOULD be configured to do so. It is proper for these lookups to
+   be cached, however, only when the TTL (Time To Live) information
+   reported by the name server makes it likely that the cached
+   information will remain useful.
+
+   If HTTP clients cache the results of host name lookups in order to
+   achieve a performance improvement, they MUST observe the TTL
+   information reported by DNS.
+
+   If HTTP clients do not observe this rule, they could be spoofed when
+   a previously-accessed server's IP address changes. As network
+   renumbering is expected to become increasingly common [24], the
+   possibility of this form of attack will grow. Observing this
+   requirement thus reduces this potential security vulnerability.
+
+   This requirement also improves the load-balancing behavior of clients
+   for replicated servers using the same DNS name and reduces the
+   likelihood of a user's experiencing failure in accessing sites which
+   use that strategy.
+
+15.4 Location Headers and Spoofing
+
+   If a single server supports multiple organizations that do not trust
+   one another, then it MUST check the values of Location and Content-
+   Location headers in responses that are generated under control of
+   said organizations to make sure that they do not attempt to
+   invalidate resources over which they have no authority.
+
+15.5 Content-Disposition Issues
+
+   RFC 1806 [35], from which the often implemented Content-Disposition
+   (see section 19.5.1) header in HTTP is derived, has a number of very
+   serious security considerations. Content-Disposition is not part of
+   the HTTP standard, but since it is widely implemented, we are
+   documenting its use and risks for implementors. See RFC 2183 [49]
+   (which updates RFC 1806) for details.
+
+
+
+Fielding, et al.            Standards Track                   [Page 154]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.6 Authentication Credentials and Idle Clients
+
+   Existing HTTP clients and user agents typically retain authentication
+   information indefinitely. HTTP/1.1. does not provide a method for a
+   server to direct clients to discard these cached credentials. This is
+   a significant defect that requires further extensions to HTTP.
+   Circumstances under which credential caching can interfere with the
+   application's security model include but are not limited to:
+
+      - Clients which have been idle for an extended period following
+        which the server might wish to cause the client to reprompt the
+        user for credentials.
+
+      - Applications which include a session termination indication
+        (such as a `logout' or `commit' button on a page) after which
+        the server side of the application `knows' that there is no
+        further reason for the client to retain the credentials.
+
+   This is currently under separate study. There are a number of work-
+   arounds to parts of this problem, and we encourage the use of
+   password protection in screen savers, idle time-outs, and other
+   methods which mitigate the security problems inherent in this
+   problem. In particular, user agents which cache credentials are
+   encouraged to provide a readily accessible mechanism for discarding
+   cached credentials under user control.
+
+15.7 Proxies and Caching
+
+   By their very nature, HTTP proxies are men-in-the-middle, and
+   represent an opportunity for man-in-the-middle attacks. Compromise of
+   the systems on which the proxies run can result in serious security
+   and privacy problems. Proxies have access to security-related
+   information, personal information about individual users and
+   organizations, and proprietary information belonging to users and
+   content providers. A compromised proxy, or a proxy implemented or
+   configured without regard to security and privacy considerations,
+   might be used in the commission of a wide range of potential attacks.
+
+   Proxy operators should protect the systems on which proxies run as
+   they would protect any system that contains or transports sensitive
+   information. In particular, log information gathered at proxies often
+   contains highly sensitive personal information, and/or information
+   about organizations. Log information should be carefully guarded, and
+   appropriate guidelines for use developed and followed. (Section
+   15.1.1).
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 155]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Caching proxies provide additional potential vulnerabilities, since
+   the contents of the cache represent an attractive target for
+   malicious exploitation. Because cache contents persist after an HTTP
+   request is complete, an attack on the cache can reveal information
+   long after a user believes that the information has been removed from
+   the network. Therefore, cache contents should be protected as
+   sensitive information.
+
+   Proxy implementors should consider the privacy and security
+   implications of their design and coding decisions, and of the
+   configuration options they provide to proxy operators (especially the
+   default configuration).
+
+   Users of a proxy need to be aware that they are no trustworthier than
+   the people who run the proxy; HTTP itself cannot solve this problem.
+
+   The judicious use of cryptography, when appropriate, may suffice to
+   protect against a broad range of security and privacy attacks. Such
+   cryptography is beyond the scope of the HTTP/1.1 specification.
+
+15.7.1 Denial of Service Attacks on Proxies
+
+   They exist. They are hard to defend against. Research continues.
+   Beware.
+
+16 Acknowledgments
+
+   This specification makes heavy use of the augmented BNF and generic
+   constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
+   reuses many of the definitions provided by Nathaniel Borenstein and
+   Ned Freed for MIME [7]. We hope that their inclusion in this
+   specification will help reduce past confusion over the relationship
+   between HTTP and Internet mail message formats.
+
+   The HTTP protocol has evolved considerably over the years. It has
+   benefited from a large and active developer community--the many
+   people who have participated on the www-talk mailing list--and it is
+   that community which has been most responsible for the success of
+   HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
+   Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
+   Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
+   McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
+   VanHeyningen deserve special recognition for their efforts in
+   defining early aspects of the protocol.
+
+   This document has benefited greatly from the comments of all those
+   participating in the HTTP-WG. In addition to those already mentioned,
+   the following individuals have contributed to this specification:
+
+
+
+Fielding, et al.            Standards Track                   [Page 156]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       Gary Adams                  Ross Patterson
+       Harald Tveit Alvestrand     Albert Lunde
+       Keith Ball                  John C. Mallery
+       Brian Behlendorf            Jean-Philippe Martin-Flatin
+       Paul Burchard               Mitra
+       Maurizio Codogno            David Morris
+       Mike Cowlishaw              Gavin Nicol
+       Roman Czyborra              Bill Perry
+       Michael A. Dolan            Jeffrey Perry
+       David J. Fiander            Scott Powers
+       Alan Freier                 Owen Rees
+       Marc Hedlund                Luigi Rizzo
+       Greg Herlihy                David Robinson
+       Koen Holtman                Marc Salomon
+       Alex Hopmann                Rich Salz
+       Bob Jernigan                Allan M. Schiffman
+       Shel Kaphan                 Jim Seidman
+       Rohit Khare                 Chuck Shotton
+       John Klensin                Eric W. Sink
+       Martijn Koster              Simon E. Spero
+       Alexei Kosut                Richard N. Taylor
+       David M. Kristol            Robert S. Thau
+       Daniel LaLiberte            Bill (BearHeart) Weinman
+       Ben Laurie                  Francois Yergeau
+       Paul J. Leach               Mary Ellen Zurko
+       Daniel DuBois               Josh Cohen
+
+
+   Much of the content and presentation of the caching design is due to
+   suggestions and comments from individuals including: Shel Kaphan,
+   Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
+
+   Most of the specification of ranges is based on work originally done
+   by Ari Luotonen and John Franks, with additional input from Steve
+   Zilles.
+
+   Thanks to the "cave men" of Palo Alto. You know who you are.
+
+   Jim Gettys (the current editor of this document) wishes particularly
+   to thank Roy Fielding, the previous editor of this document, along
+   with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
+   Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
+   Larry Masinter for their help. And thanks go particularly to Jeff
+   Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 157]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
+   Frystyk implemented RFC 2068 early, and we wish to thank them for the
+   discovery of many of the problems that this document attempts to
+   rectify.
+
+17 References
+
+   [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
+       1766, March 1995.
+
+   [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
+       D. and B. Alberti, "The Internet Gopher Protocol (a distributed
+       document search and retrieval protocol)", RFC 1436, March 1993.
+
+   [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
+       1630, June 1994.
+
+   [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+       Locators (URL)", RFC 1738, December 1994.
+
+   [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
+       2.0", RFC 1866, November 1995.
+
+   [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
+       Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+       Extensions (MIME) Part One: Format of Internet Message Bodies",
+       RFC 2045, November 1996.
+
+   [8] Braden, R., "Requirements for Internet Hosts -- Communication
+       Layers", STD 3, RFC 1123, October 1989.
+
+   [9] Crocker, D., "Standard for The Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, August 1982.
+
+   [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
+        Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
+        Functional Specification," (v1.5), Thinking Machines
+        Corporation, April 1990.
+
+   [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
+        June 1995.
+
+   [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
+        Messages", RFC 1036, December 1987.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 158]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
+        977, February 1986.
+
+   [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+        November 1996.
+
+   [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
+        1867, November 1995.
+
+   [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+        August 1982.
+
+   [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
+        November 1996.
+
+   [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
+        959, October 1985.
+
+   [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+        October 1994.
+
+   [20] Sollins, K. and L. Masinter, "Functional Requirements for
+        Uniform Resource Names", RFC 1737, December 1994.
+
+   [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
+        Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
+
+   [22] ISO-8859. International Standard -- Information Processing --
+        8-bit Single-Byte Coded Graphic Character Sets --
+        Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
+        Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
+        Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
+        Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
+        Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
+        Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
+        Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
+        Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
+        Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
+
+   [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
+        1864, October 1995.
+
+   [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
+        1900, February 1996.
+
+   [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
+        1952, May 1996.
+
+
+
+Fielding, et al.            Standards Track                   [Page 159]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
+        Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
+        Dec. 1995. Slightly revised version of paper in Proc. 2nd
+        International WWW Conference '94: Mosaic and the Web, Oct. 1994,
+        which is available at
+        http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
+        ency.html.
+
+   [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
+        Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
+        ISI Research Report ISI/RR-98-463, (original report dated Aug.
+        1996), USC/Information Sciences Institute, August 1998.
+
+   [28] Mills, D., "Network Time Protocol (Version 3) Specification,
+        Implementation and Analysis", RFC 1305, March 1992.
+
+   [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
+        version 1.3", RFC 1951, May 1996.
+
+   [30] S. Spero, "Analysis of HTTP Performance Problems,"
+        http://sunsite.unc.edu/mdma-release/http-prob.html.
+
+   [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
+        Specification version 3.3", RFC 1950, May 1996.
+
+   [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
+        Digest Access Authentication", RFC 2069, January 1997.
+
+   [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+        2068, January 1997.
+
+   [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [35] Troost, R. and Dorner, S., "Communicating Presentation
+        Information in Internet Messages: The Content-Disposition
+        Header", RFC 1806, June 1995.
+
+   [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
+        Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
+        [jg639]
+
+   [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
+        1997. [jg640]
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 160]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
+        ISO-10646", RFC 2279, January 1998. [jg641]
+
+   [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
+        Lie, H., and C. Lilley. "Network Performance Effects of
+        HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
+        France, September 1997.[jg642]
+
+   [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Two: Media Types", RFC 2046, November
+        1996. [jg643]
+
+   [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
+        BCP 18, RFC 2277, January 1998. [jg644]
+
+   [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
+        August 1998. [jg645]
+
+   [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+        Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
+        Authentication: Basic and Digest Access Authentication", RFC
+        2617, June 1999. [jg646]
+
+   [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
+        servers," Work in Progress. [jg647]
+
+   [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
+        Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
+        1997.
+
+   [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
+        (HTCPCP/1.0)", RFC 2324, 1 April 1998.
+
+   [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Five: Conformance Criteria and Examples",
+        RFC 2049, November 1996.
+
+   [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
+        Information in Internet Messages: The Content-Disposition Header
+        Field", RFC 2183, August 1997.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 161]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+18 Authors' Addresses
+
+   Roy T. Fielding
+   Information and Computer Science
+   University of California, Irvine
+   Irvine, CA 92697-3425, USA
+
+   Fax: +1 (949) 824-1715
+   EMail: fielding@ics.uci.edu
+
+
+   James Gettys
+   World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: jg@w3.org
+
+
+   Jeffrey C. Mogul
+   Western Research Laboratory
+   Compaq Computer Corporation
+   250 University Avenue
+   Palo Alto, California, 94305, USA
+
+   EMail: mogul@wrl.dec.com
+
+
+   Henrik Frystyk Nielsen
+   World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: frystyk@w3.org
+
+
+   Larry Masinter
+   Xerox Corporation
+   3333 Coyote Hill Road
+   Palo Alto, CA 94034, USA
+
+   EMail: masinter@parc.xerox.com
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 162]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Paul J. Leach
+   Microsoft Corporation
+   1 Microsoft Way
+   Redmond, WA 98052, USA
+
+   EMail: paulle@microsoft.com
+
+
+   Tim Berners-Lee
+   Director, World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: timbl@w3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 163]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+19 Appendices
+
+19.1 Internet Media Type message/http and application/http
+
+   In addition to defining the HTTP/1.1 protocol, this document serves
+   as the specification for the Internet media type "message/http" and
+   "application/http". The message/http type can be used to enclose a
+   single HTTP request or response message, provided that it obeys the
+   MIME restrictions for all "message" types regarding line length and
+   encodings. The application/http type can be used to enclose a
+   pipeline of one or more HTTP request or response messages (not
+   intermixed). The following is to be registered with IANA [17].
+
+       Media Type name:         message
+       Media subtype name:      http
+       Required parameters:     none
+       Optional parameters:     version, msgtype
+        version: The HTTP-Version number of the enclosed message
+                 (e.g., "1.1"). If not present, the version can be
+                 determined from the first line of the body.
+        msgtype: The message type -- "request" or "response". If not
+                 present, the type can be determined from the first
+                 line of the body.
+       Encoding considerations: only "7bit", "8bit", or "binary" are
+                                permitted
+       Security considerations: none
+
+       Media Type name:         application
+       Media subtype name:      http
+       Required parameters:     none
+       Optional parameters:     version, msgtype
+        version: The HTTP-Version number of the enclosed messages
+                 (e.g., "1.1"). If not present, the version can be
+                 determined from the first line of the body.
+        msgtype: The message type -- "request" or "response". If not
+                 present, the type can be determined from the first
+                 line of the body.
+       Encoding considerations: HTTP messages enclosed by this type
+                 are in "binary" format; use of an appropriate
+                 Content-Transfer-Encoding is required when
+                 transmitted via E-mail.
+       Security considerations: none
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 164]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+19.2 Internet Media Type multipart/byteranges
+
+   When an HTTP 206 (Partial Content) response message includes the
+   content of multiple ranges (a response to a request for multiple
+   non-overlapping ranges), these are transmitted as a multipart
+   message-body. The media type for this purpose is called
+   "multipart/byteranges".
+
+   The multipart/byteranges media type includes two or more parts, each
+   with its own Content-Type and Content-Range fields. The required
+   boundary parameter specifies the boundary string used to separate
+   each body-part.
+
+       Media Type name:         multipart
+       Media subtype name:      byteranges
+       Required parameters:     boundary
+       Optional parameters:     none
+       Encoding considerations: only "7bit", "8bit", or "binary" are
+                                permitted
+       Security considerations: none
+
+
+   For example:
+
+   HTTP/1.1 206 Partial Content
+   Date: Wed, 15 Nov 1995 06:25:24 GMT
+   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+   Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+
+   --THIS_STRING_SEPARATES
+   Content-type: application/pdf
+   Content-range: bytes 500-999/8000
+
+   ...the first range...
+   --THIS_STRING_SEPARATES
+   Content-type: application/pdf
+   Content-range: bytes 7000-7999/8000
+
+   ...the second range
+   --THIS_STRING_SEPARATES--
+
+      Notes:
+
+      1) Additional CRLFs may precede the first boundary string in the
+         entity.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 165]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      2) Although RFC 2046 [40] permits the boundary string to be
+         quoted, some existing implementations handle a quoted boundary
+         string incorrectly.
+
+      3) A number of browsers and servers were coded to an early draft
+         of the byteranges specification to use a media type of
+         multipart/x-byteranges, which is almost, but not quite
+         compatible with the version documented in HTTP/1.1.
+
+19.3 Tolerant Applications
+
+   Although this document specifies the requirements for the generation
+   of HTTP/1.1 messages, not all applications will be correct in their
+   implementation. We therefore recommend that operational applications
+   be tolerant of deviations whenever those deviations can be
+   interpreted unambiguously.
+
+   Clients SHOULD be tolerant in parsing the Status-Line and servers
+   tolerant when parsing the Request-Line. In particular, they SHOULD
+   accept any amount of SP or HT characters between fields, even though
+   only a single SP is required.
+
+   The line terminator for message-header fields is the sequence CRLF.
+   However, we recommend that applications, when parsing such headers,
+   recognize a single LF as a line terminator and ignore the leading CR.
+
+   The character set of an entity-body SHOULD be labeled as the lowest
+   common denominator of the character codes used within that body, with
+   the exception that not labeling the entity is preferred over labeling
+   the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
+   and 3.4.1.
+
+   Additional rules for requirements on parsing and encoding of dates
+   and other potential problems with date encodings include:
+
+      - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
+        which appears to be more than 50 years in the future is in fact
+        in the past (this helps solve the "year 2000" problem).
+
+      - An HTTP/1.1 implementation MAY internally represent a parsed
+        Expires date as earlier than the proper value, but MUST NOT
+        internally represent a parsed Expires date as later than the
+        proper value.
+
+      - All expiration-related calculations MUST be done in GMT. The
+        local time zone MUST NOT influence the calculation or comparison
+        of an age or expiration time.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 166]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - If an HTTP header incorrectly carries a date value with a time
+        zone other than GMT, it MUST be converted into GMT using the
+        most conservative possible conversion.
+
+19.4 Differences Between HTTP Entities and RFC 2045 Entities
+
+   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
+   822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
+   allow entities to be transmitted in an open variety of
+   representations and with extensible mechanisms. However, RFC 2045
+   discusses mail, and HTTP has a few features that are different from
+   those described in RFC 2045. These differences were carefully chosen
+   to optimize performance over binary connections, to allow greater
+   freedom in the use of new media types, to make date comparisons
+   easier, and to acknowledge the practice of some early HTTP servers
+   and clients.
+
+   This appendix describes specific areas where HTTP differs from RFC
+   2045. Proxies and gateways to strict MIME environments SHOULD be
+   aware of these differences and provide the appropriate conversions
+   where necessary. Proxies and gateways from MIME environments to HTTP
+   also need to be aware of the differences because some conversions
+   might be required.
+
+19.4.1 MIME-Version
+
+   HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
+   include a single MIME-Version general-header field to indicate what
+   version of the MIME protocol was used to construct the message. Use
+   of the MIME-Version header field indicates that the message is in
+   full compliance with the MIME protocol (as defined in RFC 2045[7]).
+   Proxies/gateways are responsible for ensuring full compliance (where
+   possible) when exporting HTTP messages to strict MIME environments.
+
+       MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+   MIME version "1.0" is the default for use in HTTP/1.1. However,
+   HTTP/1.1 message parsing and semantics are defined by this document
+   and not the MIME specification.
+
+19.4.2 Conversion to Canonical Form
+
+   RFC 2045 [7] requires that an Internet mail entity be converted to
+   canonical form prior to being transferred, as described in section 4
+   of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
+   allowed for subtypes of the "text" media type when transmitted over
+   HTTP. RFC 2046 requires that content with a type of "text" represent
+   line breaks as CRLF and forbids the use of CR or LF outside of line
+
+
+
+Fielding, et al.            Standards Track                   [Page 167]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
+   line break within text content when a message is transmitted over
+   HTTP.
+
+   Where it is possible, a proxy or gateway from HTTP to a strict MIME
+   environment SHOULD translate all line breaks within the text media
+   types described in section 3.7.1 of this document to the RFC 2049
+   canonical form of CRLF. Note, however, that this might be complicated
+   by the presence of a Content-Encoding and by the fact that HTTP
+   allows the use of some character sets which do not use octets 13 and
+   10 to represent CR and LF, as is the case for some multi-byte
+   character sets.
+
+   Implementors should note that conversion will break any cryptographic
+   checksums applied to the original content unless the original content
+   is already in canonical form. Therefore, the canonical form is
+   recommended for any content that uses such checksums in HTTP.
+
+19.4.3 Conversion of Date Formats
+
+   HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
+   simplify the process of date comparison. Proxies and gateways from
+   other protocols SHOULD ensure that any Date header field present in a
+   message conforms to one of the HTTP/1.1 formats and rewrite the date
+   if necessary.
+
+19.4.4 Introduction of Content-Encoding
+
+   RFC 2045 does not include any concept equivalent to HTTP/1.1's
+   Content-Encoding header field. Since this acts as a modifier on the
+   media type, proxies and gateways from HTTP to MIME-compliant
+   protocols MUST either change the value of the Content-Type header
+   field or decode the entity-body before forwarding the message. (Some
+   experimental applications of Content-Type for Internet mail have used
+   a media-type parameter of ";conversions=<content-coding>" to perform
+   a function equivalent to Content-Encoding. However, this parameter is
+   not part of RFC 2045.)
+
+19.4.5 No Content-Transfer-Encoding
+
+   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
+   2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
+   remove any non-identity CTE ("quoted-printable" or "base64") encoding
+   prior to delivering the response message to an HTTP client.
+
+   Proxies and gateways from HTTP to MIME-compliant protocols are
+   responsible for ensuring that the message is in the correct format
+   and encoding for safe transport on that protocol, where "safe
+
+
+
+Fielding, et al.            Standards Track                   [Page 168]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   transport" is defined by the limitations of the protocol being used.
+   Such a proxy or gateway SHOULD label the data with an appropriate
+   Content-Transfer-Encoding if doing so will improve the likelihood of
+   safe transport over the destination protocol.
+
+19.4.6 Introduction of Transfer-Encoding
+
+   HTTP/1.1 introduces the Transfer-Encoding header field (section
+   14.41). Proxies/gateways MUST remove any transfer-coding prior to
+   forwarding a message via a MIME-compliant protocol.
+
+   A process for decoding the "chunked" transfer-coding (section 3.6)
+   can be represented in pseudo-code as:
+
+       length := 0
+       read chunk-size, chunk-extension (if any) and CRLF
+       while (chunk-size > 0) {
+          read chunk-data and CRLF
+          append chunk-data to entity-body
+          length := length + chunk-size
+          read chunk-size and CRLF
+       }
+       read entity-header
+       while (entity-header not empty) {
+          append entity-header to existing header fields
+          read entity-header
+       }
+       Content-Length := length
+       Remove "chunked" from Transfer-Encoding
+
+19.4.7 MHTML and Line Length Limitations
+
+   HTTP implementations which share code with MHTML [45] implementations
+   need to be aware of MIME line length limitations. Since HTTP does not
+   have this limitation, HTTP does not fold long lines. MHTML messages
+   being transported by HTTP follow all conventions of MHTML, including
+   line length limitations and folding, canonicalization, etc., since
+   HTTP transports all message-bodies as payload (see section 3.7.2) and
+   does not interpret the content or any MIME header lines that might be
+   contained therein.
+
+19.5 Additional Features
+
+   RFC 1945 and RFC 2068 document protocol elements used by some
+   existing HTTP implementations, but not consistently and correctly
+   across most HTTP/1.1 applications. Implementors are advised to be
+   aware of these features, but cannot rely upon their presence in, or
+   interoperability with, other HTTP/1.1 applications. Some of these
+
+
+
+Fielding, et al.            Standards Track                   [Page 169]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   describe proposed experimental features, and some describe features
+   that experimental deployment found lacking that are now addressed in
+   the base HTTP/1.1 specification.
+
+   A number of other headers, such as Content-Disposition and Title,
+   from SMTP and MIME are also often implemented (see RFC 2076 [37]).
+
+19.5.1 Content-Disposition
+
+   The Content-Disposition response-header field has been proposed as a
+   means for the origin server to suggest a default filename if the user
+   requests that the content is saved to a file. This usage is derived
+   from the definition of Content-Disposition in RFC 1806 [35].
+
+        content-disposition = "Content-Disposition" ":"
+                              disposition-type *( ";" disposition-parm )
+        disposition-type = "attachment" | disp-extension-token
+        disposition-parm = filename-parm | disp-extension-parm
+        filename-parm = "filename" "=" quoted-string
+        disp-extension-token = token
+        disp-extension-parm = token "=" ( token | quoted-string )
+
+   An example is
+
+        Content-Disposition: attachment; filename="fname.ext"
+
+   The receiving user agent SHOULD NOT respect any directory path
+   information present in the filename-parm parameter, which is the only
+   parameter believed to apply to HTTP implementations at this time. The
+   filename SHOULD be treated as a terminal component only.
+
+   If this header is used in a response with the application/octet-
+   stream content-type, the implied suggestion is that the user agent
+   should not display the response, but directly enter a `save response
+   as...' dialog.
+
+   See section 15.5 for Content-Disposition security issues.
+
+19.6 Compatibility with Previous Versions
+
+   It is beyond the scope of a protocol specification to mandate
+   compliance with previous versions. HTTP/1.1 was deliberately
+   designed, however, to make supporting previous versions easy. It is
+   worth noting that, at the time of composing this specification
+   (1996), we would expect commercial HTTP/1.1 servers to:
+
+      - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
+        1.1 requests;
+
+
+
+Fielding, et al.            Standards Track                   [Page 170]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - understand any valid request in the format of HTTP/0.9, 1.0, or
+        1.1;
+
+      - respond appropriately with a message in the same major version
+        used by the client.
+
+   And we would expect HTTP/1.1 clients to:
+
+      - recognize the format of the Status-Line for HTTP/1.0 and 1.1
+        responses;
+
+      - understand any valid response in the format of HTTP/0.9, 1.0, or
+        1.1.
+
+   For most implementations of HTTP/1.0, each connection is established
+   by the client prior to the request and closed by the server after
+   sending the response. Some implementations implement the Keep-Alive
+   version of persistent connections described in section 19.7.1 of RFC
+   2068 [33].
+
+19.6.1 Changes from HTTP/1.0
+
+   This section summarizes major differences between versions HTTP/1.0
+   and HTTP/1.1.
+
+19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
+         Addresses
+
+   The requirements that clients and servers support the Host request-
+   header, report an error if the Host request-header (section 14.23) is
+   missing from an HTTP/1.1 request, and accept absolute URIs (section
+   5.1.2) are among the most important changes defined by this
+   specification.
+
+   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+   addresses and servers; there was no other established mechanism for
+   distinguishing the intended server of a request than the IP address
+   to which that request was directed. The changes outlined above will
+   allow the Internet, once older HTTP clients are no longer common, to
+   support multiple Web sites from a single IP address, greatly
+   simplifying large operational Web servers, where allocation of many
+   IP addresses to a single host has created serious problems. The
+   Internet will also be able to recover the IP addresses that have been
+   allocated for the sole purpose of allowing special-purpose domain
+   names to be used in root-level HTTP URLs. Given the rate of growth of
+   the Web, and the number of servers already deployed, it is extremely
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 171]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   important that all implementations of HTTP (including updates to
+   existing HTTP/1.0 applications) correctly implement these
+   requirements:
+
+      - Both clients and servers MUST support the Host request-header.
+
+      - A client that sends an HTTP/1.1 request MUST send a Host header.
+
+      - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
+        request does not include a Host request-header.
+
+      - Servers MUST accept absolute URIs.
+
+19.6.2 Compatibility with HTTP/1.0 Persistent Connections
+
+   Some clients and servers might wish to be compatible with some
+   previous implementations of persistent connections in HTTP/1.0
+   clients and servers. Persistent connections in HTTP/1.0 are
+   explicitly negotiated as they are not the default behavior. HTTP/1.0
+   experimental implementations of persistent connections are faulty,
+   and the new facilities in HTTP/1.1 are designed to rectify these
+   problems. The problem was that some existing 1.0 clients may be
+   sending Keep-Alive to a proxy server that doesn't understand
+   Connection, which would then erroneously forward it to the next
+   inbound server, which would establish the Keep-Alive connection and
+   result in a hung HTTP/1.0 proxy waiting for the close on the
+   response. The result is that HTTP/1.0 clients must be prevented from
+   using Keep-Alive when talking to proxies.
+
+   However, talking to proxies is the most important use of persistent
+   connections, so that prohibition is clearly unacceptable. Therefore,
+   we need some other mechanism for indicating a persistent connection
+   is desired, which is safe to use even when talking to an old proxy
+   that ignores Connection. Persistent connections are the default for
+   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
+   declaring non-persistence. See section 14.10.
+
+   The original HTTP/1.0 form of persistent connections (the Connection:
+   Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
+
+19.6.3 Changes from RFC 2068
+
+   This specification has been carefully audited to correct and
+   disambiguate key word usage; RFC 2068 had many problems in respect to
+   the conventions laid out in RFC 2119 [34].
+
+   Clarified which error code should be used for inbound server failures
+   (e.g. DNS failures). (Section 10.5.5).
+
+
+
+Fielding, et al.            Standards Track                   [Page 172]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   CREATE had a race that required an Etag be sent when a resource is
+   first created. (Section 10.2.2).
+
+   Content-Base was deleted from the specification: it was not
+   implemented widely, and there is no simple, safe way to introduce it
+   without a robust extension mechanism. In addition, it is used in a
+   similar, but not identical fashion in MHTML [45].
+
+   Transfer-coding and message lengths all interact in ways that
+   required fixing exactly when chunked encoding is used (to allow for
+   transfer encoding that may not be self delimiting); it was important
+   to straighten out exactly how message lengths are computed. (Sections
+   3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
+
+   A content-coding of "identity" was introduced, to solve problems
+   discovered in caching. (section 3.5)
+
+   Quality Values of zero should indicate that "I don't want something"
+   to allow clients to refuse a representation. (Section 3.9)
+
+   The use and interpretation of HTTP version numbers has been clarified
+   by RFC 2145. Require proxies to upgrade requests to highest protocol
+   version they support to deal with problems discovered in HTTP/1.0
+   implementations (Section 3.1)
+
+   Charset wildcarding is introduced to avoid explosion of character set
+   names in accept headers. (Section 14.2)
+
+   A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
+   was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
+   14.9.3)
+
+   The Cache-Control: max-age directive was not properly defined for
+   responses. (Section 14.9.3)
+
+   There are situations where a server (especially a proxy) does not
+   know the full length of a response but is capable of serving a
+   byterange request. We therefore need a mechanism to allow byteranges
+   with a content-range not indicating the full length of the message.
+   (Section 14.16)
+
+   Range request responses would become very verbose if all meta-data
+   were always returned; by allowing the server to only send needed
+   headers in a 206 response, this problem can be avoided. (Section
+   10.2.7, 13.5.3, and 14.27)
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 173]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Fix problem with unsatisfiable range requests; there are two cases:
+   syntactic problems, and range doesn't exist in the document. The 416
+   status code was needed to resolve this ambiguity needed to indicate
+   an error for a byte range request that falls outside of the actual
+   contents of a document. (Section 10.4.17, 14.16)
+
+   Rewrite of message transmission requirements to make it much harder
+   for implementors to get it wrong, as the consequences of errors here
+   can have significant impact on the Internet, and to deal with the
+   following problems:
+
+      1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
+         this was incorrectly placing a requirement on the behavior of
+         an implementation of a future version of HTTP/1.x
+
+      2. Made it clear that user-agents should retry requests, not
+         "clients" in general.
+
+      3. Converted requirements for clients to ignore unexpected 100
+         (Continue) responses, and for proxies to forward 100 responses,
+         into a general requirement for 1xx responses.
+
+      4. Modified some TCP-specific language, to make it clearer that
+         non-TCP transports are possible for HTTP.
+
+      5. Require that the origin server MUST NOT wait for the request
+         body before it sends a required 100 (Continue) response.
+
+      6. Allow, rather than require, a server to omit 100 (Continue) if
+         it has already seen some of the request body.
+
+      7. Allow servers to defend against denial-of-service attacks and
+         broken clients.
+
+   This change adds the Expect header and 417 status code. The message
+   transmission requirements fixes are in sections 8.2, 10.4.18,
+   8.1.2.2, 13.11, and 14.20.
+
+   Proxies should be able to add Content-Length when appropriate.
+   (Section 13.5.2)
+
+   Clean up confusion between 403 and 404 responses. (Section 10.4.4,
+   10.4.5, and 10.4.11)
+
+   Warnings could be cached incorrectly, or not updated appropriately.
+   (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
+   also needed to be a general header, as PUT or other methods may have
+   need for it in requests.
+
+
+
+Fielding, et al.            Standards Track                   [Page 174]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Transfer-coding had significant problems, particularly with
+   interactions with chunked encoding. The solution is that transfer-
+   codings become as full fledged as content-codings. This involves
+   adding an IANA registry for transfer-codings (separate from content
+   codings), a new header field (TE) and enabling trailer headers in the
+   future. Transfer encoding is a major performance benefit, so it was
+   worth fixing [39]. TE also solves another, obscure, downward
+   interoperability problem that could have occurred due to interactions
+   between authentication trailers, chunked encoding and HTTP/1.0
+   clients.(Section 3.6, 3.6.1, and 14.39)
+
+   The PATCH, LINK, UNLINK methods were defined but not commonly
+   implemented in previous versions of this specification. See RFC 2068
+   [33].
+
+   The Alternates, Content-Version, Derived-From, Link, URI, Public and
+   Content-Base header fields were defined in previous versions of this
+   specification, but not commonly implemented. See RFC 2068 [33].
+
+20 Index
+
+   Please see the PostScript version of this RFC for the INDEX.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 175]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+21.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 176]
+
diff --git a/doc/rfc2812.txt b/doc/rfc2812.txt
new file mode 100644
index 0000000..7f1b162
--- /dev/null
+++ b/doc/rfc2812.txt
@@ -0,0 +1,3531 @@
+
+
+
+
+
+
+Network Working Group                                            C. Kalt
+Request for Comments: 2812                                    April 2000
+Updates: 1459
+Category: Informational
+
+
+                  Internet Relay Chat: Client Protocol
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+IESG NOTE:
+
+   The IRC protocol itself enables several possibilities of transferring
+   data between clients, and just like with other transfer mechanisms
+   like email, the receiver of the data has to be careful about how the
+   data is handled. For more information on security issues with the IRC
+   protocol, see for example http://www.irchelp.org/irchelp/security/.
+
+Abstract
+
+   The IRC (Internet Relay Chat) protocol is for use with text based
+   conferencing; the simplest client being any socket program capable of
+   connecting to the server.
+
+   This document defines the Client Protocol, and assumes that the
+   reader is familiar with the IRC Architecture [IRC-ARCH].
+
+Table of Contents
+
+   1.  Labels .....................................................   3
+      1.1  Servers ................................................   3
+      1.2  Clients ................................................   3
+         1.2.1  Users .............................................   4
+            1.2.1.1  Operators ....................................   4
+         1.2.2  Services ..........................................   4
+      1.3  Channels ...............................................   4
+   2.  The IRC Client Specification ...............................   5
+      2.1  Overview ...............................................   5
+      2.2  Character codes ........................................   5
+      2.3  Messages ...............................................   5
+
+
+
+Kalt                         Informational                      [Page 1]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+         2.3.1  Message format in Augmented BNF ...................   6
+      2.4  Numeric replies ........................................   8
+      2.5  Wildcard expressions ...................................   9
+   3.  Message Details ............................................   9
+      3.1  Connection Registration ................................  10
+         3.1.1  Password message ..................................  10
+         3.1.2  Nick message ......................................  10
+         3.1.3  User message ......................................  11
+         3.1.4  Oper message ......................................  12
+         3.1.5  User mode message .................................  12
+         3.1.6  Service message ...................................  13
+         3.1.7  Quit ..............................................  14
+         3.1.8  Squit .............................................  15
+      3.2  Channel operations .....................................  15
+         3.2.1  Join message ......................................  16
+         3.2.2  Part message ......................................  17
+         3.2.3  Channel mode message ..............................  18
+         3.2.4  Topic message .....................................  19
+         3.2.5  Names message .....................................  20
+         3.2.6  List message ......................................  21
+         3.2.7  Invite message ....................................  21
+         3.2.8  Kick command ......................................  22
+      3.3  Sending messages .......................................  23
+         3.3.1  Private messages ..................................  23
+         3.3.2  Notice ............................................  24
+      3.4  Server queries and commands ............................  25
+         3.4.1  Motd message ......................................  25
+         3.4.2  Lusers message ....................................  25
+         3.4.3  Version message ...................................  26
+         3.4.4  Stats message .....................................  26
+         3.4.5  Links message .....................................  27
+         3.4.6  Time message ......................................  28
+         3.4.7  Connect message ...................................  28
+         3.4.8  Trace message .....................................  29
+         3.4.9  Admin command .....................................  30
+         3.4.10 Info command ......................................  31
+      3.5  Service Query and Commands .............................  31
+         3.5.1  Servlist message ..................................  31
+         3.5.2  Squery ............................................  32
+      3.6  User based queries .....................................  32
+         3.6.1  Who query .........................................  32
+         3.6.2  Whois query .......................................  33
+         3.6.3  Whowas ............................................  34
+      3.7  Miscellaneous messages .................................  34
+         3.7.1  Kill message ......................................  35
+         3.7.2  Ping message ......................................  36
+         3.7.3  Pong message ......................................  37
+         3.7.4  Error .............................................  37
+
+
+
+Kalt                         Informational                      [Page 2]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   4.  Optional features ..........................................  38
+      4.1  Away ...................................................  38
+      4.2  Rehash message .........................................  39
+      4.3  Die message ............................................  39
+      4.4  Restart message ........................................  40
+      4.5  Summon message .........................................  40
+      4.6  Users ..................................................  41
+      4.7  Operwall message .......................................  41
+      4.8  Userhost message .......................................  42
+      4.9  Ison message ...........................................  42
+   5.  Replies ....................................................  43
+      5.1  Command responses ......................................  43
+      5.2  Error Replies ..........................................  53
+      5.3  Reserved numerics ......................................  59
+   6.  Current implementations ....................................  60
+   7.  Current problems ...........................................  60
+      7.1  Nicknames ..............................................  60
+      7.2  Limitation of wildcards ................................  61
+      7.3  Security considerations ................................  61
+   8.  Current support and availability ...........................  61
+   9.  Acknowledgements ...........................................  61
+   10.  References ................................................  62
+   11.  Author's Address ..........................................  62
+   12.  Full Copyright Statement ..................................  63
+
+1. Labels
+
+   This section defines the identifiers used for the various components
+   of the IRC protocol.
+
+1.1 Servers
+
+   Servers are uniquely identified by their name, which has a maximum
+   length of sixty three (63) characters.  See the protocol grammar
+   rules (section 2.3.1) for what may and may not be used in a server
+   name.
+
+1.2 Clients
+
+   For each client all servers MUST have the following information: a
+   netwide unique identifier (whose format depends on the type of
+   client) and the server which introduced the client.
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                      [Page 3]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+1.2.1 Users
+
+   Each user is distinguished from other users by a unique nickname
+   having a maximum length of nine (9) characters.  See the protocol
+   grammar rules (section 2.3.1) for what may and may not be used in a
+   nickname.
+
+   While the maximum length is limited to nine characters, clients
+   SHOULD accept longer strings as they may become used in future
+   evolutions of the protocol.
+
+1.2.1.1 Operators
+
+   To allow a reasonable amount of order to be kept within the IRC
+   network, a special class of users (operators) is allowed to perform
+   general maintenance functions on the network.  Although the powers
+   granted to an operator can be considered as 'dangerous', they are
+   nonetheless often necessary.  Operators SHOULD be able to perform
+   basic network tasks such as disconnecting and reconnecting servers as
+   needed.  In recognition of this need, the protocol discussed herein
+   provides for operators only to be able to perform such functions.
+   See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).
+
+   A more controversial power of operators is the ability to remove a
+   user from the connected network by 'force', i.e., operators are able
+   to close the connection between any client and server.  The
+   justification for this is very delicate since its abuse is both
+   destructive and annoying, and its benefits close to inexistent.  For
+   further details on this type of action, see section 3.7.1 (KILL).
+
+1.2.2 Services
+
+   Each service is distinguished from other services by a service name
+   composed of a nickname and a server name.  As for users, the nickname
+   has a maximum length of nine (9) characters.  See the protocol
+   grammar rules (section 2.3.1) for what may and may not be used in a
+   nickname.
+
+1.3 Channels
+
+   Channels names are strings (beginning with a '&', '#', '+' or '!'
+   character) of length up to fifty (50) characters.  Apart from the
+   requirement that the first character is either '&', '#', '+' or '!',
+   the only restriction on a channel name is that it SHALL NOT contain
+   any spaces (' '), a control G (^G or ASCII 7), a comma (',').  Space
+   is used as parameter separator and command is used as a list item
+   separator by the protocol).  A colon (':') can also be used as a
+   delimiter for the channel mask.  Channel names are case insensitive.
+
+
+
+Kalt                         Informational                      [Page 4]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   See the protocol grammar rules (section 2.3.1) for the exact syntax
+   of a channel name.
+
+   Each prefix characterizes a different channel type.  The definition
+   of the channel types is not relevant to the client-server protocol
+   and thus it is beyond the scope of this document.  More details can
+   be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+2. The IRC Client Specification
+
+2.1 Overview
+
+   The protocol as described herein is for use only with client to
+   server connections when the client registers as a user.
+
+2.2 Character codes
+
+   No specific character set is specified. The protocol is based on a
+   set of codes which are composed of eight (8) bits, making up an
+   octet.  Each message may be composed of any number of these octets;
+   however, some octet values are used for control codes, which act as
+   message delimiters.
+
+   Regardless of being an 8-bit protocol, the delimiters and keywords
+   are such that protocol is mostly usable from US-ASCII terminal and a
+   telnet connection.
+
+   Because of IRC's Scandinavian origin, the characters {}|^ are
+   considered to be the lower case equivalents of the characters []\~,
+   respectively. This is a critical issue when determining the
+   equivalence of two nicknames or channel names.
+
+2.3 Messages
+
+   Servers and clients send each other messages, which may or may not
+   generate a reply.  If the message contains a valid command, as
+   described in later sections, the client should expect a reply as
+   specified but it is not advised to wait forever for the reply; client
+   to server and server to server communication is essentially
+   asynchronous by nature.
+
+   Each IRC message may consist of up to three main parts: the prefix
+   (OPTIONAL), the command, and the command parameters (maximum of
+   fifteen (15)).  The prefix, command, and all parameters are separated
+   by one ASCII space character (0x20) each.
+
+
+
+
+
+
+Kalt                         Informational                      [Page 5]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   The presence of a prefix is indicated with a single leading ASCII
+   colon character (':', 0x3b), which MUST be the first character of the
+   message itself.  There MUST be NO gap (whitespace) between the colon
+   and the prefix.  The prefix is used by servers to indicate the true
+   origin of the message.  If the prefix is missing from the message, it
+   is assumed to have originated from the connection from which it was
+   received from.  Clients SHOULD NOT use a prefix when sending a
+   message; if they use one, the only valid prefix is the registered
+   nickname associated with the client.
+
+   The command MUST either be a valid IRC command or a three (3) digit
+   number represented in ASCII text.
+
+   IRC messages are always lines of characters terminated with a CR-LF
+   (Carriage Return - Line Feed) pair, and these messages SHALL NOT
+   exceed 512 characters in length, counting all characters including
+   the trailing CR-LF. Thus, there are 510 characters maximum allowed
+   for the command and its parameters.  There is no provision for
+   continuation of message lines.  See section 6 for more details about
+   current implementations.
+
+2.3.1 Message format in Augmented BNF
+
+   The protocol messages must be extracted from the contiguous stream of
+   octets.  The current solution is to designate two characters, CR and
+   LF, as message separators.  Empty messages are silently ignored,
+   which permits use of the sequence CR-LF between messages without
+   extra problems.
+
+   The extracted message is parsed into the components <prefix>,
+   <command> and list of parameters (<params>).
+
+    The Augmented BNF representation for this is:
+
+    message    =  [ ":" prefix SPACE ] command [ params ] crlf
+    prefix     =  servername / ( nickname [ [ "!" user ] "@" host ] )
+    command    =  1*letter / 3digit
+    params     =  *14( SPACE middle ) [ SPACE ":" trailing ]
+               =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
+
+    nospcrlfcl =  %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
+                    ; any octet except NUL, CR, LF, " " and ":"
+    middle     =  nospcrlfcl *( ":" / nospcrlfcl )
+    trailing   =  *( ":" / " " / nospcrlfcl )
+
+    SPACE      =  %x20        ; space character
+    crlf       =  %x0D %x0A   ; "carriage return" "linefeed"
+
+
+
+
+Kalt                         Informational                      [Page 6]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   NOTES:
+      1) After extracting the parameter list, all parameters are equal
+         whether matched by <middle> or <trailing>. <trailing> is just a
+         syntactic trick to allow SPACE within the parameter.
+
+      2) The NUL (%x00) character is not special in message framing, and
+         basically could end up inside a parameter, but it would cause
+         extra complexities in normal C string handling. Therefore, NUL
+         is not allowed within messages.
+
+   Most protocol messages specify additional semantics and syntax for
+   the extracted parameter strings dictated by their position in the
+   list.  For example, many server commands will assume that the first
+   parameter after the command is the list of targets, which can be
+   described with:
+
+  target     =  nickname / server
+  msgtarget  =  msgto *( "," msgto )
+  msgto      =  channel / ( user [ "%" host ] "@" servername )
+  msgto      =/ ( user "%" host ) / targetmask
+  msgto      =/ nickname / ( nickname "!" user "@" host )
+  channel    =  ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring
+                [ ":" chanstring ]
+  servername =  hostname
+  host       =  hostname / hostaddr
+  hostname   =  shortname *( "." shortname )
+  shortname  =  ( letter / digit ) *( letter / digit / "-" )
+                *( letter / digit )
+                  ; as specified in RFC 1123 [HNAME]
+  hostaddr   =  ip4addr / ip6addr
+  ip4addr    =  1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
+  ip6addr    =  1*hexdigit 7( ":" 1*hexdigit )
+  ip6addr    =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr
+  nickname   =  ( letter / special ) *8( letter / digit / special / "-" )
+  targetmask =  ( "$" / "#" ) mask
+                  ; see details on allowed masks in section 3.3.1
+  chanstring =  %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
+  chanstring =/ %x2D-39 / %x3B-FF
+                  ; any octet except NUL, BELL, CR, LF, " ", "," and ":"
+  channelid  = 5( %x41-5A / digit )   ; 5( A-Z / 0-9 )
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                      [Page 7]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+  Other parameter syntaxes are:
+
+  user       =  1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
+                  ; any octet except NUL, CR, LF, " " and "@"
+  key        =  1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
+                  ; any 7-bit US_ASCII character,
+                  ; except NUL, CR, LF, FF, h/v TABs, and " "
+  letter     =  %x41-5A / %x61-7A       ; A-Z / a-z
+  digit      =  %x30-39                 ; 0-9
+  hexdigit   =  digit / "A" / "B" / "C" / "D" / "E" / "F"
+  special    =  %x5B-60 / %x7B-7D
+                   ; "[", "]", "\", "`", "_", "^", "{", "|", "}"
+
+  NOTES:
+      1) The <hostaddr> syntax is given here for the sole purpose of
+         indicating the format to follow for IP addresses.  This
+         reflects the fact that the only available implementations of
+         this protocol uses TCP/IP as underlying network protocol but is
+         not meant to prevent other protocols to be used.
+
+      2) <hostname> has a maximum length of 63 characters.  This is a
+         limitation of the protocol as internet hostnames (in
+         particular) can be longer.  Such restriction is necessary
+         because IRC messages are limited to 512 characters in length.
+         Clients connecting from a host which name is longer than 63
+         characters are registered using the host (numeric) address
+         instead of the host name.
+
+      3) Some parameters used in the following sections of this
+         documents are not defined here as there is nothing specific
+         about them besides the name that is used for convenience.
+         These parameters follow the general syntax defined for
+         <params>.
+
+2.4 Numeric replies
+
+   Most of the messages sent to the server generate a reply of some
+   sort.  The most common reply is the numeric reply, used for both
+   errors and normal replies.  The numeric reply MUST be sent as one
+   message consisting of the sender prefix, the three-digit numeric, and
+   the target of the reply.  A numeric reply is not allowed to originate
+   from a client. In all other respects, a numeric reply is just like a
+   normal message, except that the keyword is made up of 3 numeric
+   digits rather than a string of letters.  A list of different replies
+   is supplied in section 5 (Replies).
+
+
+
+
+
+
+Kalt                         Informational                      [Page 8]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+2.5 Wildcard expressions
+
+   When wildcards are allowed in a string, it is referred as a "mask".
+
+   For string matching purposes, the protocol allows the use of two
+   special characters: '?' (%x3F) to match one and only one character,
+   and '*' (%x2A) to match any number of any characters.  These two
+   characters can be escaped using the character '\' (%x5C).
+
+   The Augmented BNF syntax for this is:
+
+    mask       =  *( nowild / noesc wildone / noesc wildmany )
+    wildone    =  %x3F
+    wildmany   =  %x2A
+    nowild     =  %x01-29 / %x2B-3E / %x40-FF
+                    ; any octet except NUL, "*", "?"
+    noesc      =  %x01-5B / %x5D-FF
+                    ; any octet except NUL and "\"
+    matchone   =  %x01-FF
+                    ; matches wildone
+    matchmany  =  *matchone
+                    ; matches wildmany
+
+   Examples:
+
+   a?c         ; Matches any string of 3 characters in length starting
+               with "a" and ending with "c"
+
+   a*c         ; Matches any string of at least 2 characters in length
+               starting with "a" and ending with "c"
+
+3. Message Details
+
+   On the following pages there are descriptions of each message
+   recognized by the IRC server and client.  All commands described in
+   this section MUST be implemented by any server for this protocol.
+
+   Where the reply ERR_NOSUCHSERVER is returned, it means that the
+   target of the message could not be found.  The server MUST NOT send
+   any other replies after this error for that command.
+
+   The server to which a client is connected is required to parse the
+   complete message, and return any appropriate errors.
+
+   If multiple parameters is presented, then each MUST be checked for
+   validity and appropriate responses MUST be sent back to the client.
+   In the case of incorrect messages which use parameter lists with
+   comma as an item separator, a reply MUST be sent for each item.
+
+
+
+Kalt                         Informational                      [Page 9]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.1 Connection Registration
+
+   The commands described here are used to register a connection with an
+   IRC server as a user as well as to correctly disconnect.
+
+   A "PASS" command is not required for a client connection to be
+   registered, but it MUST precede the latter of the NICK/USER
+   combination (for a user connection) or the SERVICE command (for a
+   service connection). The RECOMMENDED order for a client to register
+   is as follows:
+
+                           1. Pass message
+           2. Nick message                 2. Service message
+           3. User message
+
+   Upon success, the client will receive an RPL_WELCOME (for users) or
+   RPL_YOURESERVICE (for services) message indicating that the
+   connection is now registered and known the to the entire IRC network.
+   The reply message MUST contain the full client identifier upon which
+   it was registered.
+
+3.1.1 Password message
+
+      Command: PASS
+   Parameters: <password>
+
+   The PASS command is used to set a 'connection password'.  The
+   optional password can and MUST be set before any attempt to register
+   the connection is made.  Currently this requires that user send a
+   PASS command before sending the NICK/USER combination.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED
+
+   Example:
+
+           PASS secretpasswordhere
+
+3.1.2 Nick message
+
+
+      Command: NICK
+   Parameters: <nickname>
+
+   NICK command is used to give user a nickname or change the existing
+   one.
+
+
+
+
+Kalt                         Informational                     [Page 10]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Numeric Replies:
+
+           ERR_NONICKNAMEGIVEN             ERR_ERRONEUSNICKNAME
+           ERR_NICKNAMEINUSE               ERR_NICKCOLLISION
+           ERR_UNAVAILRESOURCE             ERR_RESTRICTED
+
+   Examples:
+
+   NICK Wiz                ; Introducing new nick "Wiz" if session is
+                           still unregistered, or user changing his
+                           nickname to "Wiz"
+
+   :WiZ!jto@tolsun.oulu.fi NICK Kilroy
+                           ; Server telling that WiZ changed his
+                           nickname to Kilroy.
+
+3.1.3 User message
+
+      Command: USER
+   Parameters: <user> <mode> <unused> <realname>
+
+   The USER command is used at the beginning of connection to specify
+   the username, hostname and realname of a new user.
+
+   The <mode> parameter should be a numeric, and can be used to
+   automatically set user modes when registering with the server.  This
+   parameter is a bitmask, with only 2 bits having any signification: if
+   the bit 2 is set, the user mode 'w' will be set and if the bit 3 is
+   set, the user mode 'i' will be set.  (See Section 3.1.5 "User
+   Modes").
+
+   The <realname> may contain space characters.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED
+
+   Example:
+
+   USER guest 0 * :Ronnie Reagan   ; User registering themselves with a
+                                   username of "guest" and real name
+                                   "Ronnie Reagan".
+
+   USER guest 8 * :Ronnie Reagan   ; User registering themselves with a
+                                   username of "guest" and real name
+                                   "Ronnie Reagan", and asking to be set
+                                   invisible.
+
+
+
+
+Kalt                         Informational                     [Page 11]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.1.4 Oper message
+
+      Command: OPER
+   Parameters: <name> <password>
+
+   A normal user uses the OPER command to obtain operator privileges.
+   The combination of <name> and <password> are REQUIRED to gain
+   Operator privileges.  Upon success, the user will receive a MODE
+   message (see section 3.1.5) indicating the new user modes.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              RPL_YOUREOPER
+           ERR_NOOPERHOST                  ERR_PASSWDMISMATCH
+
+   Example:
+
+   OPER foo bar                    ; Attempt to register as an operator
+                                   using a username of "foo" and "bar"
+                                   as the password.
+
+3.1.5 User mode message
+
+      Command: MODE
+   Parameters: <nickname>
+               *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
+
+   The user MODE's are typically changes which affect either how the
+   client is seen by others or what 'extra' messages the client is sent.
+
+   A user MODE command MUST only be accepted if both the sender of the
+   message and the nickname given as a parameter are both the same.  If
+   no other parameter is given, then the server will return the current
+   settings for the nick.
+
+      The available modes are as follows:
+
+           a - user is flagged as away;
+           i - marks a users as invisible;
+           w - user receives wallops;
+           r - restricted user connection;
+           o - operator flag;
+           O - local operator flag;
+           s - marks a user for receipt of server notices.
+
+   Additional modes may be available later on.
+
+
+
+
+
+Kalt                         Informational                     [Page 12]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   The flag 'a' SHALL NOT be toggled by the user using the MODE command,
+   instead use of the AWAY command is REQUIRED.
+
+   If a user attempts to make themselves an operator using the "+o" or
+   "+O" flag, the attempt SHOULD be ignored as users could bypass the
+   authentication mechanisms of the OPER command.  There is no
+   restriction, however, on anyone `deopping' themselves (using "-o" or
+   "-O").
+
+   On the other hand, if a user attempts to make themselves unrestricted
+   using the "-r" flag, the attempt SHOULD be ignored.  There is no
+   restriction, however, on anyone `deopping' themselves (using "+r").
+   This flag is typically set by the server upon connection for
+   administrative reasons.  While the restrictions imposed are left up
+   to the implementation, it is typical that a restricted user not be
+   allowed to change nicknames, nor make use of the channel operator
+   status on channels.
+
+   The flag 's' is obsolete but MAY still be used.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_USERSDONTMATCH
+           ERR_UMODEUNKNOWNFLAG            RPL_UMODEIS
+
+   Examples:
+
+   MODE WiZ -w                     ; Command by WiZ to turn off
+                                   reception of WALLOPS messages.
+
+   MODE Angel +i                   ; Command from Angel to make herself
+                                   invisible.
+
+   MODE WiZ -o                     ; WiZ 'deopping' (removing operator
+                                   status).
+
+3.1.6 Service message
+
+      Command: SERVICE
+   Parameters: <nickname> <reserved> <distribution> <type>
+               <reserved> <info>
+
+   The SERVICE command to register a new service.  Command parameters
+   specify the service nickname, distribution, type and info of a new
+   service.
+
+
+
+
+
+
+Kalt                         Informational                     [Page 13]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   The <distribution> parameter is used to specify the visibility of a
+   service.  The service may only be known to servers which have a name
+   matching the distribution.  For a matching server to have knowledge
+   of the service, the network path between that server and the server
+   on which the service is connected MUST be composed of servers which
+   names all match the mask.
+
+   The <type> parameter is currently reserved for future usage.
+
+   Numeric Replies:
+
+           ERR_ALREADYREGISTRED            ERR_NEEDMOREPARAMS
+           ERR_ERRONEUSNICKNAME
+           RPL_YOURESERVICE                RPL_YOURHOST
+           RPL_MYINFO
+
+   Example:
+
+   SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering
+                                   itself with a name of "dict".  This
+                                   service will only be available on
+                                   servers which name matches "*.fr".
+
+3.1.7 Quit
+
+      Command: QUIT
+   Parameters: [ <Quit Message> ]
+
+   A client session is terminated with a quit message.  The server
+   acknowledges this by sending an ERROR message to the client.
+
+   Numeric Replies:
+
+           None.
+
+   Example:
+
+   QUIT :Gone to have lunch        ; Preferred message format.
+
+   :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User
+                                   syrk has quit IRC to have lunch.
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 14]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.1.8 Squit
+
+      Command: SQUIT
+   Parameters: <server> <comment>
+
+   The SQUIT command is available only to operators.  It is used to
+   disconnect server links.  Also servers can generate SQUIT messages on
+   error conditions.  A SQUIT message may also target a remote server
+   connection.  In this case, the SQUIT message will simply be sent to
+   the remote server without affecting the servers in between the
+   operator and the remote server.
+
+   The <comment> SHOULD be supplied by all operators who execute a SQUIT
+   for a remote server.  The server ordered to disconnect its peer
+   generates a WALLOPS message with <comment> included, so that other
+   users may be aware of the reason of this action.
+
+   Numeric replies:
+
+           ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
+           ERR_NEEDMOREPARAMS
+
+   Examples:
+
+   SQUIT tolsun.oulu.fi :Bad Link ?  ; Command to uplink of the server
+                                   tolson.oulu.fi to terminate its
+                                   connection with comment "Bad Link".
+
+   :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
+                                   from Trillian from to disconnect
+                                   "cm22.eng.umd.edu" from the net with
+                                   comment "Server out of control".
+
+3.2 Channel operations
+
+   This group of messages is concerned with manipulating channels, their
+   properties (channel modes), and their contents (typically users).
+   For this reason, these messages SHALL NOT be made available to
+   services.
+
+   All of these messages are requests which will or will not be granted
+   by the server.  The server MUST send a reply informing the user
+   whether the request was granted, denied or generated an error.  When
+   the server grants the request, the message is typically sent back
+   (eventually reformatted) to the user with the prefix set to the user
+   itself.
+
+
+
+
+
+Kalt                         Informational                     [Page 15]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   The rules governing how channels are managed are enforced by the
+   servers.  These rules are beyond the scope of this document.  More
+   details are found in "Internet Relay Chat: Channel Management" [IRC-
+   CHAN].
+
+3.2.1 Join message
+
+      Command: JOIN
+   Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
+               / "0"
+
+   The JOIN command is used by a user to request to start listening to
+   the specific channel.  Servers MUST be able to parse arguments in the
+   form of a list of target, but SHOULD NOT use lists when sending JOIN
+   messages to clients.
+
+   Once a user has joined a channel, he receives information about
+   all commands his server receives affecting the channel.  This
+   includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.
+   This allows channel members to keep track of the other channel
+   members, as well as channel modes.
+
+   If a JOIN is successful, the user receives a JOIN message as
+   confirmation and is then sent the channel's topic (using RPL_TOPIC) and
+   the list of users who are on the channel (using RPL_NAMREPLY), which
+   MUST include the user joining.
+
+   Note that this message accepts a special argument ("0"), which is
+   a special request to leave all channels the user is currently a member
+   of.  The server will process this message as if the user had sent
+   a PART command (See Section 3.2.2) for each channel he is a member
+   of.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
+           ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
+           ERR_CHANNELISFULL               ERR_BADCHANMASK
+           ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
+           ERR_TOOMANYTARGETS              ERR_UNAVAILRESOURCE
+           RPL_TOPIC
+
+   Examples:
+
+   JOIN #foobar                    ; Command to join channel #foobar.
+
+   JOIN &foo fubar                 ; Command to join channel &foo using
+                                   key "fubar".
+
+
+
+Kalt                         Informational                     [Page 16]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   JOIN #foo,&bar fubar            ; Command to join channel #foo using
+                                   key "fubar" and &bar using no key.
+
+   JOIN #foo,#bar fubar,foobar     ; Command to join channel #foo using
+                                   key "fubar", and channel #bar using
+                                   key "foobar".
+
+   JOIN #foo,#bar                  ; Command to join channels #foo and
+                                   #bar.
+
+   JOIN 0                          ; Leave all currently joined
+                                   channels.
+
+   :WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ
+                                   on channel #Twilight_zone
+
+3.2.2 Part message
+
+      Command: PART
+   Parameters: <channel> *( "," <channel> ) [ <Part Message> ]
+
+   The PART command causes the user sending the message to be removed
+   from the list of active members for all given channels listed in the
+   parameter string.  If a "Part Message" is given, this will be sent
+   instead of the default message, the nickname.  This request is always
+   granted by the server.
+
+   Servers MUST be able to parse arguments in the form of a list of
+   target, but SHOULD NOT use lists when sending PART messages to
+   clients.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
+           ERR_NOTONCHANNEL
+
+   Examples:
+
+   PART #twilight_zone             ; Command to leave channel
+                                   "#twilight_zone"
+
+   PART #oz-ops,&group5            ; Command to leave both channels
+                                   "&group5" and "#oz-ops".
+
+   :WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
+                                   ; User WiZ leaving channel
+                                   "#playzone" with the message "I
+                                   lost".
+
+
+
+Kalt                         Informational                     [Page 17]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.2.3 Channel mode message
+
+      Command: MODE
+   Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
+
+   The MODE command is provided so that users may query and change the
+   characteristics of a channel.  For more details on available modes
+   and their uses, see "Internet Relay Chat: Channel Management" [IRC-
+   CHAN].  Note that there is a maximum limit of three (3) changes per
+   command for modes that take a parameter.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_KEYSET
+           ERR_NOCHANMODES                 ERR_CHANOPRIVSNEEDED
+           ERR_USERNOTINCHANNEL            ERR_UNKNOWNMODE
+           RPL_CHANNELMODEIS
+           RPL_BANLIST                     RPL_ENDOFBANLIST
+           RPL_EXCEPTLIST                  RPL_ENDOFEXCEPTLIST
+           RPL_INVITELIST                  RPL_ENDOFINVITELIST
+           RPL_UNIQOPIS
+
+   The following examples are given to help understanding the syntax of
+   the MODE command, but refer to modes defined in "Internet Relay Chat:
+   Channel Management" [IRC-CHAN].
+
+   Examples:
+
+   MODE #Finnish +imI *!*@*.fi     ; Command to make #Finnish channel
+                                   moderated and 'invite-only' with user
+                                   with a hostname matching *.fi
+                                   automatically invited.
+
+   MODE #Finnish +o Kilroy         ; Command to give 'chanop' privileges
+                                   to Kilroy on channel #Finnish.
+
+   MODE #Finnish +v Wiz            ; Command to allow WiZ to speak on
+                                   #Finnish.
+
+   MODE #Fins -s                   ; Command to remove 'secret' flag
+                                   from channel #Fins.
+
+   MODE #42 +k oulu                ; Command to set the channel key to
+                                   "oulu".
+
+   MODE #42 -k oulu                ; Command to remove the "oulu"
+                                   channel key on channel "#42".
+
+
+
+
+Kalt                         Informational                     [Page 18]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   MODE #eu-opers +l 10            ; Command to set the limit for the
+                                   number of users on channel
+                                   "#eu-opers" to 10.
+
+   :WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
+                                   ; User "WiZ" removing the limit for
+                                   the number of users on channel "#eu-
+                                   opers".
+
+   MODE &oulu +b                   ; Command to list ban masks set for
+                                   the channel "&oulu".
+
+   MODE &oulu +b *!*@*             ; Command to prevent all users from
+                                   joining.
+
+   MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu
+                                   ; Command to prevent any user from a
+                                   hostname matching *.edu from joining,
+                                   except if matching *.bu.edu
+
+   MODE #bu +be *!*@*.edu *!*@*.bu.edu
+                                   ; Comment to prevent any user from a
+                                   hostname matching *.edu from joining,
+                                   except if matching *.bu.edu
+
+   MODE #meditation e              ; Command to list exception masks set
+                                   for the channel "#meditation".
+
+   MODE #meditation I              ; Command to list invitations masks
+                                   set for the channel "#meditation".
+
+   MODE !12345ircd O               ; Command to ask who the channel
+                                   creator for "!12345ircd" is
+
+3.2.4 Topic message
+
+      Command: TOPIC
+   Parameters: <channel> [ <topic> ]
+
+   The TOPIC command is used to change or view the topic of a channel.
+   The topic for channel <channel> is returned if there is no <topic>
+   given.  If the <topic> parameter is present, the topic for that
+   channel will be changed, if this action is allowed for the user
+   requesting it.  If the <topic> parameter is an empty string, the
+   topic for that channel will be removed.
+
+
+
+
+
+
+Kalt                         Informational                     [Page 19]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_NOTONCHANNEL
+           RPL_NOTOPIC                     RPL_TOPIC
+           ERR_CHANOPRIVSNEEDED            ERR_NOCHANMODES
+
+   Examples:
+
+   :WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
+                                   topic.
+
+   TOPIC #test :another topic      ; Command to set the topic on #test
+                                   to "another topic".
+
+   TOPIC #test :                   ; Command to clear the topic on
+                                   #test.
+
+   TOPIC #test                     ; Command to check the topic for
+                                   #test.
+
+3.2.5 Names message
+
+      Command: NAMES
+   Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
+
+   By using the NAMES command, a user can list all nicknames that are
+   visible to him. For more details on what is visible and what is not,
+   see "Internet Relay Chat: Channel Management" [IRC-CHAN].  The
+   <channel> parameter specifies which channel(s) to return information
+   about.  There is no error reply for bad channel names.
+
+   If no <channel> parameter is given, a list of all channels and their
+   occupants is returned.  At the end of this list, a list of users who
+   are visible but either not on any channel or not on a visible channel
+   are listed as being on `channel' "*".
+
+   If the <target> parameter is specified, the request is forwarded to
+   that server which will generate the reply.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numerics:
+
+           ERR_TOOMANYMATCHES              ERR_NOSUCHSERVER
+           RPL_NAMREPLY                    RPL_ENDOFNAMES
+
+
+
+
+
+
+Kalt                         Informational                     [Page 20]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   NAMES #twilight_zone,#42        ; Command to list visible users on
+                                   #twilight_zone and #42
+
+   NAMES                           ; Command to list all visible
+                                   channels and users
+
+3.2.6 List message
+
+      Command: LIST
+   Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
+
+   The list command is used to list channels and their topics.  If the
+   <channel> parameter is used, only the status of that channel is
+   displayed.
+
+   If the <target> parameter is specified, the request is forwarded to
+   that server which will generate the reply.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_TOOMANYMATCHES              ERR_NOSUCHSERVER
+           RPL_LIST                        RPL_LISTEND
+
+   Examples:
+
+   LIST                            ; Command to list all channels.
+
+   LIST #twilight_zone,#42         ; Command to list channels
+                                   #twilight_zone and #42
+
+3.2.7 Invite message
+
+      Command: INVITE
+   Parameters: <nickname> <channel>
+
+   The INVITE command is used to invite a user to a channel.  The
+   parameter <nickname> is the nickname of the person to be invited to
+   the target channel <channel>.  There is no requirement that the
+   channel the target user is being invited to must exist or be a valid
+   channel.  However, if the channel exists, only members of the channel
+   are allowed to invite other users.  When the channel has invite-only
+   flag set, only channel operators may issue INVITE command.
+
+
+
+
+
+Kalt                         Informational                     [Page 21]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Only the user inviting and the user being invited will receive
+   notification of the invitation.  Other channel members are not
+   notified.  (This is unlike the MODE changes, and is occasionally the
+   source of trouble for users.)
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_NOSUCHNICK
+           ERR_NOTONCHANNEL                ERR_USERONCHANNEL
+           ERR_CHANOPRIVSNEEDED
+           RPL_INVITING                    RPL_AWAY
+
+   Examples:
+
+   :Angel!wings@irc.org INVITE Wiz #Dust
+
+                                   ; Message to WiZ when he has been
+                                   invited by user Angel to channel
+                                   #Dust
+
+   INVITE Wiz #Twilight_Zone       ; Command to invite WiZ to
+                                   #Twilight_zone
+
+3.2.8 Kick command
+
+      Command: KICK
+   Parameters: <channel> *( "," <channel> ) <user> *( "," <user> )
+               [<comment>]
+
+   The KICK command can be used to request the forced removal of a user
+   from a channel.  It causes the <user> to PART from the <channel> by
+   force.  For the message to be syntactically correct, there MUST be
+   either one channel parameter and multiple user parameter, or as many
+   channel parameters as there are user parameters.  If a "comment" is
+   given, this will be sent instead of the default message, the nickname
+   of the user issuing the KICK.
+
+   The server MUST NOT send KICK messages with multiple channels or
+   users to clients.  This is necessarily to maintain backward
+   compatibility with old client software.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
+           ERR_BADCHANMASK                 ERR_CHANOPRIVSNEEDED
+           ERR_USERNOTINCHANNEL            ERR_NOTONCHANNEL
+
+
+
+
+
+Kalt                         Informational                     [Page 22]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   KICK &Melbourne Matthew         ; Command to kick Matthew from
+                                   &Melbourne
+
+   KICK #Finnish John :Speaking English
+                                   ; Command to kick John from #Finnish
+                                   using "Speaking English" as the
+                                   reason (comment).
+
+   :WiZ!jto@tolsun.oulu.fi KICK #Finnish John
+                                   ; KICK message on channel #Finnish
+                                   from WiZ to remove John from channel
+
+3.3 Sending messages
+
+   The main purpose of the IRC protocol is to provide a base for clients
+   to communicate with each other.  PRIVMSG, NOTICE and SQUERY
+   (described in Section 3.5 on Service Query and Commands) are the only
+   messages available which actually perform delivery of a text message
+   from one client to another - the rest just make it possible and try
+   to ensure it happens in a reliable and structured manner.
+
+3.3.1 Private messages
+
+      Command: PRIVMSG
+   Parameters: <msgtarget> <text to be sent>
+
+   PRIVMSG is used to send private messages between users, as well as to
+   send messages to channels.  <msgtarget> is usually the nickname of
+   the recipient of the message, or a channel name.
+
+   The <msgtarget> parameter may also be a host mask (#<mask>) or server
+   mask ($<mask>).  In both cases the server will only send the PRIVMSG
+   to those who have a server or host matching the mask.  The mask MUST
+   have at least 1 (one) "." in it and no wildcards following the last
+   ".".  This requirement exists to prevent people sending messages to
+   "#*" or "$*", which would broadcast to all users.  Wildcards are the
+   '*' and '?'  characters.  This extension to the PRIVMSG command is
+   only available to operators.
+
+   Numeric Replies:
+
+           ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
+           ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
+           ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
+           ERR_NOSUCHNICK
+           RPL_AWAY
+
+
+
+Kalt                         Informational                     [Page 23]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
+                                   ; Message from Angel to Wiz.
+
+   PRIVMSG Angel :yes I'm receiving it !
+                                   ; Command to send a message to Angel.
+
+   PRIVMSG jto@tolsun.oulu.fi :Hello !
+                                   ; Command to send a message to a user
+                                   on server tolsun.oulu.fi with
+                                   username of "jto".
+
+   PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog?
+                                   ; Message to a user on server
+                                   irc.stealth.net with username of
+                                   "kalt", and connected from the host
+                                   millennium.stealth.net.
+
+   PRIVMSG kalt%millennium.stealth.net :Do you like cheese?
+                                   ; Message to a user on the local
+                                   server with username of "kalt", and
+                                   connected from the host
+                                   millennium.stealth.net.
+
+   PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
+                                   ; Message to the user with nickname
+                                   Wiz who is connected from the host
+                                   tolsun.oulu.fi and has the username
+                                   "jto".
+
+   PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
+                                   ; Message to everyone on a server
+                                   which has a name matching *.fi.
+
+   PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
+                                   ; Message to all users who come from
+                                   a host which has a name matching
+                                   *.edu.
+
+3.3.2 Notice
+
+      Command: NOTICE
+   Parameters: <msgtarget> <text>
+
+   The NOTICE command is used similarly to PRIVMSG.  The difference
+   between NOTICE and PRIVMSG is that automatic replies MUST NEVER be
+   sent in response to a NOTICE message.  This rule applies to servers
+
+
+
+Kalt                         Informational                     [Page 24]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   too - they MUST NOT send any error reply back to the client on
+   receipt of a notice.  The object of this rule is to avoid loops
+   between clients automatically sending something in response to
+   something it received.
+
+   This command is available to services as well as users.
+
+   This is typically used by services, and automatons (clients with
+   either an AI or other interactive program controlling their actions).
+
+   See PRIVMSG for more details on replies and examples.
+
+3.4 Server queries and commands
+
+   The server query group of commands has been designed to return
+   information about any server which is connected to the network.
+
+   In these queries, where a parameter appears as <target>, wildcard
+   masks are usually valid.  For each parameter, however, only one query
+   and set of replies is to be generated.  In most cases, if a nickname
+   is given, it will mean the server to which the user is connected.
+
+   These messages typically have little value for services, it is
+   therefore RECOMMENDED to forbid services from using them.
+
+3.4.1 Motd message
+
+      Command: MOTD
+   Parameters: [ <target> ]
+
+   The MOTD command is used to get the "Message Of The Day" of the given
+   server, or current server if <target> is omitted.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+           RPL_MOTDSTART                   RPL_MOTD
+           RPL_ENDOFMOTD                   ERR_NOMOTD
+
+3.4.2 Lusers message
+
+      Command: LUSERS
+   Parameters: [ <mask> [ <target> ] ]
+
+   The LUSERS command is used to get statistics about the size of the
+   IRC network.  If no parameter is given, the reply will be about the
+   whole net.  If a <mask> is specified, then the reply will only
+
+
+
+
+Kalt                         Informational                     [Page 25]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   concern the part of the network formed by the servers matching the
+   mask.  Finally, if the <target> parameter is specified, the request
+   is forwarded to that server which will generate the reply.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           RPL_LUSERCLIENT                 RPL_LUSEROP
+           RPL_LUSERUNKOWN                 RPL_LUSERCHANNELS
+           RPL_LUSERME                     ERR_NOSUCHSERVER
+
+3.4.3 Version message
+
+      Command: VERSION
+   Parameters: [ <target> ]
+
+   The VERSION command is used to query the version of the server
+   program.  An optional parameter <target> is used to query the version
+   of the server program which a client is not directly connected to.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER                RPL_VERSION
+
+   Examples:
+
+   VERSION tolsun.oulu.fi          ; Command to check the version of
+                                   server "tolsun.oulu.fi".
+
+3.4.4 Stats message
+
+      Command: STATS
+   Parameters: [ <query> [ <target> ] ]
+
+   The stats command is used to query statistics of certain server.  If
+   <query> parameter is omitted, only the end of stats reply is sent
+   back.
+
+   A query may be given for any single letter which is only checked by
+   the destination server and is otherwise passed on by intermediate
+   servers, ignored and unaltered.
+
+   Wildcards are allowed in the <target> parameter.
+
+
+
+
+
+Kalt                         Informational                     [Page 26]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Except for the ones below, the list of valid queries is
+   implementation dependent.  The standard queries below SHOULD be
+   supported by the server:
+
+            l - returns a list of the server's connections, showing how
+                long each connection has been established and the
+                traffic over that connection in Kbytes and messages for
+                each direction;
+            m - returns the usage count for each of commands supported
+                by the server; commands for which the usage count is
+                zero MAY be omitted;
+            o - returns a list of configured privileged users,
+                operators;
+            u - returns a string showing how long the server has been
+                up.
+
+   It is also RECOMMENDED that client and server access configuration be
+   published this way.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER
+           RPL_STATSLINKINFO                RPL_STATSUPTIME
+           RPL_STATSCOMMANDS                RPL_STATSOLINE
+           RPL_ENDOFSTATS
+
+   Examples:
+
+   STATS m                         ; Command to check the command usage
+                                   for the server you are connected to
+
+3.4.5 Links message
+
+      Command: LINKS
+   Parameters: [ [ <remote server> ] <server mask> ]
+
+   With LINKS, a user can list all servernames, which are known by the
+   server answering the query.  The returned list of servers MUST match
+   the mask, or if no mask is given, the full list is returned.
+
+   If <remote server> is given in addition to <server mask>, the LINKS
+   command is forwarded to the first server found that matches that name
+   (if any), and that server is then required to answer the query.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER
+           RPL_LINKS                        RPL_ENDOFLINKS
+
+
+
+Kalt                         Informational                     [Page 27]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   LINKS *.au                      ; Command to list all servers which
+                                   have a name that matches *.au;
+
+   LINKS *.edu *.bu.edu            ; Command to list servers matching
+                                   *.bu.edu as seen by the first server
+                                   matching *.edu.
+
+3.4.6 Time message
+
+      Command: TIME
+   Parameters: [ <target> ]
+
+   The time command is used to query local time from the specified
+   server. If the <target> parameter is not given, the server receiving
+   the command must reply to the query.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER              RPL_TIME
+
+   Examples:
+   TIME tolsun.oulu.fi             ; check the time on the server
+                                   "tolson.oulu.fi"
+
+3.4.7 Connect message
+
+      Command: CONNECT
+   Parameters: <target server> <port> [ <remote server> ]
+
+   The CONNECT command can be used to request a server to try to
+   establish a new connection to another server immediately.  CONNECT is
+   a privileged command and SHOULD be available only to IRC Operators.
+   If a <remote server> is given and its mask doesn't match name of the
+   parsing server, the CONNECT attempt is sent to the first match of
+   remote server. Otherwise the CONNECT attempt is made by the server
+   processing the request.
+
+   The server receiving a remote CONNECT command SHOULD generate a
+   WALLOPS message describing the source and target of the request.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER              ERR_NOPRIVILEGES
+           ERR_NEEDMOREPARAMS
+
+
+
+Kalt                         Informational                     [Page 28]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   CONNECT tolsun.oulu.fi 6667     ; Command to attempt to connect local
+                                   server to tolsun.oulu.fi on port 6667
+
+3.4.8 Trace message
+
+      Command: TRACE
+   Parameters: [ <target> ]
+
+   TRACE command is used to find the route to specific server and
+   information about its peers.  Each server that processes this command
+   MUST report to the sender about it.  The replies from pass-through
+   links form a chain, which shows route to destination.  After sending
+   this reply back, the query MUST be sent to the next server until
+   given <target> server is reached.
+
+   TRACE command is used to find the route to specific server.  Each
+   server that processes this message MUST tell the sender about it by
+   sending a reply indicating it is a pass-through link, forming a chain
+   of replies.  After sending this reply back, it MUST then send the
+   TRACE message to the next server until given server is reached.  If
+   the <target> parameter is omitted, it is RECOMMENDED that TRACE
+   command sends a message to the sender telling which servers the local
+   server has direct connection to.
+
+   If the destination given by <target> is an actual server, the
+   destination server is REQUIRED to report all servers, services and
+   operators which are connected to it; if the command was issued by an
+   operator, the server MAY also report all users which are connected to
+   it.  If the destination given by <target> is a nickname, then only a
+   reply for that nickname is given.  If the <target> parameter is
+   omitted, it is RECOMMENDED that the TRACE command is parsed as
+   targeted to the processing server.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER
+
+      If the TRACE message is destined for another server, all
+      intermediate servers must return a RPL_TRACELINK reply to indicate
+      that the TRACE passed through it and where it is going next.
+
+           RPL_TRACELINK
+
+
+
+
+
+Kalt                         Informational                     [Page 29]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+      A TRACE reply may be composed of any number of the following
+      numeric replies.
+
+           RPL_TRACECONNECTING           RPL_TRACEHANDSHAKE
+           RPL_TRACEUNKNOWN              RPL_TRACEOPERATOR
+           RPL_TRACEUSER                 RPL_TRACESERVER
+           RPL_TRACESERVICE              RPL_TRACENEWTYPE
+           RPL_TRACECLASS                RPL_TRACELOG
+           RPL_TRACEEND
+
+   Examples:
+
+   TRACE *.oulu.fi                 ; TRACE to a server matching
+                                   *.oulu.fi
+
+3.4.9 Admin command
+
+      Command: ADMIN
+   Parameters: [ <target> ]
+
+   The admin command is used to find information about the administrator
+   of the given server, or current server if <target> parameter is
+   omitted.  Each server MUST have the ability to forward ADMIN messages
+   to other servers.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER
+           RPL_ADMINME                   RPL_ADMINLOC1
+           RPL_ADMINLOC2                 RPL_ADMINEMAIL
+
+   Examples:
+
+   ADMIN tolsun.oulu.fi            ; request an ADMIN reply from
+                                   tolsun.oulu.fi
+
+   ADMIN syrk                      ; ADMIN request for the server to
+                                   which the user syrk is connected
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 30]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.4.10 Info command
+
+      Command: INFO
+   Parameters: [ <target> ]
+
+   The INFO command is REQUIRED to return information describing the
+   server: its version, when it was compiled, the patchlevel, when it
+   was started, and any other miscellaneous information which may be
+   considered to be relevant.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER
+           RPL_INFO                      RPL_ENDOFINFO
+
+   Examples:
+
+   INFO csd.bu.edu                 ; request an INFO reply from
+                                   csd.bu.edu
+
+   INFO Angel                      ; request info from the server that
+                                   Angel is connected to.
+
+3.5 Service Query and Commands
+
+   The service query group of commands has been designed to return
+   information about any service which is connected to the network.
+
+3.5.1 Servlist message
+
+      Command: SERVLIST
+   Parameters: [ <mask> [ <type> ] ]
+
+   The SERVLIST command is used to list services currently connected to
+   the network and visible to the user issuing the command.  The
+   optional parameters may be used to restrict the result of the query
+   (to matching services names, and services type).
+
+   Numeric Replies:
+
+           RPL_SERVLIST                  RPL_SERVLISTEND
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 31]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.5.2 Squery
+
+      Command: SQUERY
+   Parameters: <servicename> <text>
+
+   The SQUERY command is used similarly to PRIVMSG.  The only difference
+   is that the recipient MUST be a service.  This is the only way for a
+   text message to be delivered to a service.
+
+   See PRIVMSG for more details on replies and example.
+
+   Examples:
+
+   SQUERY irchelp :HELP privmsg
+                                   ; Message to the service with
+                                   nickname irchelp.
+
+   SQUERY dict@irc.fr :fr2en blaireau
+                                   ; Message to the service with name
+                                   dict@irc.fr.
+
+3.6 User based queries
+
+   User queries are a group of commands which are primarily concerned
+   with finding details on a particular user or group users.  When using
+   wildcards with any of these commands, if they match, they will only
+   return information on users who are 'visible' to you.  The visibility
+   of a user is determined as a combination of the user's mode and the
+   common set of channels you are both on.
+
+   Although services SHOULD NOT be using this class of message, they are
+   allowed to.
+
+3.6.1 Who query
+
+      Command: WHO
+   Parameters: [ <mask> [ "o" ] ]
+
+   The WHO command is used by a client to generate a query which returns
+   a list of information which 'matches' the <mask> parameter given by
+   the client.  In the absence of the <mask> parameter, all visible
+   (users who aren't invisible (user mode +i) and who don't have a
+   common channel with the requesting client) are listed.  The same
+   result can be achieved by using a <mask> of "0" or any wildcard which
+   will end up matching every visible user.
+
+   The <mask> passed to WHO is matched against users' host, server, real
+   name and nickname if the channel <mask> cannot be found.
+
+
+
+Kalt                         Informational                     [Page 32]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   If the "o" parameter is passed only operators are returned according
+   to the <mask> supplied.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER
+           RPL_WHOREPLY                  RPL_ENDOFWHO
+
+   Examples:
+
+   WHO *.fi                        ; Command to list all users who match
+                                   against "*.fi".
+
+   WHO jto* o                      ; Command to list all users with a
+                                   match against "jto*" if they are an
+                                   operator.
+
+3.6.2 Whois query
+
+      Command: WHOIS
+   Parameters: [ <target> ] <mask> *( "," <mask> )
+
+   This command is used to query information about particular user.
+   The server will answer this command with several numeric messages
+   indicating different statuses of each user which matches the mask (if
+   you are entitled to see them).  If no wildcard is present in the
+   <mask>, any information about that nick which you are allowed to see
+   is presented.
+
+   If the <target> parameter is specified, it sends the query to a
+   specific server.  It is useful if you want to know how long the user
+   in question has been idle as only local server (i.e., the server the
+   user is directly connected to) knows that information, while
+   everything else is globally known.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER              ERR_NONICKNAMEGIVEN
+           RPL_WHOISUSER                 RPL_WHOISCHANNELS
+           RPL_WHOISCHANNELS             RPL_WHOISSERVER
+           RPL_AWAY                      RPL_WHOISOPERATOR
+           RPL_WHOISIDLE                 ERR_NOSUCHNICK
+           RPL_ENDOFWHOIS
+
+
+
+
+
+
+Kalt                         Informational                     [Page 33]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   WHOIS wiz                       ; return available user information
+                                   about nick WiZ
+
+   WHOIS eff.org trillian          ; ask server eff.org for user
+                                   information  about trillian
+
+3.6.3 Whowas
+
+      Command: WHOWAS
+   Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
+
+   Whowas asks for information about a nickname which no longer exists.
+   This may either be due to a nickname change or the user leaving IRC.
+   In response to this query, the server searches through its nickname
+   history, looking for any nicks which are lexically the same (no wild
+   card matching here).  The history is searched backward, returning the
+   most recent entry first.  If there are multiple entries, up to
+   <count> replies will be returned (or all of them if no <count>
+   parameter is given).  If a non-positive number is passed as being
+   <count>, then a full search is done.
+
+   Wildcards are allowed in the <target> parameter.
+
+   Numeric Replies:
+
+           ERR_NONICKNAMEGIVEN           ERR_WASNOSUCHNICK
+           RPL_WHOWASUSER                RPL_WHOISSERVER
+           RPL_ENDOFWHOWAS
+
+   Examples:
+
+   WHOWAS Wiz                      ; return all information in the nick
+                                   history about nick "WiZ";
+
+   WHOWAS Mermaid 9                ; return at most, the 9 most recent
+                                   entries in the nick history for
+                                   "Mermaid";
+
+   WHOWAS Trillian 1 *.edu         ; return the most recent history for
+                                   "Trillian" from the first server
+                                   found to match "*.edu".
+
+3.7 Miscellaneous messages
+
+   Messages in this category do not fit into any of the above categories
+   but are nonetheless still a part of and REQUIRED by the protocol.
+
+
+
+Kalt                         Informational                     [Page 34]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.7.1 Kill message
+
+      Command: KILL
+   Parameters: <nickname> <comment>
+
+   The KILL command is used to cause a client-server connection to be
+   closed by the server which has the actual connection.  Servers
+   generate KILL messages on nickname collisions.  It MAY also be
+   available available to users who have the operator status.
+
+   Clients which have automatic reconnect algorithms effectively make
+   this command useless since the disconnection is only brief.  It does
+   however break the flow of data and can be used to stop large amounts
+   of 'flooding' from abusive users or accidents.  Abusive users usually
+   don't care as they will reconnect promptly and resume their abusive
+   behaviour.  To prevent this command from being abused, any user may
+   elect to receive KILL messages generated for others to keep an 'eye'
+   on would be trouble spots.
+
+   In an arena where nicknames are REQUIRED to be globally unique at all
+   times, KILL messages are sent whenever 'duplicates' are detected
+   (that is an attempt to register two users with the same nickname) in
+   the hope that both of them will disappear and only 1 reappear.
+
+   When a client is removed as the result of a KILL message, the server
+   SHOULD add the nickname to the list of unavailable nicknames in an
+   attempt to avoid clients to reuse this name immediately which is
+   usually the pattern of abusive behaviour often leading to useless
+   "KILL loops".  See the "IRC Server Protocol" document [IRC-SERVER]
+   for more information on this procedure.
+
+   The comment given MUST reflect the actual reason for the KILL.  For
+   server-generated KILLs it usually is made up of details concerning
+   the origins of the two conflicting nicknames.  For users it is left
+   up to them to provide an adequate reason to satisfy others who see
+   it.  To prevent/discourage fake KILLs from being generated to hide
+   the identify of the KILLer, the comment also shows a 'kill-path'
+   which is updated by each server it passes through, each prepending
+   its name to the path.
+
+   Numeric Replies:
+
+           ERR_NOPRIVILEGES              ERR_NEEDMOREPARAMS
+           ERR_NOSUCHNICK                ERR_CANTKILLSERVER
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 35]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   NOTE:
+   It is RECOMMENDED that only Operators be allowed to kill other users
+   with KILL command.  This command has been the subject of many
+   controversies over the years, and along with the above
+   recommendation, it is also widely recognized that not even operators
+   should be allowed to kill users on remote servers.
+
+3.7.2 Ping message
+
+      Command: PING
+   Parameters: <server1> [ <server2> ]
+
+   The PING command is used to test the presence of an active client or
+   server at the other end of the connection.  Servers send a PING
+   message at regular intervals if no other activity detected coming
+   from a connection.  If a connection fails to respond to a PING
+   message within a set amount of time, that connection is closed.  A
+   PING message MAY be sent even if the connection is active.
+
+   When a PING message is received, the appropriate PONG message MUST be
+   sent as reply to <server1> (server which sent the PING message out)
+   as soon as possible.  If the <server2> parameter is specified, it
+   represents the target of the ping, and the message gets forwarded
+   there.
+
+   Numeric Replies:
+
+           ERR_NOORIGIN                  ERR_NOSUCHSERVER
+
+   Examples:
+
+   PING tolsun.oulu.fi             ; Command to send a PING message to
+                                   server
+
+   PING WiZ tolsun.oulu.fi         ; Command from WiZ to send a PING
+                                   message to server "tolsun.oulu.fi"
+
+   PING :irc.funet.fi              ; Ping message sent by server
+                                   "irc.funet.fi"
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 36]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+3.7.3 Pong message
+
+      Command: PONG
+   Parameters: <server> [ <server2> ]
+
+   PONG message is a reply to ping message.  If parameter <server2> is
+   given, this message MUST be forwarded to given target.  The <server>
+   parameter is the name of the entity who has responded to PING message
+   and generated this message.
+
+   Numeric Replies:
+
+           ERR_NOORIGIN                  ERR_NOSUCHSERVER
+
+   Example:
+
+   PONG csd.bu.edu tolsun.oulu.fi  ; PONG message from csd.bu.edu to
+                                   tolsun.oulu.fi
+
+3.7.4 Error
+
+      Command: ERROR
+   Parameters: <error message>
+
+   The ERROR command is for use by servers when reporting a serious or
+   fatal error to its peers.  It may also be sent from one server to
+   another but MUST NOT be accepted from any normal unknown clients.
+
+   Only an ERROR message SHOULD be used for reporting errors which occur
+   with a server-to-server link.  An ERROR message is sent to the server
+   at the other end (which reports it to appropriate local users and
+   logs) and to appropriate local users and logs.  It is not to be
+   passed onto any other servers by a server if it is received from a
+   server.
+
+   The ERROR message is also used before terminating a client
+   connection.
+
+   When a server sends a received ERROR message to its operators, the
+   message SHOULD be encapsulated inside a NOTICE message, indicating
+   that the client was not responsible for the error.
+
+   Numerics:
+
+           None.
+
+
+
+
+
+
+Kalt                         Informational                     [Page 37]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   ERROR :Server *.fi already exists ; ERROR message to the other server
+                                   which caused this error.
+
+   NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
+                                   ; Same ERROR message as above but
+                                   sent to user WiZ on the other server.
+
+4. Optional features
+
+   This section describes OPTIONAL messages.  They are not required in a
+   working server implementation of the protocol described herein.  In
+   the absence of the feature, an error reply message MUST be generated
+   or an unknown command error.  If the message is destined for another
+   server to answer then it MUST be passed on (elementary parsing
+   REQUIRED) The allocated numerics for this are listed with the
+   messages below.
+
+   From this section, only the USERHOST and ISON messages are available
+   to services.
+
+4.1 Away
+
+      Command: AWAY
+   Parameters: [ <text> ]
+
+   With the AWAY command, clients can set an automatic reply string for
+   any PRIVMSG commands directed at them (not to a channel they are on).
+   The server sends an automatic reply to the client sending the PRIVMSG
+   command.  The only replying server is the one to which the sending
+   client is connected to.
+
+   The AWAY command is used either with one parameter, to set an AWAY
+   message, or with no parameters, to remove the AWAY message.
+
+   Because of its high cost (memory and bandwidth wise), the AWAY
+   message SHOULD only be used for client-server communication.  A
+   server MAY choose to silently ignore AWAY messages received from
+   other servers.  To update the away status of a client across servers,
+   the user mode 'a' SHOULD be used instead.  (See Section 3.1.5)
+
+   Numeric Replies:
+
+           RPL_UNAWAY                    RPL_NOWAWAY
+
+
+
+
+
+
+Kalt                         Informational                     [Page 38]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Example:
+
+   AWAY :Gone to lunch.  Back in 5 ; Command to set away message to
+                                   "Gone to lunch.  Back in 5".
+
+4.2 Rehash message
+
+      Command: REHASH
+   Parameters: None
+
+   The rehash command is an administrative command which can be used by
+   an operator to force the server to re-read and process its
+   configuration file.
+
+   Numeric Replies:
+
+           RPL_REHASHING                 ERR_NOPRIVILEGES
+
+
+   Example:
+
+   REHASH                          ; message from user with operator
+                                   status to server asking it to reread
+                                   its configuration file.
+
+4.3 Die message
+
+      Command: DIE
+   Parameters: None
+
+   An operator can use the DIE command to shutdown the server.  This
+   message is optional since it may be viewed as a risk to allow
+   arbitrary people to connect to a server as an operator and execute
+   this command.
+
+   The DIE command MUST always be fully processed by the server to which
+   the sending client is connected and MUST NOT be passed onto other
+   connected servers.
+
+   Numeric Replies:
+
+           ERR_NOPRIVILEGES
+
+   Example:
+
+   DIE                             ; no parameters required.
+
+
+
+
+
+Kalt                         Informational                     [Page 39]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+4.4 Restart message
+
+      Command: RESTART
+   Parameters: None
+
+   An operator can use the restart command to force the server to
+   restart itself.  This message is optional since it may be viewed as a
+   risk to allow arbitrary people to connect to a server as an operator
+   and execute this command, causing (at least) a disruption to service.
+
+   The RESTART command MUST always be fully processed by the server to
+   which the sending client is connected and MUST NOT be passed onto
+   other connected servers.
+
+   Numeric Replies:
+
+           ERR_NOPRIVILEGES
+
+   Example:
+
+   RESTART                         ; no parameters required.
+
+4.5 Summon message
+
+      Command: SUMMON
+   Parameters: <user> [ <target> [ <channel> ] ]
+
+   The SUMMON command can be used to give users who are on a host
+   running an IRC server a message asking them to please join IRC.  This
+   message is only sent if the target server (a) has SUMMON enabled, (b)
+   the user is logged in and (c) the server process can write to the
+   user's tty (or similar).
+
+   If no <server> parameter is given it tries to summon <user> from the
+   server the client is connected to is assumed as the target.
+
+   If summon is not enabled in a server, it MUST return the
+   ERR_SUMMONDISABLED numeric.
+
+   Numeric Replies:
+
+           ERR_NORECIPIENT               ERR_FILEERROR
+           ERR_NOLOGIN                   ERR_NOSUCHSERVER
+           ERR_SUMMONDISABLED            RPL_SUMMONING
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 40]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   Examples:
+
+   SUMMON jto                      ; summon user jto on the server's
+                                   host
+
+   SUMMON jto tolsun.oulu.fi       ; summon user jto on the host which a
+                                   server named "tolsun.oulu.fi" is
+                                   running.
+
+4.6 Users
+
+      Command: USERS
+   Parameters: [ <target> ]
+
+   The USERS command returns a list of users logged into the server in a
+   format similar to the UNIX commands who(1), rusers(1) and finger(1).
+   If disabled, the correct numeric MUST be returned to indicate this.
+
+   Because of the security implications of such a command, it SHOULD be
+   disabled by default in server implementations.  Enabling it SHOULD
+   require recompiling the server or some equivalent change rather than
+   simply toggling an option and restarting the server.  The procedure
+   to enable this command SHOULD also include suitable large comments.
+
+   Numeric Replies:
+
+           ERR_NOSUCHSERVER              ERR_FILEERROR
+           RPL_USERSSTART                RPL_USERS
+           RPL_NOUSERS                   RPL_ENDOFUSERS
+           ERR_USERSDISABLED
+
+   Disabled Reply:
+
+           ERR_USERSDISABLED
+
+   Example:
+
+   USERS eff.org                   ; request a list of users logged in
+                                   on server eff.org
+
+4.7 Operwall message
+
+      Command: WALLOPS
+   Parameters: <Text to be sent>
+
+   The WALLOPS command is used to send a message to all currently
+   connected users who have set the 'w' user mode for themselves.  (See
+   Section 3.1.5 "User modes").
+
+
+
+Kalt                         Informational                     [Page 41]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   After implementing WALLOPS as a user command it was found that it was
+   often and commonly abused as a means of sending a message to a lot of
+   people.  Due to this, it is RECOMMENDED that the implementation of
+   WALLOPS allows and recognizes only servers as the originators of
+   WALLOPS.
+
+   Numeric Replies:
+
+           ERR_NEEDMOREPARAMS
+
+   Example:
+
+   :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS
+                                   message from csd.bu.edu announcing a
+                                   CONNECT message it received from
+                                   Joshua and acted upon.
+
+4.8 Userhost message
+
+      Command: USERHOST
+   Parameters: <nickname> *( SPACE <nickname> )
+
+   The USERHOST command takes a list of up to 5 nicknames, each
+   separated by a space character and returns a list of information
+   about each nickname that it found.  The returned list has each reply
+   separated by a space.
+
+   Numeric Replies:
+
+           RPL_USERHOST                  ERR_NEEDMOREPARAMS
+
+   Example:
+
+   USERHOST Wiz Michael syrk       ; USERHOST request for information on
+                                   nicks "Wiz", "Michael", and "syrk"
+
+   :ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net
+                                   ; Reply for user syrk
+
+4.9 Ison message
+
+      Command: ISON
+   Parameters: <nickname> *( SPACE <nickname> )
+
+   The ISON command was implemented to provide a quick and efficient
+   means to get a response about whether a given nickname was currently
+   on IRC. ISON only takes one (1) type of parameter: a space-separated
+   list of nicks.  For each nickname in the list that is present, the
+
+
+
+Kalt                         Informational                     [Page 42]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   server adds that to its reply string.  Thus the reply string may
+   return empty (none of the given nicks are present), an exact copy of
+   the parameter string (all of them present) or any other subset of the
+   set of nicks given in the parameter.  The only limit on the number of
+   nicks that may be checked is that the combined length MUST NOT be too
+   large as to cause the server to chop it off so it fits in 512
+   characters.
+
+   ISON is only processed by the server local to the client sending the
+   command and thus not passed onto other servers for further
+   processing.
+
+   Numeric Replies:
+
+           RPL_ISON                      ERR_NEEDMOREPARAMS
+
+   Example:
+
+   ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk
+                                   ; Sample ISON request for 7 nicks.
+
+5. Replies
+
+   The following is a list of numeric replies which are generated in
+   response to the commands given above.  Each numeric is given with its
+   number, name and reply string.
+
+5.1 Command responses
+
+   Numerics in the range from 001 to 099 are used for client-server
+   connections only and should never travel between servers.  Replies
+   generated in the response to commands are found in the range from 200
+   to 399.
+
+       001    RPL_WELCOME
+              "Welcome to the Internet Relay Network
+               <nick>!<user>@<host>"
+       002    RPL_YOURHOST
+              "Your host is <servername>, running version <ver>"
+       003    RPL_CREATED
+              "This server was created <date>"
+       004    RPL_MYINFO
+              "<servername> <version> <available user modes>
+               <available channel modes>"
+
+         - The server sends Replies 001 to 004 to a user upon
+           successful registration.
+
+
+
+
+Kalt                         Informational                     [Page 43]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       005    RPL_BOUNCE
+              "Try server <server name>, port <port number>"
+
+         - Sent by the server to a user to suggest an alternative
+           server.  This is often used when the connection is
+           refused because the server is already full.
+
+       302    RPL_USERHOST
+              ":*1<reply> *( " " <reply> )"
+
+         - Reply format used by USERHOST to list replies to
+           the query list.  The reply string is composed as
+           follows:
+
+           reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname
+
+           The '*' indicates whether the client has registered
+           as an Operator.  The '-' or '+' characters represent
+           whether the client has set an AWAY message or not
+           respectively.
+
+       303    RPL_ISON
+              ":*1<nick> *( " " <nick> )"
+
+         - Reply format used by ISON to list replies to the
+           query list.
+
+       301    RPL_AWAY
+              "<nick> :<away message>"
+       305    RPL_UNAWAY
+              ":You are no longer marked as being away"
+       306    RPL_NOWAWAY
+              ":You have been marked as being away"
+
+         - These replies are used with the AWAY command (if
+           allowed).  RPL_AWAY is sent to any client sending a
+           PRIVMSG to a client which is away.  RPL_AWAY is only
+           sent by the server to which the client is connected.
+           Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
+           client removes and sets an AWAY message.
+
+       311    RPL_WHOISUSER
+              "<nick> <user> <host> * :<real name>"
+       312    RPL_WHOISSERVER
+              "<nick> <server> :<server info>"
+       313    RPL_WHOISOPERATOR
+              "<nick> :is an IRC operator"
+
+
+
+
+Kalt                         Informational                     [Page 44]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       317    RPL_WHOISIDLE
+              "<nick> <integer> :seconds idle"
+       318    RPL_ENDOFWHOIS
+              "<nick> :End of WHOIS list"
+       319    RPL_WHOISCHANNELS
+              "<nick> :*( ( "@" / "+" ) <channel> " " )"
+
+         - Replies 311 - 313, 317 - 319 are all replies
+           generated in response to a WHOIS message.  Given that
+           there are enough parameters present, the answering
+           server MUST either formulate a reply out of the above
+           numerics (if the query nick is found) or return an
+           error reply.  The '*' in RPL_WHOISUSER is there as
+           the literal character and not as a wild card.  For
+           each reply set, only RPL_WHOISCHANNELS may appear
+           more than once (for long lists of channel names).
+           The '@' and '+' characters next to the channel name
+           indicate whether a client is a channel operator or
+           has been granted permission to speak on a moderated
+           channel.  The RPL_ENDOFWHOIS reply is used to mark
+           the end of processing a WHOIS message.
+
+       314    RPL_WHOWASUSER
+              "<nick> <user> <host> * :<real name>"
+       369    RPL_ENDOFWHOWAS
+              "<nick> :End of WHOWAS"
+
+         - When replying to a WHOWAS message, a server MUST use
+           the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
+           ERR_WASNOSUCHNICK for each nickname in the presented
+           list.  At the end of all reply batches, there MUST
+           be RPL_ENDOFWHOWAS (even if there was only one reply
+           and it was an error).
+
+       321    RPL_LISTSTART
+              Obsolete. Not used.
+
+       322    RPL_LIST
+              "<channel> <# visible> :<topic>"
+       323    RPL_LISTEND
+              ":End of LIST"
+
+         - Replies RPL_LIST, RPL_LISTEND mark the actual replies
+           with data and end of the server's response to a LIST
+           command.  If there are no channels available to return,
+           only the end reply MUST be sent.
+
+
+
+
+
+Kalt                         Informational                     [Page 45]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       325    RPL_UNIQOPIS
+              "<channel> <nickname>"
+
+       324    RPL_CHANNELMODEIS
+              "<channel> <mode> <mode params>"
+
+       331    RPL_NOTOPIC
+              "<channel> :No topic is set"
+       332    RPL_TOPIC
+              "<channel> :<topic>"
+
+         - When sending a TOPIC message to determine the
+           channel topic, one of two replies is sent.  If
+           the topic is set, RPL_TOPIC is sent back else
+           RPL_NOTOPIC.
+
+       341    RPL_INVITING
+              "<channel> <nick>"
+
+         - Returned by the server to indicate that the
+           attempted INVITE message was successful and is
+           being passed onto the end client.
+
+       342    RPL_SUMMONING
+              "<user> :Summoning user to IRC"
+
+         - Returned by a server answering a SUMMON message to
+           indicate that it is summoning that user.
+
+       346    RPL_INVITELIST
+              "<channel> <invitemask>"
+       347    RPL_ENDOFINVITELIST
+              "<channel> :End of channel invite list"
+
+         - When listing the 'invitations masks' for a given channel,
+           a server is required to send the list back using the
+           RPL_INVITELIST and RPL_ENDOFINVITELIST messages.  A
+           separate RPL_INVITELIST is sent for each active mask.
+           After the masks have been listed (or if none present) a
+           RPL_ENDOFINVITELIST MUST be sent.
+
+       348    RPL_EXCEPTLIST
+              "<channel> <exceptionmask>"
+       349    RPL_ENDOFEXCEPTLIST
+              "<channel> :End of channel exception list"
+
+
+
+
+
+
+Kalt                         Informational                     [Page 46]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+         - When listing the 'exception masks' for a given channel,
+           a server is required to send the list back using the
+           RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages.  A
+           separate RPL_EXCEPTLIST is sent for each active mask.
+           After the masks have been listed (or if none present)
+           a RPL_ENDOFEXCEPTLIST MUST be sent.
+
+       351    RPL_VERSION
+              "<version>.<debuglevel> <server> :<comments>"
+
+         - Reply by the server showing its version details.
+           The <version> is the version of the software being
+           used (including any patchlevel revisions) and the
+           <debuglevel> is used to indicate if the server is
+           running in "debug mode".
+
+           The "comments" field may contain any comments about
+           the version or further version details.
+
+       352    RPL_WHOREPLY
+              "<channel> <user> <host> <server> <nick>
+              ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
+              :<hopcount> <real name>"
+
+       315    RPL_ENDOFWHO
+              "<name> :End of WHO list"
+
+         - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
+           to answer a WHO message.  The RPL_WHOREPLY is only
+           sent if there is an appropriate match to the WHO
+           query.  If there is a list of parameters supplied
+           with a WHO message, a RPL_ENDOFWHO MUST be sent
+           after processing each list item with <name> being
+           the item.
+
+       353    RPL_NAMREPLY
+              "( "=" / "*" / "@" ) <channel>
+               :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
+         - "@" is used for secret channels, "*" for private
+           channels, and "=" for others (public channels).
+
+       366    RPL_ENDOFNAMES
+              "<channel> :End of NAMES list"
+
+         - To reply to a NAMES message, a reply pair consisting
+           of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
+           server back to the client.  If there is no channel
+           found as in the query, then only RPL_ENDOFNAMES is
+
+
+
+Kalt                         Informational                     [Page 47]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+           returned.  The exception to this is when a NAMES
+           message is sent with no parameters and all visible
+           channels and contents are sent back in a series of
+           RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
+           the end.
+
+       364    RPL_LINKS
+              "<mask> <server> :<hopcount> <server info>"
+       365    RPL_ENDOFLINKS
+              "<mask> :End of LINKS list"
+
+         - In replying to the LINKS message, a server MUST send
+           replies back using the RPL_LINKS numeric and mark the
+           end of the list using an RPL_ENDOFLINKS reply.
+
+       367    RPL_BANLIST
+              "<channel> <banmask>"
+       368    RPL_ENDOFBANLIST
+              "<channel> :End of channel ban list"
+
+         - When listing the active 'bans' for a given channel,
+           a server is required to send the list back using the
+           RPL_BANLIST and RPL_ENDOFBANLIST messages.  A separate
+           RPL_BANLIST is sent for each active banmask.  After the
+           banmasks have been listed (or if none present) a
+           RPL_ENDOFBANLIST MUST be sent.
+
+       371    RPL_INFO
+              ":<string>"
+       374    RPL_ENDOFINFO
+              ":End of INFO list"
+
+         - A server responding to an INFO message is required to
+           send all its 'info' in a series of RPL_INFO messages
+           with a RPL_ENDOFINFO reply to indicate the end of the
+           replies.
+
+       375    RPL_MOTDSTART
+              ":- <server> Message of the day - "
+       372    RPL_MOTD
+              ":- <text>"
+       376    RPL_ENDOFMOTD
+              ":End of MOTD command"
+
+         - When responding to the MOTD message and the MOTD file
+           is found, the file is displayed line by line, with
+           each line no longer than 80 characters, using
+
+
+
+
+Kalt                         Informational                     [Page 48]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+           RPL_MOTD format replies.  These MUST be surrounded
+           by a RPL_MOTDSTART (before the RPL_MOTDs) and an
+           RPL_ENDOFMOTD (after).
+
+       381    RPL_YOUREOPER
+              ":You are now an IRC operator"
+
+         - RPL_YOUREOPER is sent back to a client which has
+           just successfully issued an OPER message and gained
+           operator status.
+
+       382    RPL_REHASHING
+              "<config file> :Rehashing"
+
+         - If the REHASH option is used and an operator sends
+           a REHASH message, an RPL_REHASHING is sent back to
+           the operator.
+
+       383    RPL_YOURESERVICE
+              "You are service <servicename>"
+
+         - Sent by the server to a service upon successful
+           registration.
+
+       391    RPL_TIME
+              "<server> :<string showing server's local time>"
+
+         - When replying to the TIME message, a server MUST send
+           the reply using the RPL_TIME format above.  The string
+           showing the time need only contain the correct day and
+           time there.  There is no further requirement for the
+           time string.
+
+       392    RPL_USERSSTART
+              ":UserID   Terminal  Host"
+       393    RPL_USERS
+              ":<username> <ttyline> <hostname>"
+       394    RPL_ENDOFUSERS
+              ":End of users"
+       395    RPL_NOUSERS
+              ":Nobody logged in"
+
+         - If the USERS message is handled by a server, the
+           replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
+           RPL_NOUSERS are used.  RPL_USERSSTART MUST be sent
+           first, following by either a sequence of RPL_USERS
+           or a single RPL_NOUSER.  Following this is
+           RPL_ENDOFUSERS.
+
+
+
+Kalt                         Informational                     [Page 49]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       200    RPL_TRACELINK
+              "Link <version & debug level> <destination>
+               <next server> V<protocol version>
+               <link uptime in seconds> <backstream sendq>
+               <upstream sendq>"
+       201    RPL_TRACECONNECTING
+              "Try. <class> <server>"
+       202    RPL_TRACEHANDSHAKE
+              "H.S. <class> <server>"
+       203    RPL_TRACEUNKNOWN
+              "???? <class> [<client IP address in dot form>]"
+       204    RPL_TRACEOPERATOR
+              "Oper <class> <nick>"
+       205    RPL_TRACEUSER
+              "User <class> <nick>"
+       206    RPL_TRACESERVER
+              "Serv <class> <int>S <int>C <server>
+               <nick!user|*!*>@<host|server> V<protocol version>"
+       207    RPL_TRACESERVICE
+              "Service <class> <name> <type> <active type>"
+       208    RPL_TRACENEWTYPE
+              "<newtype> 0 <client name>"
+       209    RPL_TRACECLASS
+              "Class <class> <count>"
+       210    RPL_TRACERECONNECT
+              Unused.
+       261    RPL_TRACELOG
+              "File <logfile> <debug level>"
+       262    RPL_TRACEEND
+              "<server name> <version & debug level> :End of TRACE"
+
+         - The RPL_TRACE* are all returned by the server in
+           response to the TRACE message.  How many are
+           returned is dependent on the TRACE message and
+           whether it was sent by an operator or not.  There
+           is no predefined order for which occurs first.
+           Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
+           RPL_TRACEHANDSHAKE are all used for connections
+           which have not been fully established and are either
+           unknown, still attempting to connect or in the
+           process of completing the 'server handshake'.
+           RPL_TRACELINK is sent by any server which handles
+           a TRACE message and has to pass it on to another
+           server.  The list of RPL_TRACELINKs sent in
+           response to a TRACE command traversing the IRC
+           network should reflect the actual connectivity of
+           the servers themselves along that path.
+
+
+
+
+Kalt                         Informational                     [Page 50]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+           RPL_TRACENEWTYPE is to be used for any connection
+           which does not fit in the other categories but is
+           being displayed anyway.
+           RPL_TRACEEND is sent to indicate the end of the list.
+
+       211    RPL_STATSLINKINFO
+              "<linkname> <sendq> <sent messages>
+               <sent Kbytes> <received messages>
+               <received Kbytes> <time open>"
+
+         - reports statistics on a connection.  <linkname>
+           identifies the particular connection, <sendq> is
+           the amount of data that is queued and waiting to be
+           sent <sent messages> the number of messages sent,
+           and <sent Kbytes> the amount of data sent, in
+           Kbytes. <received messages> and <received Kbytes>
+           are the equivalent of <sent messages> and <sent
+           Kbytes> for received data, respectively.  <time
+           open> indicates how long ago the connection was
+           opened, in seconds.
+
+       212    RPL_STATSCOMMANDS
+              "<command> <count> <byte count> <remote count>"
+
+         - reports statistics on commands usage.
+
+       219    RPL_ENDOFSTATS
+              "<stats letter> :End of STATS report"
+
+       242    RPL_STATSUPTIME
+              ":Server Up %d days %d:%02d:%02d"
+
+         - reports the server uptime.
+
+       243    RPL_STATSOLINE
+              "O <hostmask> * <name>"
+
+         - reports the allowed hosts from where user may become IRC
+           operators.
+
+       221    RPL_UMODEIS
+              "<user mode string>"
+
+         - To answer a query about a client's own mode,
+           RPL_UMODEIS is sent back.
+
+       234    RPL_SERVLIST
+              "<name> <server> <mask> <type> <hopcount> <info>"
+
+
+
+Kalt                         Informational                     [Page 51]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       235    RPL_SERVLISTEND
+              "<mask> <type> :End of service listing"
+
+         - When listing services in reply to a SERVLIST message,
+           a server is required to send the list back using the
+           RPL_SERVLIST and RPL_SERVLISTEND messages.  A separate
+           RPL_SERVLIST is sent for each service.  After the
+           services have been listed (or if none present) a
+           RPL_SERVLISTEND MUST be sent.
+
+       251    RPL_LUSERCLIENT
+              ":There are <integer> users and <integer>
+               services on <integer> servers"
+       252    RPL_LUSEROP
+              "<integer> :operator(s) online"
+       253    RPL_LUSERUNKNOWN
+              "<integer> :unknown connection(s)"
+       254    RPL_LUSERCHANNELS
+              "<integer> :channels formed"
+       255    RPL_LUSERME
+              ":I have <integer> clients and <integer>
+                servers"
+
+         - In processing an LUSERS message, the server
+           sends a set of replies from RPL_LUSERCLIENT,
+           RPL_LUSEROP, RPL_USERUNKNOWN,
+           RPL_LUSERCHANNELS and RPL_LUSERME.  When
+           replying, a server MUST send back
+           RPL_LUSERCLIENT and RPL_LUSERME.  The other
+           replies are only sent back if a non-zero count
+           is found for them.
+
+       256    RPL_ADMINME
+              "<server> :Administrative info"
+       257    RPL_ADMINLOC1
+              ":<admin info>"
+       258    RPL_ADMINLOC2
+              ":<admin info>"
+       259    RPL_ADMINEMAIL
+              ":<admin info>"
+
+         - When replying to an ADMIN message, a server
+           is expected to use replies RPL_ADMINME
+           through to RPL_ADMINEMAIL and provide a text
+           message with each.  For RPL_ADMINLOC1 a
+           description of what city, state and country
+           the server is in is expected, followed by
+           details of the institution (RPL_ADMINLOC2)
+
+
+
+Kalt                         Informational                     [Page 52]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+           and finally the administrative contact for the
+           server (an email address here is REQUIRED)
+           in RPL_ADMINEMAIL.
+
+       263    RPL_TRYAGAIN
+              "<command> :Please wait a while and try again."
+
+         - When a server drops a command without processing it,
+           it MUST use the reply RPL_TRYAGAIN to inform the
+           originating client.
+
+5.2 Error Replies
+
+       Error replies are found in the range from 400 to 599.
+
+       401    ERR_NOSUCHNICK
+              "<nickname> :No such nick/channel"
+
+          - Used to indicate the nickname parameter supplied to a
+            command is currently unused.
+
+       402    ERR_NOSUCHSERVER
+              "<server name> :No such server"
+
+         - Used to indicate the server name given currently
+           does not exist.
+
+       403    ERR_NOSUCHCHANNEL
+              "<channel name> :No such channel"
+
+         - Used to indicate the given channel name is invalid.
+
+       404    ERR_CANNOTSENDTOCHAN
+              "<channel name> :Cannot send to channel"
+
+         - Sent to a user who is either (a) not on a channel
+           which is mode +n or (b) not a chanop (or mode +v) on
+           a channel which has mode +m set or where the user is
+           banned and is trying to send a PRIVMSG message to
+           that channel.
+
+       405    ERR_TOOMANYCHANNELS
+              "<channel name> :You have joined too many channels"
+
+         - Sent to a user when they have joined the maximum
+           number of allowed channels and they try to join
+           another channel.
+
+
+
+
+Kalt                         Informational                     [Page 53]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       406    ERR_WASNOSUCHNICK
+              "<nickname> :There was no such nickname"
+
+         - Returned by WHOWAS to indicate there is no history
+           information for that nickname.
+
+       407    ERR_TOOMANYTARGETS
+              "<target> :<error code> recipients. <abort message>"
+
+         - Returned to a client which is attempting to send a
+           PRIVMSG/NOTICE using the user@host destination format
+           and for a user@host which has several occurrences.
+
+         - Returned to a client which trying to send a
+           PRIVMSG/NOTICE to too many recipients.
+
+         - Returned to a client which is attempting to JOIN a safe
+           channel using the shortname when there are more than one
+           such channel.
+
+       408    ERR_NOSUCHSERVICE
+              "<service name> :No such service"
+
+         - Returned to a client which is attempting to send a SQUERY
+           to a service which does not exist.
+
+       409    ERR_NOORIGIN
+              ":No origin specified"
+
+         - PING or PONG message missing the originator parameter.
+
+       411    ERR_NORECIPIENT
+              ":No recipient given (<command>)"
+       412    ERR_NOTEXTTOSEND
+              ":No text to send"
+       413    ERR_NOTOPLEVEL
+              "<mask> :No toplevel domain specified"
+       414    ERR_WILDTOPLEVEL
+              "<mask> :Wildcard in toplevel domain"
+       415    ERR_BADMASK
+              "<mask> :Bad Server/host mask"
+
+         - 412 - 415 are returned by PRIVMSG to indicate that
+           the message wasn't delivered for some reason.
+           ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
+           are returned when an invalid use of
+           "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
+
+
+
+
+Kalt                         Informational                     [Page 54]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       421    ERR_UNKNOWNCOMMAND
+              "<command> :Unknown command"
+
+         - Returned to a registered client to indicate that the
+           command sent is unknown by the server.
+
+       422    ERR_NOMOTD
+              ":MOTD File is missing"
+
+         - Server's MOTD file could not be opened by the server.
+
+       423    ERR_NOADMININFO
+              "<server> :No administrative info available"
+
+         - Returned by a server in response to an ADMIN message
+           when there is an error in finding the appropriate
+           information.
+
+       424    ERR_FILEERROR
+              ":File error doing <file op> on <file>"
+
+         - Generic error message used to report a failed file
+           operation during the processing of a message.
+
+       431    ERR_NONICKNAMEGIVEN
+              ":No nickname given"
+
+         - Returned when a nickname parameter expected for a
+           command and isn't found.
+
+       432    ERR_ERRONEUSNICKNAME
+              "<nick> :Erroneous nickname"
+
+         - Returned after receiving a NICK message which contains
+           characters which do not fall in the defined set.  See
+           section 2.3.1 for details on valid nicknames.
+
+       433    ERR_NICKNAMEINUSE
+              "<nick> :Nickname is already in use"
+
+         - Returned when a NICK message is processed that results
+           in an attempt to change to a currently existing
+           nickname.
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 55]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       436    ERR_NICKCOLLISION
+              "<nick> :Nickname collision KILL from <user>@<host>"
+
+         - Returned by a server to a client when it detects a
+           nickname collision (registered of a NICK that
+           already exists by another server).
+
+       437    ERR_UNAVAILRESOURCE
+              "<nick/channel> :Nick/channel is temporarily unavailable"
+
+         - Returned by a server to a user trying to join a channel
+           currently blocked by the channel delay mechanism.
+
+         - Returned by a server to a user trying to change nickname
+           when the desired nickname is blocked by the nick delay
+           mechanism.
+
+       441    ERR_USERNOTINCHANNEL
+              "<nick> <channel> :They aren't on that channel"
+
+         - Returned by the server to indicate that the target
+           user of the command is not on the given channel.
+
+       442    ERR_NOTONCHANNEL
+              "<channel> :You're not on that channel"
+
+         - Returned by the server whenever a client tries to
+           perform a channel affecting command for which the
+           client isn't a member.
+
+       443    ERR_USERONCHANNEL
+              "<user> <channel> :is already on channel"
+
+         - Returned when a client tries to invite a user to a
+           channel they are already on.
+
+       444    ERR_NOLOGIN
+              "<user> :User not logged in"
+
+         - Returned by the summon after a SUMMON command for a
+           user was unable to be performed since they were not
+           logged in.
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 56]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       445    ERR_SUMMONDISABLED
+              ":SUMMON has been disabled"
+
+         - Returned as a response to the SUMMON command.  MUST be
+           returned by any server which doesn't implement it.
+
+       446    ERR_USERSDISABLED
+              ":USERS has been disabled"
+
+         - Returned as a response to the USERS command.  MUST be
+           returned by any server which does not implement it.
+
+       451    ERR_NOTREGISTERED
+              ":You have not registered"
+
+         - Returned by the server to indicate that the client
+           MUST be registered before the server will allow it
+           to be parsed in detail.
+
+       461    ERR_NEEDMOREPARAMS
+              "<command> :Not enough parameters"
+
+         - Returned by the server by numerous commands to
+           indicate to the client that it didn't supply enough
+           parameters.
+
+       462    ERR_ALREADYREGISTRED
+              ":Unauthorized command (already registered)"
+
+         - Returned by the server to any link which tries to
+           change part of the registered details (such as
+           password or user details from second USER message).
+
+       463    ERR_NOPERMFORHOST
+              ":Your host isn't among the privileged"
+
+         - Returned to a client which attempts to register with
+           a server which does not been setup to allow
+           connections from the host the attempted connection
+           is tried.
+
+       464    ERR_PASSWDMISMATCH
+              ":Password incorrect"
+
+         - Returned to indicate a failed attempt at registering
+           a connection for which a password was required and
+           was either not given or incorrect.
+
+
+
+
+Kalt                         Informational                     [Page 57]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       465    ERR_YOUREBANNEDCREEP
+              ":You are banned from this server"
+
+         - Returned after an attempt to connect and register
+           yourself with a server which has been setup to
+           explicitly deny connections to you.
+
+       466    ERR_YOUWILLBEBANNED
+
+         - Sent by a server to a user to inform that access to the
+           server will soon be denied.
+
+       467    ERR_KEYSET
+              "<channel> :Channel key already set"
+       471    ERR_CHANNELISFULL
+              "<channel> :Cannot join channel (+l)"
+       472    ERR_UNKNOWNMODE
+              "<char> :is unknown mode char to me for <channel>"
+       473    ERR_INVITEONLYCHAN
+              "<channel> :Cannot join channel (+i)"
+       474    ERR_BANNEDFROMCHAN
+              "<channel> :Cannot join channel (+b)"
+       475    ERR_BADCHANNELKEY
+              "<channel> :Cannot join channel (+k)"
+       476    ERR_BADCHANMASK
+              "<channel> :Bad Channel Mask"
+       477    ERR_NOCHANMODES
+              "<channel> :Channel doesn't support modes"
+       478    ERR_BANLISTFULL
+              "<channel> <char> :Channel list is full"
+
+       481    ERR_NOPRIVILEGES
+              ":Permission Denied- You're not an IRC operator"
+
+         - Any command requiring operator privileges to operate
+           MUST return this error to indicate the attempt was
+           unsuccessful.
+
+       482    ERR_CHANOPRIVSNEEDED
+              "<channel> :You're not channel operator"
+
+         - Any command requiring 'chanop' privileges (such as
+           MODE messages) MUST return this error if the client
+           making the attempt is not a chanop on the specified
+           channel.
+
+
+
+
+
+
+Kalt                         Informational                     [Page 58]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+       483    ERR_CANTKILLSERVER
+              ":You can't kill a server!"
+
+         - Any attempts to use the KILL command on a server
+           are to be refused and this error returned directly
+           to the client.
+
+       484    ERR_RESTRICTED
+              ":Your connection is restricted!"
+
+         - Sent by the server to a user upon connection to indicate
+           the restricted nature of the connection (user mode "+r").
+
+       485    ERR_UNIQOPPRIVSNEEDED
+              ":You're not the original channel operator"
+
+         - Any MODE requiring "channel creator" privileges MUST
+           return this error if the client making the attempt is not
+           a chanop on the specified channel.
+
+       491    ERR_NOOPERHOST
+              ":No O-lines for your host"
+
+         - If a client sends an OPER message and the server has
+           not been configured to allow connections from the
+           client's host as an operator, this error MUST be
+           returned.
+
+       501    ERR_UMODEUNKNOWNFLAG
+              ":Unknown MODE flag"
+
+         - Returned by the server to indicate that a MODE
+           message was sent with a nickname parameter and that
+           the a mode flag sent was not recognized.
+
+       502    ERR_USERSDONTMATCH
+              ":Cannot change mode for other users"
+
+         - Error sent to any user trying to view or change the
+           user mode for a user other than themselves.
+
+5.3 Reserved numerics
+
+   These numerics are not described above since they fall into one of
+   the following categories:
+
+   1. no longer in use;
+
+
+
+
+Kalt                         Informational                     [Page 59]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+   2. reserved for future planned use;
+
+   3. in current use but are part of a non-generic 'feature' of
+      the current IRC server.
+
+            231    RPL_SERVICEINFO     232  RPL_ENDOFSERVICES
+            233    RPL_SERVICE
+            300    RPL_NONE            316  RPL_WHOISCHANOP
+            361    RPL_KILLDONE        362  RPL_CLOSING
+            363    RPL_CLOSEEND        373  RPL_INFOSTART
+            384    RPL_MYPORTIS
+
+            213    RPL_STATSCLINE      214  RPL_STATSNLINE
+            215    RPL_STATSILINE      216  RPL_STATSKLINE
+            217    RPL_STATSQLINE      218  RPL_STATSYLINE
+            240    RPL_STATSVLINE      241  RPL_STATSLLINE
+            244    RPL_STATSHLINE      244  RPL_STATSSLINE
+            246    RPL_STATSPING       247  RPL_STATSBLINE
+            250    RPL_STATSDLINE
+
+            492    ERR_NOSERVICEHOST
+
+6. Current implementations
+
+   The IRC software, version 2.10 is the only complete implementation of
+   the IRC protocol (client and server).  Because of the small amount of
+   changes in the client protocol since the publication of RFC 1459
+   [IRC], implementations that follow it are likely to be compliant with
+   this protocol or to require a small amount of changes to reach
+   compliance.
+
+7. Current problems
+
+   There are a number of recognized problems with the IRC Client
+   Protocol, and more generally with the IRC Server Protocol.  In order
+   to preserve backward compatibility with old clients, this protocol
+   has almost not evolved since the publication of RFC 1459 [IRC].
+
+7.1 Nicknames
+
+   The idea of the nickname on IRC is very convenient for users to use
+   when talking to each other outside of a channel, but there is only a
+   finite nickname space and being what they are, it's not uncommon for
+   several people to want to use the same nick.  If a nickname is chosen
+   by two people using this protocol, either one will not succeed or
+   both will removed by use of a server KILL (See Section 3.7.1).
+
+
+
+
+
+Kalt                         Informational                     [Page 60]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+7.2 Limitation of wildcards
+
+   There is no way to escape the escape character "\" (%x5C).  While
+   this isn't usually a problem, it makes it impossible to form a mask
+   with a backslash character ("\") preceding a wildcard.
+
+7.3 Security considerations
+
+   Security issues related to this protocol are discussed in the "IRC
+   Server Protocol" [IRC-SERVER] as they are mostly an issue for the
+   server side of the connection.
+
+8. Current support and availability
+
+        Mailing lists for IRC related discussion:
+          General discussion: ircd-users@irc.org
+          Protocol development: ircd-dev@irc.org
+
+        Software implementations:
+          ftp://ftp.irc.org/irc/server
+          ftp://ftp.funet.fi/pub/unix/irc
+          ftp://ftp.irc.org/irc/clients
+
+        Newsgroup: alt.irc
+
+9. Acknowledgements
+
+   Parts of this document were copied from the RFC 1459 [IRC] which
+   first formally documented the IRC Protocol.  It has also benefited
+   from many rounds of review and comments.  In particular, the
+   following people have made significant contributions to this
+   document:
+
+   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
+   Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 61]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+10. References
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                Specifications: ABNF", RFC 2234, November 1997.
+
+   [HNAME]      Braden, R., "Requirements for Internet Hosts --
+                Application and Support", STD 3, RFC 1123, October 1989.
+
+   [IRC]        Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol",
+                RFC 1459, May 1993.
+
+   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+                April 2000.
+
+   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
+                2811, April 2000.
+
+   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+                2813, April 2000.
+
+11. Author's Address
+
+   Christophe Kalt
+   99 Teaneck Rd, Apt #117
+   Ridgefield Park, NJ 07660
+   USA
+
+   EMail: kalt@stealth.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 62]
+
+RFC 2812          Internet Relay Chat: Client Protocol        April 2000
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt                         Informational                     [Page 63]
+
diff --git a/include/Action.h b/include/Action.h
new file mode 100644
index 0000000..e9edf27
--- /dev/null
+++ b/include/Action.h
@@ -0,0 +1,57 @@
+#ifndef __ACTION_H__
+#define __ACTION_H__
+#ifdef __cplusplus
+
+#include "Exceptions.h"
+#include "Handle.h"
+#include "Variables.h"
+
+/*
+ * La classe Action defini les actions HTTP possibles.
+ * Le constructeur indique l'URL de l'action. Si aucune URL n'est specifiee,
+ * alors une URL aléatoire sera générée.
+ *
+ * Lors de la construction d'une Action, elle sera rajoutée dans une liste chaînée
+ * interne à la classe. De ce fait, la fonction Look4URL recherchera une Action
+ * associée a une URL donnée en paramètre dans la liste chaînée. Le destructeur
+ * va remettre en place la liste chaînée.
+ *
+ * Les dérivés doivent surcharger la méthode Do, qui recevra les variables transportées
+ * par l'action (si nous avions une méthode POST juste avant) et le handle d'écriture
+ * vers le socket HTTP. Ils devront aussi surcharger GetTitle, qui sert à écrire le
+ * titre de la page HTML dans les méthodes SendHead et SendFoot. Ces deux méthodes sont
+ * d'ailleurs surchargeables, pour créer de nouvelles skins HTML dans des classes dérivées.
+ *
+ * La méthode ShowButton sert à afficher un bouton sur la page. Par défaut, ce bouton reviendra
+ * vers la page principale.
+ *
+ * Une action peut être "temporaire", c'est à dire accessible uniquement une seule fois.
+ * Dans ce cas, après création, il faut faire appel à la méthode CleanUp, et la méthode
+ * Do devra terminer par un appel a Accessed, afin de supprimer cette Action.
+ */
+
+class Action : public Base {
+  public:
+    Action(const String & = "");
+    virtual ~Action();
+    Action * Look4URL(const String &);
+    virtual void Do(Variables *, Handle *) = 0;
+    virtual void SendHead(Handle *);
+    virtual void SendFoot(Handle *);
+    virtual void ShowButton(Handle *, const String & = "    Ok    ", const String & = "start");
+    virtual String GetTitle(void) = 0;
+    String GetURL(void);
+    void CleanUp(void);
+  protected:
+    void Accessed(void);
+  private:
+    static Action * start;
+    Action * next, * prev;
+    String URL;
+    bool hastoclean, accessed;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Confirm.h b/include/Confirm.h
new file mode 100644
index 0000000..b56e0d2
--- /dev/null
+++ b/include/Confirm.h
@@ -0,0 +1,33 @@
+#ifndef __CONFIRM_H__
+#define __CONFIRM_H__
+#ifdef __cplusplus
+
+#include "Exceptions.h"
+#include "Action.h"
+#include "String.h"
+
+/*
+ * Cette classe sert à afficher une boîte de dialogue de confirmation.
+ *   Constructeur:
+ *     - titre = titre de la boite de dialogue
+ *     - msg = message a afficher
+ *     - url = url de cette boite
+ *     - yes = action a effectuer si on clique sur Oui
+ *     - no = action a effectuer si on clique sur Non.
+ */
+
+class Confirm : public Action {
+  public:
+    Confirm(const String & titre, const String & msg, const String & url, Action * yes, Action * no = 0);
+    virtual ~Confirm() { }
+    virtual String GetTitle();
+    virtual void Do(Variables *, Handle *);
+  private:
+    String tit, msg;
+    Action * NYes, * NNo;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Exceptions.h b/include/Exceptions.h
new file mode 100644
index 0000000..34c1155
--- /dev/null
+++ b/include/Exceptions.h
@@ -0,0 +1,86 @@
+#ifndef __EXCEPTIONS_H__
+#define __EXCEPTIONS_H__
+#ifdef __cplusplus
+
+#include <stdio.h>
+#include <unistd.h>
+#include <stddef.h>
+
+/*
+ * Gère les exceptions du système. Le programme principal devrait tenter
+ * de les récupérer afin de les afficher.
+ *  GeneralExecption: exception de base. Construite sur une string.
+ *  MemoryException: plus assez de mémoire. Construit une string sur la taille mémoire
+ *                   qui a fait défaut.
+ *  IOException: erreur de lecture/écriture. Construite sur le nombre d'octets
+ *                                           et sur l'opération qui a générée l'erreur.
+ *  IOGeneral: erreur générale sur une opération IO (erreur à l'ouverture notemment)
+ *  IOInternal: erreur interne du programme. En particulier, le programme
+ *              a voulu lire ou écrire alors que le Handle n'était pas prévu pour.
+ *
+ * Nous définissons les fonctions xmalloc, xfree et xstrdup. Elles devraient être
+ * utilisées en lieu et place des fonctions malloc, free et strdup. La fonction realloc
+ * étant désapréciée, elle n'est pas surchargée.
+ */
+
+// Impossible de surcharger free(void *). Les compilateurs
+// refuseront de passer un char * par exemple.
+#define free(p) xfree((void*)p)
+
+// On prédéfinit la classe String, pour éviter
+// les deadlocks de compilation...
+class String;
+
+class Base {
+  public:
+    char * strdup(const char *) const;
+    void * malloc(ssize_t) const;
+/*    void * operator new(size_t);
+    void * operator new(size_t, void *); */
+};
+
+class GeneralException : public Base{
+  public:
+      GeneralException(String);
+      GeneralException(const GeneralException &);
+      ~GeneralException();
+    char * GetMsg();
+  protected:
+      GeneralException();
+    char * msg;
+    static char t[BUFSIZ];
+};
+
+class MemoryException : public GeneralException {
+  public:
+      MemoryException(ssize_t);
+};
+
+enum op_t {
+  IO_WRITE = 1,
+  IO_READ
+};
+
+class IOException : public GeneralException {
+  public:
+      IOException(String, op_t, ssize_t);
+};
+
+class IOGeneral : public GeneralException {
+  public:
+      IOGeneral(String);
+};
+
+class IOInternal : public GeneralException {
+  public:
+      IOInternal(String, op_t);
+};
+
+char * xstrdup(const char *) throw (MemoryException);
+void * xmalloc(ssize_t) throw (MemoryException);
+void xfree(void *&);
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Form.h b/include/Form.h
new file mode 100644
index 0000000..8a35898
--- /dev/null
+++ b/include/Form.h
@@ -0,0 +1,41 @@
+#ifndef __FORM_H__
+#define __FORM_H__
+#ifdef __cplusplus
+
+#include "Exceptions.h"
+#include "Action.h"
+#include "String.h"
+/*
+ * Cette classe sert à afficher un formulaire de saisie.
+ *   Constructeur:
+ *     - titre = titre de la page
+ *     - url = url de ce formulaire
+ *     - inv = invite du formulaire
+ *     - names = liste des noms des variables pour chaque champs
+ *     - invs = liste des invites pour chaque champs
+ *     - defaults = listes des valeurs par defaut pour chaque champs
+ *     - lists = liste des listes de valeurs pour les menus deroulants. Si une liste déroulante = 0,
+ *         alors il s'agira d'un champ de saisie manuel.
+ *     - descs = liste des listes de descriptions pour les menus deroulants.
+ *     - nb = nombre de champs
+ *     - ok = Action a effectuer lorsque l'on clique sur le bouton Ok.
+ */
+
+class Form : public Action {
+  public:
+    Form(const String & titre, const String & url, const String & inv,
+	 String * names, String * invs, String * defaults, String ** lists, String ** descs,
+	 int nb, Action * ok = 0);
+    virtual ~Form() { }
+    virtual String GetTitle();
+    virtual void Do(Variables *, Handle *);
+  private:
+    String tit, iv, * nms, * ivs, * defs, ** lsts, ** dscs;
+    int n;
+    Action * Next;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Handle.h b/include/Handle.h
new file mode 100644
index 0000000..cec51c7
--- /dev/null
+++ b/include/Handle.h
@@ -0,0 +1,51 @@
+#ifndef __HANDLE_H__
+#define __HANDLE_H__
+#ifdef __cplusplus
+
+#include <unistd.h>
+#include <iostream.h>
+#include "String.h"
+#include "Exceptions.h"
+
+/*
+ * Pour les classes qui vont deriver: le constructeur Handle(int) specifie
+ * le handle a stocker. De meme, GetHandle sert a lire le handle stocke.
+ *
+ * Les operateurs >> et << ne fonctionnent qu'avec des String. Vu que la
+ * classe String possede des constructeurs pour tous les types utiles, cela
+ * ne posera pas de problemes. >> va lire une ligne en supprimant les caractères
+ * '\n' des fins de lignes et en ignorant '\r'.
+ *
+ * Les fonctions read et write sont les memes que les fonctions systeme read
+ * et write.
+ *
+ * Les booleens CanRead et CanWrite indiquent si le handle peut lire ou ecrire.
+ *
+ * GetName donne le nom associe au handle. (nom de fichier ou autre)
+ */       
+
+class Handle : public Base {
+  public:
+      Handle(const Handle &);
+      virtual ~Handle();
+    ssize_t read(void *buf, size_t count) throw (IOException);
+    ssize_t write(const void *buf, size_t count) throw (IOException);
+    bool IsClosed(void);
+    virtual bool CanRead() = 0;
+    virtual bool CanWrite() = 0;
+    virtual String GetName() = 0;
+  protected:
+      Handle(int h);
+    int GetHandle();
+  private:
+    int h;
+    bool closed;
+};
+
+Handle & operator<<(Handle &, const String &);
+Handle & operator>>(Handle &, String &);
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/HttpServ.h b/include/HttpServ.h
new file mode 100644
index 0000000..71dc4eb
--- /dev/null
+++ b/include/HttpServ.h
@@ -0,0 +1,44 @@
+#ifndef __HTTPSERV_H__
+#define __HTTPSERV_H__
+#ifdef __cplusplus
+
+#include "Socket.h"
+#include "String.h"
+#include "Exceptions.h"
+#include "Variables.h"
+#include "Action.h"
+
+/*
+ * La classe HttpServ. Le constructueur (int, const String &) indique le port
+ * et le nom du serveur à indiquer dans les entetes HTTP.
+ *
+ * Une fois lance, il suffit de lancer MainLoop en indiquant le menu principal,
+ * qui est obligatoirement statique et doit posseder l'url /bin/start.
+ */
+
+class HttpServ : public Base {
+  public:
+      HttpServ(int = 1500, const String & = String("GruiK Server v0.1"));
+      ~HttpServ() {}
+      void MainLoop(Action *);
+  private:
+    String GetMime(const String &);
+    void ProcessRequest(Action *);
+    bool ParseUri(String &, String &, Socket &);
+    void ParseVars(Socket &, int);
+    void ShowError(Socket &);
+    void SendHeads(Socket &, const String &);
+    void SendRedirect(Socket &);
+    String name;
+    Socket Listener;
+    Variables * Vars;
+    int localport;
+    bool bad;
+};
+
+extern String endhl, endnl;
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Input.h b/include/Input.h
new file mode 100644
index 0000000..81a48d8
--- /dev/null
+++ b/include/Input.h
@@ -0,0 +1,26 @@
+#ifndef __INPUT_H__
+#define __INPUT_H__
+#ifdef __cplusplus
+
+#include "String.h"
+#include "Handle.h"
+
+/*
+ * Cette classe sert à créer un fichier ouvert en lecture.
+ */
+
+class Input : public Handle {
+  public:
+      Input(String = "") throw (IOGeneral);
+      virtual ~Input() {}
+    virtual bool CanWrite();
+    virtual bool CanRead();
+    virtual String GetName();
+  protected:
+    String n;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Makefile.am b/include/Makefile.am
new file mode 100644
index 0000000..f58566a
--- /dev/null
+++ b/include/Makefile.am
@@ -0,0 +1,2 @@
+include_HEADERS = Exceptions.h Handle.h String.h Output.h Socket.h HttpServ.h Variables.h Menu.h Action.h Message.h Form.h Confirm.h Table.h
+
diff --git a/include/Menu.h b/include/Menu.h
new file mode 100644
index 0000000..67bc54e
--- /dev/null
+++ b/include/Menu.h
@@ -0,0 +1,35 @@
+#ifndef __MENU_H__
+#define __MENU_H__
+#ifdef __cplusplus
+
+#include "Exceptions.h"
+#include "Action.h"
+#include "String.h"
+
+/*
+ * Cette classe permet d'afficher un menu.
+ *   Constructeur:
+ *     - titre = titre de la page
+ *     - url = url de la page
+ *     - labels = labels de items du menu
+ *     - listac = liste des pointeurs sur les actions
+ *     - nb = nombre d'items
+ */
+
+class Menu : public Action {
+  public:
+    Menu(const String & titre, const String & url, String * labels, Action ** listac, int nb);
+    virtual ~Menu() {}
+    virtual String GetTitle();
+    virtual void Do(Variables *, Handle *);
+  private:
+    String tit;
+    String * lt;
+    Action ** la;
+    int nba;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Message.h b/include/Message.h
new file mode 100644
index 0000000..1cdb297
--- /dev/null
+++ b/include/Message.h
@@ -0,0 +1,32 @@
+#ifndef __MESSAGE_H__
+#define __MESSAGE_H__
+#ifdef __cplusplus
+
+#include "Exceptions.h"
+#include "Action.h"
+#include "String.h"
+
+/*
+ * Cette classe sert a afficher un message.
+ *   Constructeur:
+ *     - titre = titre de la page
+ *     - msg = message de la boite de dialogue
+ *     - url = url de la page
+ *     - ok = action a effectuer lorsque l'on clique sur Ok.
+ */
+
+class Message : public Action {
+  public:
+    Message(const String & titre, const String & msg, const String & url, Action * ok = 0);
+    virtual ~Message() { }
+    virtual String GetTitle();
+    virtual void Do(Variables *, Handle *);
+  private:
+    String tit, msg;
+    Action * Next;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Output.h b/include/Output.h
new file mode 100644
index 0000000..6c944ab
--- /dev/null
+++ b/include/Output.h
@@ -0,0 +1,26 @@
+#ifndef __OUTPUT_H__
+#define __OUTPUT_H__
+#ifdef __cplusplus
+
+#include "String.h"
+#include "Handle.h"
+
+/*
+ * Ouvre un fichier en ecriture.
+ */
+
+class Output : public Handle {
+  public:
+      Output(String = "", int trunc = 1) throw (IOGeneral);
+      virtual ~Output() {}
+    virtual bool CanWrite();
+    virtual bool CanRead();
+    virtual String GetName();
+  protected:
+    String n;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Socket.h b/include/Socket.h
new file mode 100644
index 0000000..355d3b2
--- /dev/null
+++ b/include/Socket.h
@@ -0,0 +1,55 @@
+#ifndef __SOCKET_H__
+#define __SOCKET_H__
+#ifdef __cplusplus
+
+#include "String.h"
+#include "Handle.h"
+#include "Exceptions.h"
+#include "Output.h"
+#include "Input.h"
+
+/*
+ * Cree un socket.
+ *
+ * SetLocal(hostname, port) définit le hostname local et le port a écouter, si le
+ * socket est destine a etre un socket serveur, ou la vhost et le port source si
+ * le socket est destine a se etre un socket client. Renvoie faux si probleme quelconque.
+ *
+ * Connect(hostname, port) passe le socket en mode client et va se connecter sur
+ * l'adresse hostname:port specifiee.
+ * 
+ * Listen passe le socket en mode serveur.
+ *
+ * Accept permet de récuperer un client qui se connecte sur un socket server, et
+ * renvoie le socket de lecture/ecriture correspondant.
+ *
+ * Les methodes IsConnected et IsListening permettent de verifier l'etat du socket.
+ *
+ * Les fonctions WriteFile et ReadFile permettent de transmettre un fichier sur le socket.
+ * Tres utile pour l'upload ou le download.
+ */
+
+class Socket : public Handle {
+  public:
+      Socket() throw (GeneralException);
+      virtual ~Socket() {}
+    bool SetLocal(String, int = 0);
+    bool Connect(String, int);
+    bool Listen();
+    Socket Accept();
+    bool IsConnected();
+    bool IsListening();
+    size_t WriteFile(Output &);
+    size_t ReadFile(Input &);
+    virtual bool CanRead();
+    virtual bool CanWrite();
+    virtual String GetName();
+  private:
+    Socket(int s);
+    bool connected, listening;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/String.h b/include/String.h
new file mode 100644
index 0000000..65bf0ac
--- /dev/null
+++ b/include/String.h
@@ -0,0 +1,89 @@
+#ifndef __STRING_H__
+#define __STRING_H__
+#ifdef __cplusplus
+
+#include <iostream.h>
+#include <string.h>
+#include "Exceptions.h"
+
+/*
+ * Cette classe permet de stocker des chaînes de caractères simplement.
+ * Elle est une base essentielle et permet d'effectuer énormément d'opérations:
+ *   - set fonctionne comme sprintf, et réassigne la chaîne.
+ *   - to_charp() transforme la chaîne en pointeur.
+ *   - to_charp(from) extrait la chaîne depuis le caractère numéro from
+ *   - to_charp(from, to) extrait la chaîne depuis le caractère numéro from
+ *                        jusqu'au caractère numéro to.
+ *        ATTENTION: les fonctions to_charp renvoie un pointeur sur un tableau
+ *                   statique, et ce tableau sera modifié au prochain
+ *                   appel à to_charp ou a set.
+ *   - to_int transforme la chaîne en int.
+ *   - to_double transforme la chaîne en double
+ *   - to_sqldate effectue la conversion suivante: DD/MM/YYYY ==> YYYYMMDD
+ *   - to_sqltime effectue la conversion suivante: h:m ==> h * 60 + m
+ *   - from_sqldate et from_sqltime effectue les conversions inverses.
+ *   - datedif calcule la différence en jours entre deux dates. Si le résultat
+ *        est négatif, alors une des deux dates étaient invalide.
+ *   - is_date, is_number, is_float, is_time renvoient des booléens de test.
+ *   - strlen renvoie la longueur de la chaine
+ *   - strchr(c) renvoie la position du caractère c
+ *   - strchr(c, p) recherche le caractère c à partir de la position p
+ *   - strrchr(c) renvoie la position du caractère c, en recherchant depuis la droite.
+ *   - strstr(s) renvoie la position de la chaine s
+ *        NOTE: les fonctions de recherche renvoient un résultat négatif si pas trouvé.
+ *   - strchrcnt(c) compte le nombre d'occurences du caractère c.
+ *
+ *   Les opérateurs !=, ==, <=, >=, < et > permettent de comparer deux chaînes, en mode
+ *   'case sensitive'. L'operateur [] renvoie un caractère de la chaîne.
+ *
+ *   Les opérateurs << et >> vers un ostream ou depuis un istream sont supportés.
+ */
+
+class String : public Base {
+  public:
+      String(const String &);
+      String(const char * = "");
+      String(char);
+      String(int);
+      String(double);
+      ~String();
+      char * set(char *, ...);
+      char * to_charp(size_t = 0, ssize_t = -1) const;
+      int to_int() const;
+      double to_double() const;
+      String to_sqldate() const;
+      String to_sqltime() const;
+      String from_sqldate() const;
+      String from_sqltime() const;
+      double datedif(const String &) const;
+      bool is_date() const;
+      bool is_number() const;
+      bool is_float() const;
+      bool is_time() const;
+      size_t strlen() const;
+      ssize_t strchr(char, size_t = 0) const;
+      ssize_t strrchr(char) const;
+      ssize_t strstr(const String &) const;
+      int strchrcnt(char) const;
+      String & operator=(const String &);
+      String operator+(const String &) const;
+      String & operator+=(const String &);
+      bool operator!=(const String &) const;
+      bool operator==(const String &) const;
+      bool operator<=(const String &) const;
+      bool operator>=(const String &) const;
+      bool operator<(const String &) const;
+      bool operator>(const String &) const;
+      char operator[](size_t i) const;
+  private:
+    static char t[BUFSIZ];
+    char * str;
+};
+
+ostream & operator<<(ostream &, const String &);
+istream & operator>>(istream &, String &);
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Table.h b/include/Table.h
new file mode 100644
index 0000000..bfcd652
--- /dev/null
+++ b/include/Table.h
@@ -0,0 +1,36 @@
+#ifndef __TABLE_H__
+#define __TABLE_H__
+#ifdef __cplusplus
+
+#include "Exceptions.h"
+#include "Action.h"
+#include "String.h"
+
+/*
+ * Affiche une table.
+ *   Constructeurs:
+ *     - titre = titre de la page
+ *     - url = url de la page
+ *     - heads = liste des titres des colonnes. Si = 0, la ligne de titre est désactivée.
+ *     - cells = liste de toutes les cellules. Notez qu'il s'agit d'une liste linéaire.
+ *     - nbcol = nombre de colonnes
+ *     - nblig = nombre de lignes
+ *     - ok = action à effectuer si on clique sur le bouton Ok. Page principale par défaut.
+ */
+
+class Table : public Action {
+  public:
+    Table(const String & titre, const String & url, String * heads, String * cells, int nbcol, int nblgn, Action * ok = 0);
+    virtual ~Table() { }
+    virtual String GetTitle();
+    virtual void Do(Variables *, Handle *);
+  private:
+    String tit, * hds, * cls;
+    int nc, nl;
+    Action * Next;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/Variables.h b/include/Variables.h
new file mode 100644
index 0000000..955cf62
--- /dev/null
+++ b/include/Variables.h
@@ -0,0 +1,46 @@
+#ifndef __VARIABLES_H__
+#define __VARIABLES_H__
+#ifdef __cplusplus
+
+#include "Exceptions.h"
+#include "String.h"
+#include "Handle.h"
+
+/*
+ * Cette classe nous sert a gérer les variables transportées par les formulaires.
+ * Elle sera initialisée dans la classe HttpServ et sera passée en paramètre aux
+ * actions. Le constructeur indique le nombre de variables qu'il faut allouer.
+ * 
+ * SetTo sert à définir une variable suivant son numéro. On indique la string sous
+ * la forme "Nom=Valeur".
+ *
+ * L'opérateur [] est surchargé deux fois et permet:
+ *  - si on indique un int, de récupérer la variable sous la forme "Nom=Valeur"
+ *  - si on indique une string, de récupérer la valeur de la variable.
+ *
+ * La fonction Dump sert à sortir toutes les variables en un formulaire HTML, de
+ * sorte à faire transiter les variables d'un formulaire à l'autre. Toutes les actions
+ * implémentées ici possèdant des boutons font appel à cette méthode. En particulier,
+ * les formulaires en cascadent cumulent leurs variables.
+ *
+ * GetNb sert à lire le nombre de variables stockés dans l'instance.
+ */
+
+class Variables : public Base {
+  public:
+      Variables(int);
+      ~Variables();
+      void SetTo(int i, const String &);
+      String operator[](const String &);
+      String operator[](int i);
+      void Dump(Handle *);
+      int GetNb();
+  private:
+    String * Vars;
+    int nbvars;
+};
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/include/template.h b/include/template.h
new file mode 100644
index 0000000..f18662f
--- /dev/null
+++ b/include/template.h
@@ -0,0 +1,8 @@
+#ifndef ___H__
+#define ___H__
+#ifdef __cplusplus
+
+#else
+#error This only works with a C++ compiler
+#endif
+#endif
diff --git a/install-sh b/install-sh
new file mode 100755
index 0000000..e9de238
--- /dev/null
+++ b/install-sh
@@ -0,0 +1,251 @@
+#!/bin/sh
+#
+# install - install a program, script, or datafile
+# This comes from X11R5 (mit/util/scripts/install.sh).
+#
+# Copyright 1991 by the Massachusetts Institute of Technology
+#
+# Permission to use, copy, modify, distribute, and sell this software and its
+# documentation for any purpose is hereby granted without fee, provided that
+# the above copyright notice appear in all copies and that both that
+# copyright notice and this permission notice appear in supporting
+# documentation, and that the name of M.I.T. not be used in advertising or
+# publicity pertaining to distribution of the software without specific,
+# written prior permission.  M.I.T. makes no representations about the
+# suitability of this software for any purpose.  It is provided "as is"
+# without express or implied warranty.
+#
+# Calling this script install-sh is preferred over install.sh, to prevent
+# `make' implicit rules from creating a file called install from it
+# when there is no Makefile.
+#
+# This script is compatible with the BSD install script, but was written
+# from scratch.  It can only install one file at a time, a restriction
+# shared with many OS's install programs.
+
+
+# set DOITPROG to echo to test this script
+
+# Don't use :- since 4.3BSD and earlier shells don't like it.
+doit="${DOITPROG-}"
+
+
+# put in absolute paths if you don't have them in your path; or use env. vars.
+
+mvprog="${MVPROG-mv}"
+cpprog="${CPPROG-cp}"
+chmodprog="${CHMODPROG-chmod}"
+chownprog="${CHOWNPROG-chown}"
+chgrpprog="${CHGRPPROG-chgrp}"
+stripprog="${STRIPPROG-strip}"
+rmprog="${RMPROG-rm}"
+mkdirprog="${MKDIRPROG-mkdir}"
+
+transformbasename=""
+transform_arg=""
+instcmd="$mvprog"
+chmodcmd="$chmodprog 0755"
+chowncmd=""
+chgrpcmd=""
+stripcmd=""
+rmcmd="$rmprog -f"
+mvcmd="$mvprog"
+src=""
+dst=""
+dir_arg=""
+
+while [ x"$1" != x ]; do
+    case $1 in
+	-c) instcmd="$cpprog"
+	    shift
+	    continue;;
+
+	-d) dir_arg=true
+	    shift
+	    continue;;
+
+	-m) chmodcmd="$chmodprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-o) chowncmd="$chownprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-g) chgrpcmd="$chgrpprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-s) stripcmd="$stripprog"
+	    shift
+	    continue;;
+
+	-t=*) transformarg=`echo $1 | sed 's/-t=//'`
+	    shift
+	    continue;;
+
+	-b=*) transformbasename=`echo $1 | sed 's/-b=//'`
+	    shift
+	    continue;;
+
+	*)  if [ x"$src" = x ]
+	    then
+		src=$1
+	    else
+		# this colon is to work around a 386BSD /bin/sh bug
+		:
+		dst=$1
+	    fi
+	    shift
+	    continue;;
+    esac
+done
+
+if [ x"$src" = x ]
+then
+	echo "install:	no input file specified"
+	exit 1
+else
+	true
+fi
+
+if [ x"$dir_arg" != x ]; then
+	dst=$src
+	src=""
+	
+	if [ -d $dst ]; then
+		instcmd=:
+		chmodcmd=""
+	else
+		instcmd=mkdir
+	fi
+else
+
+# Waiting for this to be detected by the "$instcmd $src $dsttmp" command
+# might cause directories to be created, which would be especially bad 
+# if $src (and thus $dsttmp) contains '*'.
+
+	if [ -f $src -o -d $src ]
+	then
+		true
+	else
+		echo "install:  $src does not exist"
+		exit 1
+	fi
+	
+	if [ x"$dst" = x ]
+	then
+		echo "install:	no destination specified"
+		exit 1
+	else
+		true
+	fi
+
+# If destination is a directory, append the input filename; if your system
+# does not like double slashes in filenames, you may need to add some logic
+
+	if [ -d $dst ]
+	then
+		dst="$dst"/`basename $src`
+	else
+		true
+	fi
+fi
+
+## this sed command emulates the dirname command
+dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'`
+
+# Make sure that the destination directory exists.
+#  this part is taken from Noah Friedman's mkinstalldirs script
+
+# Skip lots of stat calls in the usual case.
+if [ ! -d "$dstdir" ]; then
+defaultIFS='	
+'
+IFS="${IFS-${defaultIFS}}"
+
+oIFS="${IFS}"
+# Some sh's can't handle IFS=/ for some reason.
+IFS='%'
+set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'`
+IFS="${oIFS}"
+
+pathcomp=''
+
+while [ $# -ne 0 ] ; do
+	pathcomp="${pathcomp}${1}"
+	shift
+
+	if [ ! -d "${pathcomp}" ] ;
+        then
+		$mkdirprog "${pathcomp}"
+	else
+		true
+	fi
+
+	pathcomp="${pathcomp}/"
+done
+fi
+
+if [ x"$dir_arg" != x ]
+then
+	$doit $instcmd $dst &&
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi
+else
+
+# If we're going to rename the final executable, determine the name now.
+
+	if [ x"$transformarg" = x ] 
+	then
+		dstfile=`basename $dst`
+	else
+		dstfile=`basename $dst $transformbasename | 
+			sed $transformarg`$transformbasename
+	fi
+
+# don't allow the sed command to completely eliminate the filename
+
+	if [ x"$dstfile" = x ] 
+	then
+		dstfile=`basename $dst`
+	else
+		true
+	fi
+
+# Make a temp file name in the proper directory.
+
+	dsttmp=$dstdir/#inst.$$#
+
+# Move or copy the file name to the temp name
+
+	$doit $instcmd $src $dsttmp &&
+
+	trap "rm -f ${dsttmp}" 0 &&
+
+# and set any options; do chmod last to preserve setuid bits
+
+# If any of these fail, we abort the whole thing.  If we want to
+# ignore errors from any of these, just make sure not to ignore
+# errors from the above "$doit $instcmd $src $dsttmp" command.
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else true;fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else true;fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else true;fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else true;fi &&
+
+# Now rename the file to the real destination.
+
+	$doit $rmcmd -f $dstdir/$dstfile &&
+	$doit $mvcmd $dsttmp $dstdir/$dstfile 
+
+fi &&
+
+
+exit 0
diff --git a/lib/Action.cc b/lib/Action.cc
new file mode 100644
index 0000000..292e669
--- /dev/null
+++ b/lib/Action.cc
@@ -0,0 +1,87 @@
+#include "String.h"
+#include "Action.h"
+#include "HttpServ.h"
+#include "config.h"
+
+Action * Action::start = 0;
+
+static int counter = 0;
+
+static String genurl(const String & u) {
+    if (u.strlen()) {
+	return u;
+    } else {
+	// Si l'url passée en paramètre est vide, on génère une URL
+	// sous la forme TmpXXXX où XXXX est une valeur qui s'incrémente.
+	return String("Tmp") + (counter++);
+    }
+}
+
+Action::Action(const String & u) : next(start), prev(0), URL(genurl(u)), hastoclean(false), accessed(false) {
+    start = this;
+    if (next) next->prev = this;
+}
+
+Action::~Action() {
+    if (start == this) {
+	start = next;
+    }
+    if (next) next->prev = prev;
+    if (prev) prev->next = next;
+}
+
+Action * Action::Look4URL(const String & URL) {
+    Action * p;
+    
+    for (p = start; p; p = p->next) {
+	if (!p->GetURL().strlen()) {
+	    // Si l'action que l'on vient de tester n'a pas d'URL, elle ne sert à rien.
+	    // On l'efface donc de notre liste. GetURL renvoie une chaine vide si l'action
+	    // était déclarée en mode CleanUp, puis a été accédée.
+	    delete p;
+	} else {
+	    if (URL == p->GetURL()) return p;
+	}
+    }
+    
+    return 0;
+}
+
+/*
+ * Voici la skin principale. Elle nécessite un fichier 'grain.png' dans le répertoire datas
+ * et un fichier 'style.css' (fournis)
+ */
+
+void Action::SendHead(Handle * h) {
+    (*h) << "<HTML><HEAD><TITLE>" << GetTitle() << "</TITLE>" << endnl <<
+    "<META http-equiv=\"Content-Style-Type\" content=\"text/css\">" << endnl <<
+    "<LINK REL=STYLESHEET HREF=\"/image/style.css\" TYPE=\"text/css\">" << endnl <<
+    "</HEAD><BODY BGCOLOR=\"#aaaaaa\" BACKGROUND=\"/image/grain.png\">" << endnl <<
+    "<center><TABLE WIDTH=\"50%\" BORDER=3 cellspacing=1 BGCOLOR=\"#ffffff\"><TR><TD>" << endnl <<
+    "<center><b><h1>" << GetTitle() << "</h1></b></center></TD></TR></TABLE><P>" << endnl <<
+    "<TABLE WIDTH=\"80%\" BORDER=2 cellspacing=1 BGCOLOR=\"#ffffff\"><TR><TD>" << endnl;
+}
+
+void Action::SendFoot(Handle * h) {
+    (*h) << "</TABLE></TD></TR></BODY></HTML>" << endnl;
+}
+
+String Action::GetURL(void) {
+    // Comme décrit plus haut, il faut renvoyer la chaîne vide si l'action est en
+    // mode CleanUp et a été lue.
+    return (hastoclean && accessed) ? "" : URL;
+}
+
+void Action::CleanUp(void) {
+    hastoclean = true;
+}
+
+void Action::Accessed(void) {
+    accessed = true;
+}
+
+void Action::ShowButton(Handle * h, const String & l, const String & u) {
+    (*h) << "<CENTER><FORM METHOD=\"POST\" ACTION=\"/bin/" << u << "\">" << endnl <<
+        "<INPUT TYPE=\"SUBMIT\" VALUE=\"" << l << "\">" << endnl
+	<< "</FORM></CENTER>" << endnl;
+}
diff --git a/lib/Confirm.cc b/lib/Confirm.cc
new file mode 100644
index 0000000..5177f8b
--- /dev/null
+++ b/lib/Confirm.cc
@@ -0,0 +1,26 @@
+#include "HttpServ.h"
+#include "Confirm.h"
+#include "config.h"
+
+Confirm::Confirm(const String & t, const String & m, const String & U, Action * y, Action * n) :
+    Action(U), tit(t), msg(m), NYes(y), NNo(n) { }
+
+void Confirm::Do(Variables * v, Handle * h) {
+    SendHead(h);
+    (*h) << msg << "<CENTER><TABLE BORDER=0><tr><td>" << endnl <<
+    "<FORM METHOD=\"POST\" ACTION=\"/bin/" << (NYes ? NYes->GetURL() : "start") << "\">" << endnl <<
+    "<INPUT TYPE=\"SUBMIT\" VALUE=\"     Oui     \">" << endnl;
+    v->Dump(h);
+    (*h) << "</FORM></td><td>" << endnl <<
+    "<FORM METHOD=\"POST\" ACTION=\"/bin/" << (NNo ? NNo->GetURL() : "start") << "\">" << endnl <<
+    "<INPUT TYPE=\"SUBMIT\" VALUE=\"     Non     \">" << endnl;
+    v->Dump(h);
+    (*h) << "</FORM></td></tr></TABLE></CENTER>" << endnl;
+    SendFoot(h);
+    
+    Accessed();
+}
+
+String Confirm::GetTitle(void) {
+    return tit;
+}
diff --git a/lib/Exceptions.cc b/lib/Exceptions.cc
new file mode 100644
index 0000000..b5a33bd
--- /dev/null
+++ b/lib/Exceptions.cc
@@ -0,0 +1,88 @@
+#include <malloc.h>
+#include <unistd.h>
+#include <string.h>
+#include <errno.h>
+#include <stddef.h>
+#include "config.h"
+#include "String.h"
+#include "Exceptions.h"
+
+char GeneralException::t[BUFSIZ];
+
+char * Base::strdup(const char * s) const {
+    return xstrdup(s);
+}
+
+void * Base::malloc(ssize_t s) const {
+    return xmalloc(s);
+}
+
+/*
+void * Base::operator new(size_t s) {
+    return memset(xmalloc(s), 0, s);
+}
+
+void * Base::operator new(size_t s, void * & p) {
+    return memset(p = xmalloc(s), 0, s);
+}
+*/
+
+GeneralException::GeneralException(String emsg) : msg(strdup(emsg.to_charp())) { }
+GeneralException::GeneralException() : msg(0) { }
+GeneralException::GeneralException(const GeneralException & e) : msg(strdup(e.msg)) { }
+
+GeneralException::~GeneralException() {
+    free(msg);
+}
+
+char * GeneralException::GetMsg() {
+    return msg;
+}
+
+MemoryException::MemoryException(ssize_t s) {
+    sprintf(t, _("Failed allocating %lld bytes."), s);
+    msg = strdup(t);
+}
+
+IOException::IOException(String fn, op_t op, ssize_t s) {
+    sprintf(t, _("An error has occured while %s %lld bytes from %s: %s"), op == IO_WRITE ? _("writing") : _("reading"),
+	    s, fn.to_charp(), strerror(errno));
+    msg = strdup(t);
+}
+
+IOInternal::IOInternal(String fn, op_t op) {
+    sprintf(t, _("Internal error: has occured while %s from %s: open for %s."), op == IO_WRITE ? _("writing") : _("reading"),
+	    fn.to_charp(), op == IO_WRITE ? _("reading") : _("writing"));
+    msg = strdup(t);
+}
+
+IOGeneral::IOGeneral(String fn) : GeneralException(fn) { }
+
+char * xstrdup(const char * s) throw (MemoryException) {
+    char * r;
+    
+    if (!(r = ::strdup(s))) {
+	throw MemoryException(strlen(s + 1));
+    }
+    
+    return r;
+}
+
+void * xmalloc(ssize_t s) throw (MemoryException) {
+    void * r;
+    
+    if (!(r = ::malloc(s))) {
+	throw MemoryException(s);
+    }
+    
+    return r;
+}
+
+#undef free
+
+void xfree(void *& p) {
+    if (p) {
+	::free(p);
+	p = 0;
+    }
+}
diff --git a/lib/Form.cc b/lib/Form.cc
new file mode 100644
index 0000000..5fb885a
--- /dev/null
+++ b/lib/Form.cc
@@ -0,0 +1,56 @@
+#include "Form.h"
+#include "HttpServ.h"
+
+Form::Form(const String & titre, const String & url, const String & inv, String * names, String * invs,
+	   String * defaults, String ** lists, String ** descs, int nb, Action * na) :
+  Action(url), tit(titre), iv(inv), nms(names), ivs(invs), defs(defaults), lsts(lists), dscs(descs), n(nb), Next(na) { }
+
+String Form::GetTitle(void) {
+    return tit;
+}
+
+void Form::Do(Variables * v, Handle * h) {
+    SendHead(h);
+
+    (*h) <<
+"<center>" << endnl <<
+"<form ACTION=\"/bin/" << (Next ? Next->GetURL() : "start") << "\" METHOD=POST>" << endnl;
+
+    v->Dump(h);
+    
+    (*h) <<
+"<table BORDER=0 CELLSPACING=0 BGCOLOR=\"#000000\"><tr><td>" << endnl <<
+"<table BORDER=0 CELLSPACING=0 CELLPADDING=3 WIDTH=\"300\" BGCOLOR=\"#FFFFCC\">" << endnl <<
+"<tr><td ALIGN=CENTER WIDTH=\"100%\" BGCOLOR=\"#000000\"><b><font FACE=\"arial,helvetica\" COLOR=\"#FFFFFF\">" << endnl <<
+iv << endnl <<
+"</font></b></td></tr>" << endnl;
+
+    for (int i = 0; i < n; i++) {
+	(*h) <<
+"<tr><td>" << ivs[i] << "</td></tr>" << endnl;
+	if (lsts[i]) {
+	    String * s, * t;
+	    (*h) <<
+"<tr><td><select NAME=\"" << nms[i] << "\">" << endnl;
+	    for (s = lsts[i], t = dscs[i]; s->strlen(); s++, t++) {
+		(*h) <<
+"<option VALUE=\"" << *s << "\">" << *t << "</option>" << endnl;
+	    }
+	    (*h) <<
+"</select></td></tr>" << endnl;
+	} else {
+	    (*h) <<
+"<tr><td><input TYPE=\"text\" NAME=\"" << nms[i] << "\" VALUE=\"" << defs[i] << "\" size=40></tr></td>" << endnl;
+	}
+    }
+    
+    (*h) <<
+
+"<tr><td ALIGN=\"center\"><input TYPE=\"submit\" VALUE=\"    Ok    \"></td></tr>" << endnl <<
+"</table></td></tr></table></form></center>" << endnl;
+
+    SendFoot(h);
+    
+    Accessed();
+}
+
diff --git a/lib/Handle.cc b/lib/Handle.cc
new file mode 100644
index 0000000..8108285
--- /dev/null
+++ b/lib/Handle.cc
@@ -0,0 +1,110 @@
+#include <stdio.h>
+#include <unistd.h>
+#include <string.h>
+#include <errno.h>
+#include "Handle.h"
+#include "config.h"
+
+Handle::Handle(const Handle & nh) : h(dup(nh.h)), closed(false) { }
+
+Handle::~Handle() {
+    if (h != -1) {
+	::close(h);
+    }
+}
+
+Handle::Handle(int nh) : h(nh), closed(false) { }
+
+int Handle::GetHandle() {
+    return h;
+}
+
+ssize_t Handle::write(const void *buf, size_t count) throw (IOException) {
+    ssize_t r, tr = 0;
+    bool done, full = false;
+
+    do {
+	done = true;
+        if ((r = ::write(h, buf, count)) < 0) {
+    	    if ((!errno) || (errno = EAGAIN)) {
+		// Avant de déclarer une erreur, on vérifie si ce n'est pas un
+		// problème lié au fait qu'il n'y a plus de place libre. Cela peut
+		// arriver si l'on agit sur un pipe ou un handle. Nous
+		// attendons encore une fois avant de déclarer l'erreur,
+		// grace au drapeau full.
+		if (full) {
+		    throw IOException(GetName(), IO_WRITE, count);
+		} else {
+		    sleep(1);
+		    done = false;
+		    full = true;
+		    tr += r;
+		}
+	    } else {
+		throw IOException(GetName(), IO_WRITE, count);
+	    }
+	} else if (r != count) {
+	    full = done = false;
+	    ((char *)buf) += r;
+	    tr += r;
+	}
+    } while (!done);
+
+    return r + tr;
+}
+
+ssize_t Handle::read(void *buf, size_t count) throw (IOException) {
+    ssize_t r;
+
+    if ((r = ::read(h, buf, count)) < 0) {
+	if ((!errno) || (errno = EAGAIN)) {
+	    // Avant de déclarer une erreur, on vérifie si ce n'est pas un
+	    // problème lié au fait qu'il n'y a plus d'octets.
+	    return 0;
+	} else {
+	    throw IOException(GetName(), IO_READ, count);
+	}
+    }
+    
+    if (!r) {
+	closed = true;
+    }
+
+    return r;
+}
+
+bool Handle::IsClosed(void) {
+    return closed;
+}
+
+Handle & operator<<(Handle & h, const String & s) {
+    char * p;
+    
+    p = s.to_charp();
+    h.write(p, strlen(p));
+    
+    return h;
+}
+
+Handle & operator>>(Handle & h, String & s) {
+    char t[BUFSIZ];
+    int i = 0, r;
+    
+    while ((r = h.read(&(t[i]), 1)) && (i != (BUFSIZ - 1))) {
+	// Il y a souvent des \r\n dans les sockets par exemple.
+	// On ignore le \r pour ne garder que le \n, standard sous
+	// Unix.
+	if (t[i] == '\r') {
+	    continue;
+	}
+	if (t[i] == '\n') {
+	    break;
+	} else {
+	    i++;
+	}
+    }
+    
+    t[i] = '\0';
+    s.set("%s", t);
+    return h;
+}
diff --git a/lib/HttpServ.cc b/lib/HttpServ.cc
new file mode 100644
index 0000000..dfead28
--- /dev/null
+++ b/lib/HttpServ.cc
@@ -0,0 +1,297 @@
+#include "Action.h"
+#include "HttpServ.h"
+#include "Socket.h"
+#include "config.h"
+
+String endhl = "\r\n", endnl = "\n";
+
+HttpServ::HttpServ(int port, const String & nname) : name(nname), localport(port) {
+    Listener.SetLocal("", port);
+    Listener.Listen();
+    cerr << "Mini HTTP-Server '" << name << "' ready and listening for port " << port << endl;
+}
+
+void HttpServ::MainLoop(Action * p) {
+    while (1) {
+	ProcessRequest(p);
+    }
+}
+
+void HttpServ::ProcessRequest(Action * p) {
+    Socket s(Listener.Accept());
+    String file, domain, t;
+    Action * f;
+    int len;
+
+    bad = false;
+    
+    if (!s.IsConnected()) return;
+    
+    cerr << "Got a request\n----\n";
+    
+    bool post = ParseUri(file, domain, s);
+
+
+    len = -1;
+    do {
+	s >> t;
+	cerr << t << endl;
+	if ((t.strstr("Content-Length: ") == 0) || (t.strstr("Content-length: ") == 0)) {
+	    cerr << "Saw 'Content-Lenght:', reading length from '" << t.to_charp(16) << "'\n";
+	    len = String(t.to_charp(16)).to_int();
+	}
+    } while (t.strlen());
+    
+    if (post) {
+	// On a pas eu de ligne 'Content-Length' mais on a eu une méthode POST.
+	// Cela est une erreur.
+	if (len == -1) {
+	    bad = true;
+	    Vars = new Variables(0);
+	} else {
+	    cerr << "Got a POST request. Parsing variables. (len = " << len << ")\n";
+	    // Les variables seront initialisées ici.
+	    ParseVars(s, len);
+	}
+    } else {
+	Vars = new Variables(0);
+    }
+    
+    cerr << " Domain = '" << domain << "' - File = '" << file << "'\n";
+    
+    if (!bad) {
+	// Nous vérifions le domaine.
+	if (domain != "") {
+	    bad = true;
+	    // Les domaines valides sont '/', '/bin' et '/image'.
+	    if (domain == "/image") bad = false;
+	    if (domain == "/bin") bad = false;
+	    if (domain == "/") bad = false;
+	} else {
+	    // L'url sans domaine ni fichier est valide. (cela arrive sur certains navigateurs...)
+	    bad = (file != "");
+	}
+    }
+
+    if (bad) {
+	ShowError(s);
+    } else {
+	if (((domain == "") || (domain == "/")) && (file == "")) {
+	    // Si le navigateur a demandé l'URL '/', alors on renvoie une notification
+	    // de redirection.
+	    SendRedirect(s);
+	} else if (domain == "/bin") {
+	    // Le domaine 'bin' est réservé aux actions. On cherche donc l'action à effectuer.
+	    if ((f = p->Look4URL(file))) {
+    		SendHeads(s, "text/html");
+		f->Do(Vars, &s);
+	    } else {
+		ShowError(s);
+	    }
+	} else {
+	    // Dans tous les autres cas de domaine, on cherche le fichier dans le répertoire datas.
+	    // On utilise try au cas où le fichier n'existe pas et donc que le constructeur
+	    // d'input renvoie une erreur.
+	    try {
+		Input i(String("datas/") + file);
+	        SendHeads(s, GetMime(file));
+	        s.ReadFile(i);
+		cerr << "File found, dumped.\n";
+	    }
+	    catch (IOGeneral e) {
+		ShowError(s);
+		cerr << "File not found, error showed.\n";
+	    }
+	}
+    }
+    
+    delete Vars;
+    
+    cerr << "----\n";
+}
+
+void HttpServ::ParseVars(Socket & s, int len) {
+    String t, v;
+    char conv[3], l;
+    int hconv, nbvars;
+    ssize_t pos = 0, next;
+    
+    t = "";
+    for (int i = 0; i < len; i++) {
+	s.read(&l, 1);
+	t += l;
+    }
+    cerr << "Post variables line: '" <<t << "'\n";
+    
+    
+    // Les variables sont sous la forme 'var1=val1&var2=val2&val3=var3'. Donc le nombre d'occurences
+    // du caractère '=' indique le nombre de variables.
+    nbvars = t.strchrcnt('=');
+    Vars = new Variables(nbvars);
+    
+    for (int i = 0; i < nbvars; i++) {
+	// Les variables sont sous la forme 'var1=val1&var2=val2&val3=var3'. Donc on cherche le caractère
+	// & dans la chaine POST.
+	next = t.strchr('&', pos);
+	if (next < 0) next = t.strlen();
+	v = "";
+	while (pos != next) {
+	    switch (t[pos]) {
+	    // Le navigateur encode les caractères spéciaux à l'aide du format %XX où XX indique
+	    // la valeur hexadécimale du caractère. Nous encodons surtout les caractères
+	    // ' ', '=', '%', et '/' avec cette technique.
+	    case '%':
+		pos++;
+		conv[0] = t[pos++];
+		conv[1] = t[pos++];
+		conv[2] = '\0';
+		sscanf(conv, "%x", &hconv);
+		v += ((char) hconv);
+		break;
+	    // Certains navigateurs utilisent '+' pour indiquer ' ' (qui est illégal) au lieu
+	    // d'utiliser %20.
+	    case '+':
+		v += ' ';
+		pos++;
+		break;
+	    default:
+    		v += t[pos++];
+	    }
+	    Vars->SetTo(i, v);
+	}
+	pos++;
+    }
+}
+
+/*
+ * Cette fonction renverra true si la méthode est une méthode POST.
+ * Les Strings domain et file seront modifiées afin de renvoyer le domaine
+ * et le fichier lut. La string s doit donner la première ligne de la requète,
+ * c'est à dire la méthode demandée par le client.
+ */
+
+bool HttpServ::ParseUri(String & file, String & domain, Socket & s) {
+    String t, Uri;
+    bool post = false;
+    char * p;
+    ssize_t sppos;
+
+    s >> t;
+    cerr << t << endl;
+    
+    bad = false;
+    
+    // p nous indiquera la position de la chaîne URL.
+    switch (t[0]) {
+    case 'P': /* POST? */
+	p = t.to_charp(1, 4);
+	if (!strcmp(p, "OST ")) {
+    	    p = t.to_charp(5);
+	    post = true;
+	    break;
+	}
+    case 'G': /* GET? */
+	p = t.to_charp(1, 3);
+	if (!strcmp(p, "ET ")) {
+	    p = t.to_charp(4);
+	    break;
+	}
+    default:
+	bad = true;
+    }
+    
+    if (!bad) {
+	ssize_t poshttp, posslash;
+        Uri = p;
+	sppos = Uri.strrchr(' ');
+	p = Uri.to_charp(0, sppos - 1);
+	Uri = p;
+	// On enlève tout le host spécifié éventuellement dans la requete.
+	if ((poshttp = Uri.strstr("http://")) > 0) {
+	    Uri = Uri.to_charp(poshttp + 7);
+	    posslash = Uri.strchr('/');
+	    // Certains navigateurs indiqueront uniquement http://host comme URL.
+	    if (posslash >= 0) {
+		Uri = Uri.to_charp(posslash);
+	    } else {
+		Uri = "";
+	    }
+	}
+	posslash = Uri.strrchr('/');
+	file = Uri.to_charp(posslash + 1);
+	if (posslash > 0) {
+	    domain = Uri.to_charp(0, posslash - 1);
+	} else {
+	    domain = "";
+	}
+    }
+    return post;
+}
+
+/*
+ * Ceci sert à rediriger le navigateur vers l'url de démarrage.
+ */
+void HttpServ::SendRedirect(Socket & s) {
+    s << "HTTP/1.1 301 Moved Permanently" << endhl << 
+	 "Server: " << name << endhl <<
+	 "Location: http://127.0.0.1:" << localport << "/bin/start" << endhl <<
+	 "Cache-Control: no-cache" << endhl <<
+	 "Connection-Type: closed" << endhl <<
+	 "Content-Type: text/html" << endhl << endhl <<
+	 "<HTML><HEAD><TITLE>301 - Moved Permanently</TITLE></HEAD>" << endnl <<
+	 "<BODY><center><b><h2>You should be redirected to the " << endnl << endnl <<
+	 "<a href=\"http://localhost/bin/start\">start page</a></h2></b></center>" << endnl <<
+	 "</BODY></HTML>" << endnl;
+}
+
+/*
+ * Nous envoyons les entetes de réponse HTTP.
+ */
+
+void HttpServ::SendHeads(Socket & s, const String & mime) {
+    s << "HTTP/1.1 200 OK" << endhl <<
+	 "Server: " << name << endhl <<
+	 "Cache-Control: no-cache" << endhl <<
+	 "Connection-Type: closed" << endhl <<
+	 "Content-Type: " << mime << endhl << endhl;
+}
+
+/*
+ * Affichage d'une erreur 404.
+ */
+
+void HttpServ::ShowError(Socket & s) {
+    s << "HTTP/1.1 404 Not Found" << endhl <<
+         "Server: " << name << endhl <<
+	 "Cache-Control: no-cache" << endhl <<
+         "Connection-Type: closed" << endhl <<
+         "Content-Type: text/html" << endhl << endhl <<
+	 "<HTML><HEAD><TITLE>404 - Error</TITLE></HEAD>" << endnl <<
+	 "<BODY><center><b><h2>The server was unable to process your query</h2></b></center>" << endnl <<
+	 "Click <A HREF=\"/\">here</A> to go the main page." <<
+	 "</BODY></HTML>" << endnl;
+}
+
+/*
+ * Sert à déterminer le type mime à partir de l'extension du fichier.
+ * Par défaut, nous mettons "text/plain".
+ */
+
+String HttpServ::GetMime(const String & f) {
+    String ext;
+    size_t ppos;
+    
+    ppos = f.strrchr('.');
+    
+    if (ppos >= 0) {
+	ext = f.to_charp(ppos + 1);
+	if (ext == "jpg") return "image/jpeg";
+	if (ext == "jpeg") return "image/jpeg";
+	if (ext == "htm") return "text/html";
+	if (ext == "html") return "text/html";
+	if (ext == "gif") return "image/gif";
+	if (ext == "png") return "image/png";
+    }
+    
+    return "text/plain";
+}
diff --git a/lib/Input.cc b/lib/Input.cc
new file mode 100644
index 0000000..f4e2602
--- /dev/null
+++ b/lib/Input.cc
@@ -0,0 +1,32 @@
+#include <stdio.h>
+#include <unistd.h>
+#include <string.h>
+#include <errno.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+		       
+#include "Input.h"
+#include "Exceptions.h"
+#include "config.h"
+
+Input::Input(String no) throw (IOGeneral) :
+    Handle(no.strlen() ? open(no.to_charp(), O_RDONLY) : 0),
+    n(no) {
+    if (GetHandle() < 0) {
+	throw IOGeneral(String("Error opening file") + no + " for reading: " + strerror(errno));
+    }
+}
+
+bool Input::CanWrite() {
+    return 0;
+}
+
+bool Input::CanRead() {
+    return 1;
+}
+
+String Input::GetName() {
+    return n;
+}
+
diff --git a/lib/Makefile.am b/lib/Makefile.am
new file mode 100644
index 0000000..5149387
--- /dev/null
+++ b/lib/Makefile.am
@@ -0,0 +1,12 @@
+localedir = $(datadir)/locale
+DEFS = -DLOCALEDIR=\"$(localedir)\" @DEFS@
+AM_CFLAGS = -O3 -Wall -Wstrict-prototypes $(CFLAGS)
+AM_CXXFLAGS = -O3 -Wall -Wstrict-prototypes $(CXXFLAGS)
+INCLUDES = -I. -I.. -I$(includedir) -I../include
+lib_LTLIBRARIES = libClasses.la
+
+libClasses_la_SOURCES = Exceptions.cc Handle.cc Output.cc String.cc\
+ Socket.cc Input.cc HttpServ.cc Variables.cc Action.cc Menu.cc Message.cc\
+ Form.cc Confirm.cc Table.cc checkargs.c datecalc.c
+
+libClasses_la_LDFLAGS = -version-info $(Classes_VERSION_INFO)
diff --git a/lib/Menu.cc b/lib/Menu.cc
new file mode 100644
index 0000000..7488d1d
--- /dev/null
+++ b/lib/Menu.cc
@@ -0,0 +1,26 @@
+#include "Menu.h"
+#include "HttpServ.h"
+
+Menu::Menu(const String & t, const String & U, String * ts, Action ** as, int nb) :
+    Action(U), tit(t), lt(ts), la(as), nba(nb) { }
+
+void Menu::Do(Variables * v, Handle * h) {
+    int i, f = 0;
+    
+    SendHead(h);
+    (*h) << "<center><TABLE BORDER=0>" << endnl;
+    for (i = 0; i < nba; i++) {
+	(*h) << "<TR BGCOLOR=\"#" << (f ? "dddddd" : "cccccc") << "\"><TD ALIGN=\"center\">" << (i + 1) << "</TD><TD>"
+	"<A HREF=\"/bin/" << (la[i] ? la[i]->GetURL() : "start") << "\">"
+	 << lt[i] << "</A></TD></TR>" << endnl;
+	f = f ? 0 : 1;
+    }
+    (*h) << "</TABLE></center>" << endnl;
+    SendFoot(h);
+    
+    Accessed();
+}
+
+String Menu::GetTitle(void) {
+    return tit;
+}
diff --git a/lib/Message.cc b/lib/Message.cc
new file mode 100644
index 0000000..1ede8fb
--- /dev/null
+++ b/lib/Message.cc
@@ -0,0 +1,21 @@
+#include "HttpServ.h"
+#include "Message.h"
+#include "config.h"
+
+Message::Message(const String & t, const String & m, const String & U, Action * n) :
+    Action(U), tit(t), msg(m), Next(n) { }
+
+void Message::Do(Variables * v, Handle * h) {
+    SendHead(h);
+    (*h) << msg << "<CENTER><FORM METHOD=\"POST\" ACTION=\"/bin/" << (Next ? Next->GetURL() : "start") << "\">" << endnl <<
+    "<INPUT TYPE=\"SUBMIT\" VALUE=\"     Ok     \">" << endnl;
+    v->Dump(h);
+    (*h) << "</FORM></CENTER>" << endnl;
+    SendFoot(h);
+    
+    Accessed();
+}
+
+String Message::GetTitle(void) {
+    return tit;
+}
diff --git a/lib/Output.cc b/lib/Output.cc
new file mode 100644
index 0000000..75bb437
--- /dev/null
+++ b/lib/Output.cc
@@ -0,0 +1,32 @@
+#include <stdio.h>
+#include <unistd.h>
+#include <string.h>
+#include <errno.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+		       
+#include "Output.h"
+#include "Exceptions.h"
+#include "config.h"
+
+Output::Output(String no, int trunc = 1) throw (IOGeneral) :
+    Handle(no.strlen() ? open(no.to_charp(), O_WRONLY | O_CREAT | (trunc ? O_TRUNC : O_APPEND)) : 1),
+    n(no) {
+    if (GetHandle() < 0) {
+	throw IOGeneral(String("Error opening file") + no + " for writing: " + strerror(errno));
+    }
+}
+
+bool Output::CanWrite() {
+    return 1;
+}
+
+bool Output::CanRead() {
+    return 0;
+}
+
+String Output::GetName() {
+    return n;
+}
+
diff --git a/lib/Socket.cc b/lib/Socket.cc
new file mode 100644
index 0000000..100d434
--- /dev/null
+++ b/lib/Socket.cc
@@ -0,0 +1,140 @@
+#include <netdb.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <string.h>
+#include <strings.h>
+#include <errno.h>
+#include "String.h"
+#include "Socket.h"
+#include "Exceptions.h"
+#include "config.h"
+#include "Input.h"
+#include "Output.h"
+
+Socket::Socket() throw (GeneralException) : Handle(socket(AF_INET, SOCK_STREAM, 0)), connected(false), listening(false) {
+    if (GetHandle() < 0) {
+	throw GeneralException("Error creating socket.");
+    }
+}
+
+Socket::Socket(int h) : Handle(h), connected(true), listening(false) { }
+
+String Socket::GetName(void) {
+    return String("socket");
+}
+
+bool Socket::IsConnected(void) {
+    return connected;
+}
+
+bool Socket::IsListening(void) {
+    return listening;
+}
+
+bool Socket::CanRead(void) {
+    return connected;
+}
+
+bool Socket::CanWrite(void) {
+    return connected;
+}
+
+size_t Socket::WriteFile(Output & o) {
+    char c;
+    size_t s = 0;
+    
+    while (!IsClosed()) {
+	s += read(&c, 1);
+	o.write(&c, 1);
+    }
+    return s;
+}
+
+size_t Socket::ReadFile(Input & i) {
+    char c;
+    size_t s = 0;
+    
+    while (!i.IsClosed()) {
+	s += i.read(&c, 1);
+	write(&c, 1);
+    }
+    return s;
+}
+
+
+    /***********************************************\
+    * Toute la suite n'est pas à décrire. Consulter *
+    * plutôt un document décrivant les sockets.     *
+    \***********************************************/
+
+
+bool Socket::SetLocal(String vhost, int port) {
+    struct hostent * localhostent;
+    struct in_addr localhostaddr;
+    struct sockaddr_in localsocketaddr;
+
+
+    memset((void *)&localhostaddr, 0, sizeof(localhostaddr));
+
+    if (vhost.strlen() != 0) {
+	if ((localhostent = gethostbyname(vhost.to_charp()))) {
+	    memcpy((void *)&localhostaddr, localhostent->h_addr, sizeof(localhostaddr));
+	} else {
+	    return false;
+	}
+    } else {
+	localhostaddr.s_addr = htonl(INADDR_ANY);
+    }
+
+    memset(&localsocketaddr, 0, sizeof(struct sockaddr_in));
+    localsocketaddr.sin_family = AF_INET;
+    localsocketaddr.sin_addr = localhostaddr;
+    localsocketaddr.sin_port = htons(port);
+
+    if (bind(GetHandle(), (struct sockaddr *) &localsocketaddr, sizeof(localsocketaddr)) < 0) {
+	return false;
+    } else {
+	return true;
+    }
+}
+
+bool Socket::Connect(String host, int port) {
+    struct hostent * remotehostent;
+    struct sockaddr_in remotesocketaddr;
+
+    if (!listening && !connected) {
+        if (!(remotehostent = gethostbyname(host.to_charp()))) {
+    	    return false;
+	}
+
+	remotesocketaddr.sin_family = AF_INET;
+	remotesocketaddr.sin_port = htons(port);
+	bcopy(remotehostent->h_addr, &remotesocketaddr.sin_addr, remotehostent->h_length);
+	if(connect(GetHandle(), (struct sockaddr *)&remotesocketaddr, sizeof(remotesocketaddr)) < 0) {
+	    connected = true;
+	}
+    }
+    return connected;
+}
+
+bool Socket::Listen(void) {
+    if (!listening && !connected) {
+	if (listen(GetHandle(), 10)) {
+	    listening = true;
+	}
+    }
+    return listening;
+}
+
+Socket Socket::Accept(void) {
+    struct sockaddr inaddr;
+    socklen_t inlen = sizeof(inaddr);
+    int h;
+
+    if ((h = accept(GetHandle(), &inaddr, &inlen)) < 0) {
+	return Socket();
+    } else {
+	return Socket(h);
+    }
+}
diff --git a/lib/String.cc b/lib/String.cc
new file mode 100644
index 0000000..16c7db3
--- /dev/null
+++ b/lib/String.cc
@@ -0,0 +1,291 @@
+#include <iostream.h>
+#include <string.h>
+#include <stdarg.h>
+#include "String.h"
+#include "Exceptions.h"
+#include "config.h"
+
+extern "C" {
+    double dateCalc(char *, char *);
+    int isDateArgument(char *);
+}
+
+char String::t[BUFSIZ];
+
+String::String(const String & s) : str(strdup(s.str)) { }
+
+String::String(char c) {
+    char t[2];
+
+    sprintf(t, "%c", c);
+    str = strdup(t);
+}
+
+String::String(const char * s) : str(s ? strdup(s) : strdup("")) { } 
+
+String::String(int i) {
+    char t[20];
+
+    sprintf(t, "%i", i);
+    str = strdup(t);
+}
+
+String::String(double d) {
+    char t[30];
+
+    sprintf(t, "%g", d);
+    str = strdup(t);
+}
+
+String::~String() {
+    free(str);
+}
+
+char * String::set(char * s, ...) {
+    va_list ap;
+
+    va_start(ap, s);
+    vsprintf(t, s, ap);
+    free(str);
+    str = strdup(t);
+    va_end(ap);
+    return t;
+}
+
+char * String::to_charp(size_t from, ssize_t to) const {
+    if (to < 0) {
+	strcpy(t, &(str[from]));
+    } else {
+	if (to >= strlen()) {
+	    to = strlen() - 1;
+	}
+	if (to >= from) {
+	    int i;
+	    for (i = 0; i <= to - from; i++) {
+		t[i] = str[i + from];
+	    }
+	    t[i] = '\0';
+	} else {
+	    t[0] = '\0';
+	}
+    }
+    return t;
+}
+
+int String::to_int(void) const {
+    int r;
+    
+    sscanf(str, "%i", &r);
+    return r;
+}
+
+double String::to_double(void) const {
+    double r;
+    
+    sscanf(str, "%lf", &r);
+    return r;
+}
+
+String & String::operator=(const String & s) {
+    if (str != s.str) {
+	// On évite l'autodestruction...
+	free(str);
+	str = strdup(s.str);
+    }
+    return *this;
+}
+
+String String::operator+(const String & s) const {
+    strcpy(t, str);
+    strcat(t, s.str);
+    return String(t);
+}
+
+String & String::operator+=(const String & s) {
+    strcpy(t, str);
+    strcat(t, s.str);
+    free(str);
+    str = strdup(t);
+    return (*this);
+}
+
+ostream & operator<<(ostream & os, const String & s) {
+    return (os << s.to_charp());
+}
+
+istream & operator>>(istream & is, String & s) {
+    char c;
+
+    s.set("");
+    
+    while (!is.eof()) {
+	is >> c;
+	s += c;
+    }
+    
+    return is;
+}
+
+bool String::operator!=(const String & s) const {
+    return (strcmp(str, s.str) != 0);
+}
+
+bool String::operator==(const String & s) const {
+    return (strcmp(str, s.str) == 0);
+}
+
+bool String::operator<=(const String & s) const {
+    return (strcmp(str, s.str) <= 0);
+}
+
+bool String::operator>=(const String & s) const {
+    return (strcmp(str, s.str) >= 0);
+}
+
+bool String::operator<(const String & s) const {
+    return (strcmp(str, s.str) < 0);
+}
+
+bool String::operator>(const String & s) const {
+    return (strcmp(str, s.str) > 0);
+}
+
+size_t String::strlen() const {
+    return (str ? ::strlen(str) : 0);
+}
+
+char String::operator[](size_t i) const {
+    if (i >= strlen()) {
+	return 0;
+    } else {
+        return str[i];
+    }
+}
+
+ssize_t String::strchr(char c, size_t from) const {
+    size_t s = strlen();
+
+    for (size_t i = from; i < s; i++) {
+	if (str[i] == c) return i;
+    }
+    
+    return -1;
+}
+
+ssize_t String::strrchr(char c) const {
+    size_t s = strlen();
+    
+    for (size_t i = s - 1; i >= 0; i--) {
+	if (str[i] == c) return i;
+    }
+    
+    return -1;
+}
+
+ssize_t String::strstr(const String & s) const {
+    char * p = ::strstr(str, s.str);
+    
+    if (p) {
+        return p - str;
+    } else {
+	return -1;
+    }
+}
+
+int String::strchrcnt(char c) const {
+    size_t i, cnt = 0;
+    size_t s = strlen();
+    
+    for (i = 0; i < s; i++) {
+	if (str[i] == c) cnt++;
+    }
+    
+    return cnt;
+}
+
+String String::to_sqldate(void) const {
+/* DD/MM/YYYY ==> YYYYMMMDD */
+    return (is_date() ? String(to_charp(6, 9)) + to_charp(3, 4) + to_charp(0, 1) : "");
+}
+
+String String::to_sqltime(void) const {
+/* h:m ==> h * 60 + m */
+    int p = strchr(':');
+    return (is_time() ? String(String(to_charp(0, p - 1)).to_int() * 60 + String(to_charp(p + 1)).to_int()) : "");
+}
+
+String String::from_sqldate(void) const {
+/* YYYYMMDD ==> DD/MM/YYYY */
+    return ((strlen() == 8) && is_number() ? String(to_charp(6, 7)) + '/' + to_charp(4, 5) + '/' + to_charp(0, 3) : "");
+}
+
+String String::from_sqltime(void) const {
+/* t ==> (t / 60):(t % 60) */
+    int t = to_int();
+    return (is_number() ? String((int) (t / 60)) + ':' + (t % 60) : "");
+}
+
+bool String::is_date(void) const {
+/* 'DD/MM/YYYY'
+    0123456789 */
+
+    if (strlen() != 10) return false;
+    if ((str[2] != '/') || (str[5] != '/') ||
+        (!String(to_charp(0, 1)).is_number()) ||
+        (!String(to_charp(3, 4)).is_number()) ||
+        (!String(to_charp(6, 9)).is_number())) {
+	return (isDateArgument(to_sqldate().str));
+    }
+
+    return true;
+}
+
+double String::datedif(const String & s) const {
+    double r;
+    if (is_date() && s.is_date()) {
+	r = dateCalc(str, s.str);
+	return r < 0 ? -r : r;
+    }
+    
+    return -1;
+}
+
+bool String::is_number(void) const {
+    size_t s = strlen();
+    
+    
+    for (size_t i = ((str[i] == '-') ? 1 : 0); i < s; i++) {
+	if ((str[i] > '9') || (str[i] < '0')) return false;
+    }
+    return true;
+}
+
+bool String::is_float(void) const {
+    size_t s = strlen();
+    bool seendot = false;
+    
+    for (size_t i = ((str[i] == '-') ? 1 : 0); i < s; i++) {
+	if ((str[i] > '9') || (str[i] < '0')) {
+	    if ((str[i] == '.') && !seendot) {
+		seendot = true;
+	    } else {
+		return false;
+	    }
+	}
+    }
+    
+    return true;
+}
+
+bool String::is_time(void) const {
+    int p = strchr(':');
+    
+    if (p == -1) return false;
+    
+    // On accepte les heures sous le format xxxxxx:yy pour pouvoir indiquer des durées.
+    
+    if ((!String(to_charp(0, p - 1)).is_number()) || (!String(to_charp(p + 1)).is_number()))
+        return false;
+
+    return (String(to_charp(p + 1)).to_int() < 60) ? true : false;
+}
diff --git a/lib/Table.cc b/lib/Table.cc
new file mode 100644
index 0000000..776caae
--- /dev/null
+++ b/lib/Table.cc
@@ -0,0 +1,41 @@
+#include "Table.h"
+#include "HttpServ.h"
+
+Table::Table(const String & titre, const String & url, String * heads, String * cells, int nbc, int nbl, Action * na) :
+    Action(url), tit(titre), hds(heads), cls(cells), nc(nbc), nl(nbl), Next(na) { }
+
+String Table::GetTitle(void) {
+    return tit;
+}
+
+void Table::Do(Variables * v, Handle * h) {
+    SendHead(h);
+    
+    (*h) << "<center><TABLE BORDER=0>" << endnl;
+    
+    if (hds) {
+	(*h) << "<TR>" << endnl;
+	for (int i = 0; i < nc; i++) {
+	    (*h) << "<TH BGCOLOR=\"#bbbbbb\">" << hds[i] << "</TH>" << endnl;
+	}
+	(*h) << "</TR>" << endnl;
+    }
+    
+    for (int l = 0; l < nl; l++) {
+	(*h) << "<TR>" << endnl;
+	for (int c = 0; c < nc; c++) {
+	    (*h) << "<TD BGCOLOR=\"#" << (l % 2 ? "cccccc" : "dddddd") << "\">" << cls[l * nc + c] << "</TD>" << endnl;
+	}
+	(*h) << "</TR>" << endnl;
+    }
+    
+    (*h) << "</TABLE>"
+
+"<FORM METHOD=\"POST\" ACTION=\"/bin/" << (Next ? Next->GetURL() : "start") << "\">" << endnl <<
+"<INPUT TYPE=\"SUBMIT\" VALUE=\"     Ok     \">" << endnl;
+(*h) << "</FORM></CENTER>" << endnl;
+	    
+    
+    SendFoot(h);
+    Accessed();
+}
diff --git a/lib/Variables.cc b/lib/Variables.cc
new file mode 100644
index 0000000..15de09d
--- /dev/null
+++ b/lib/Variables.cc
@@ -0,0 +1,55 @@
+
+#include "Variables.h"
+#include "HttpServ.h"
+#include "String.h"
+#include "config.h"
+
+Variables::Variables(int nb) : Vars(nb ? new String[nb] : 0), nbvars(nb) { }
+
+Variables::~Variables() {
+    if (Vars) {
+	delete[] Vars;
+    }
+}
+
+void Variables::SetTo(int i, const String & s) {
+    Vars[i] = s;
+}
+
+String Variables::operator[](const String & name) {
+    int i;
+    String r;
+    
+    for (i = 0; i < nbvars; i++) {
+        if (Vars[i].strstr(name) == 0) break;
+    }
+    
+    if (i == nbvars) {
+        r = "";
+    } else {
+        r = Vars[i].to_charp(Vars[i].strchr('=') + 1);
+    }
+    
+    return r;
+}
+
+String Variables::operator[](int i) {
+    return Vars[i];
+}
+
+int Variables::GetNb(void) {
+    return nbvars;
+}
+
+void Variables::Dump(Handle * h) {
+    int i, eqp;
+    String Vn, Vv;
+    
+    for (i = 0; i < nbvars; i++) {
+	eqp = Vars[i].strchr('=');
+	Vn = Vars[i].to_charp(0, eqp - 1);
+	Vv = Vars[i].to_charp(eqp + 1);
+	(*h) << "<INPUT TYPE=\"HIDDEN\" NAME=\"" << Vn << "\" VALUE=\"" << Vv << "\">" << endnl;
+    }
+}
+
diff --git a/lib/checkargs.c b/lib/checkargs.c
new file mode 100644
index 0000000..e1c97be
--- /dev/null
+++ b/lib/checkargs.c
@@ -0,0 +1,85 @@
+/*  datedif - calculates the difference in days between two dates
+ *  Copyright (C) 2000 Micael Widell     contact: xeniac@linux.nu
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include <stdlib.h>
+#include <string.h>
+
+int isDateArgument(char* dateString) {
+  
+  const int MONTHS[] = {31,0,31,30,31,30,31,31,30,31,30,31};
+  int i, day, month, year;
+  char buffer[5];
+  
+  /* 'today' is a valid date */ 
+  if (strcmp(dateString, "today") == 0)
+    return 1;
+  
+  /* Numeric dates must be eight characters long */
+  if (8 != strlen(dateString))
+    return 0;
+  
+  /* Check that the date is entirely formed of numbers */
+  for (i = 0; i < 8; i++) {
+    if (dateString[i] < '0' || dateString[i] > '9')
+      return 0;
+  }
+  
+  /* Check that the date exists */
+  memset(buffer, 0, 5);
+  strncpy(buffer, dateString + 6, 2);
+  day = atoi(buffer);
+  strncpy(buffer, dateString + 4, 2); 
+  month = atoi(buffer);
+  month -= 1;
+  strncpy(buffer, dateString, 4);
+  year = atoi(buffer);
+  
+  /* Validate month */
+  if (month < 0 || month > 11)
+    return 0;
+  
+  /* Validating dates is simple when the date does not fall into February */
+  if (1 != month) {
+    if (day < 1 || day > MONTHS[month])
+      return 0;
+  } else {
+    int feb = 28;
+    
+    /* Februarys are a bit tougher issue */
+    if (0 == year % 4) {
+      if (0 == year % 100) {
+	if (0 == year % 400) {
+	  feb = 29;
+	} else {
+	  feb = 28;
+	}
+      } else {
+	feb = 29;
+      }
+    }
+    if (day < 1 || day > feb)
+      return 0;
+  }
+
+  /* Avoid user from using dates before 16000301, since those will result in
+     incorrect output */
+  if(16000301 > atoi(dateString))
+    return 0;
+  
+  return 1;
+}
diff --git a/lib/datecalc.c b/lib/datecalc.c
new file mode 100644
index 0000000..46e7179
--- /dev/null
+++ b/lib/datecalc.c
@@ -0,0 +1,84 @@
+/*  datedif - calculates the difference in days between two dates
+ *  Copyright (C) 2000 Micael Widell     contact: xeniac@linux.nu
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include <time.h>
+#include <stdlib.h>
+#include <string.h>
+
+
+/* Gaus's formula - days since 1.3.1600 (Gregorian calendar) */
+int days(register int n, register int m, register int y)
+{
+  register int cy;
+  if((m -= 2) <= 0){
+    m += 12; y--;
+  }
+  y -= 1600; cy = y/100;
+  return 365*y+y/4-cy+cy/4+367*m/12+n-31;
+}
+
+
+double dateCalc(char date1[], char date2[]){   
+  
+  /* Declare the needed variables */
+  char* date[2] = { date1, date2 };
+  struct tm *date_tm[2]; 
+  time_t date_time_t[2];
+  double dateDifference;
+  int isToday[2] = { 0, 0 };
+  char buffer[5];
+  int day[2], month[2], year[2], i;
+  
+  
+  /* If any of the arguments are "today", then include today's date in the
+     right variables */
+  for(i = 0; i < 2; i++){
+    if(!strcmp(date[i], "today")){
+      time(&date_time_t[i]); 
+      date_tm[i] = localtime(&date_time_t[i]);
+      day[i] = (*date_tm[i]).tm_mday;
+      month[i] = (*date_tm[i]).tm_mon + 1;
+      year[i] = (*date_tm[i]).tm_year + 1900;
+      isToday[i] = 1;
+    }
+  }
+  
+  /* Cut out the year, month and day from 8-digit datestrings */
+  for (i = 0; i < 2; i++){
+    if(!isToday[i]){
+      memset(buffer, 0, 5);
+      strncpy(buffer, &date[i][6], 2);
+      day[i] = atoi(buffer);
+      strncpy(buffer, &date[i][4], 2);
+      month[i] = atoi(buffer);
+      strncpy(buffer, date[i], 4);
+      year[i] = atoi(buffer);       
+    }
+  }
+  
+  /* Calculate the difference */
+  dateDifference = days(day[1], month[1], year[1]) - days(day[0], month[0], year[0]);
+  
+  return dateDifference;
+}
+
+
+
+
+
+
diff --git a/ltconfig b/ltconfig
new file mode 100755
index 0000000..c14d83c
--- /dev/null
+++ b/ltconfig
@@ -0,0 +1,3114 @@
+#! /bin/sh
+
+# ltconfig - Create a system-specific libtool.
+# Copyright (C) 1996-1999 Free Software Foundation, Inc.
+# Originally by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996
+#
+# This file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# A lot of this script is taken from autoconf-2.10.
+
+# Check that we are running under the correct shell.
+SHELL=${CONFIG_SHELL-/bin/sh}
+echo=echo
+if test "X$1" = X--no-reexec; then
+  # Discard the --no-reexec flag, and continue.
+  shift
+elif test "X$1" = X--fallback-echo; then
+  # Avoid inline document here, it may be left over
+  :
+elif test "X`($echo '\t') 2>/dev/null`" = 'X\t'; then
+  # Yippee, $echo works!
+  :
+else
+  # Restart under the correct shell.
+  exec "$SHELL" "$0" --no-reexec ${1+"$@"}
+fi
+
+if test "X$1" = X--fallback-echo; then
+  # used as fallback echo
+  shift
+  cat <<EOF
+$*
+EOF
+  exit 0
+fi
+
+# Find the correct PATH separator.  Usually this is `:', but
+# DJGPP uses `;' like DOS.
+if test "X${PATH_SEPARATOR+set}" != Xset; then
+  UNAME=${UNAME-`uname 2>/dev/null`}
+  case X$UNAME in
+    *-DOS) PATH_SEPARATOR=';' ;;
+    *)     PATH_SEPARATOR=':' ;;
+  esac
+fi
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+if test "X${CDPATH+set}" = Xset; then CDPATH=:; export CDPATH; fi
+
+if test "X${echo_test_string+set}" != Xset; then
+  # find a string as large as possible, as long as the shell can cope with it
+  for cmd in 'sed 50q "$0"' 'sed 20q "$0"' 'sed 10q "$0"' 'sed 2q "$0"' 'echo test'; do
+    # expected sizes: less than 2Kb, 1Kb, 512 bytes, 16 bytes, ...
+    if (echo_test_string="`eval $cmd`") 2>/dev/null &&
+       echo_test_string="`eval $cmd`" &&
+       (test "X$echo_test_string" = "X$echo_test_string") 2>/dev/null; then
+      break
+    fi
+  done
+fi
+
+if test "X`($echo '\t') 2>/dev/null`" != 'X\t' ||
+   test "X`($echo "$echo_test_string") 2>/dev/null`" != X"$echo_test_string"; then
+  # The Solaris, AIX, and Digital Unix default echo programs unquote
+  # backslashes.  This makes it impossible to quote backslashes using
+  #   echo "$something" | sed 's/\\/\\\\/g'
+  #
+  # So, first we look for a working echo in the user's PATH.
+
+  IFS="${IFS= 	}"; save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR}"
+  for dir in $PATH /usr/ucb; do
+    if (test -f $dir/echo || test -f $dir/echo$ac_exeext) &&
+       test "X`($dir/echo '\t') 2>/dev/null`" = 'X\t' &&
+       test "X`($dir/echo "$echo_test_string") 2>/dev/null`" = X"$echo_test_string"; then
+      echo="$dir/echo"
+      break
+    fi
+  done
+  IFS="$save_ifs"
+
+  if test "X$echo" = Xecho; then
+    # We didn't find a better echo, so look for alternatives.
+    if test "X`(print -r '\t') 2>/dev/null`" = 'X\t' &&
+       test "X`(print -r "$echo_test_string") 2>/dev/null`" = X"$echo_test_string"; then
+      # This shell has a builtin print -r that does the trick.
+      echo='print -r'
+    elif (test -f /bin/ksh || test -f /bin/ksh$ac_exeext) &&
+	 test "X$CONFIG_SHELL" != X/bin/ksh; then
+      # If we have ksh, try running ltconfig again with it.
+      ORIGINAL_CONFIG_SHELL="${CONFIG_SHELL-/bin/sh}"
+      export ORIGINAL_CONFIG_SHELL
+      CONFIG_SHELL=/bin/ksh
+      export CONFIG_SHELL
+      exec "$CONFIG_SHELL" "$0" --no-reexec ${1+"$@"}
+    else
+      # Try using printf.
+      echo='printf "%s\n"'
+      if test "X`($echo '\t') 2>/dev/null`" = 'X\t' &&
+	 test "X`($echo "$echo_test_string") 2>/dev/null`" = X"$echo_test_string"; then
+	# Cool, printf works
+	:
+      elif test "X`("$ORIGINAL_CONFIG_SHELL" "$0" --fallback-echo '\t') 2>/dev/null`" = 'X\t' &&
+	   test "X`("$ORIGINAL_CONFIG_SHELL" "$0" --fallback-echo "$echo_test_string") 2>/dev/null`" = X"$echo_test_string"; then
+	CONFIG_SHELL="$ORIGINAL_CONFIG_SHELL"
+	export CONFIG_SHELL
+	SHELL="$CONFIG_SHELL"
+	export SHELL
+	echo="$CONFIG_SHELL $0 --fallback-echo"
+      elif test "X`("$CONFIG_SHELL" "$0" --fallback-echo '\t') 2>/dev/null`" = 'X\t' &&
+	   test "X`("$CONFIG_SHELL" "$0" --fallback-echo "$echo_test_string") 2>/dev/null`" = X"$echo_test_string"; then
+	echo="$CONFIG_SHELL $0 --fallback-echo"
+      else
+	# maybe with a smaller string...
+	prev=:
+
+	for cmd in 'echo test' 'sed 2q "$0"' 'sed 10q "$0"' 'sed 20q "$0"' 'sed 50q "$0"'; do
+	  if (test "X$echo_test_string" = "X`eval $cmd`") 2>/dev/null; then
+	    break
+	  fi
+	  prev="$cmd"
+	done
+
+	if test "$prev" != 'sed 50q "$0"'; then
+	  echo_test_string=`eval $prev`
+	  export echo_test_string
+	  exec "${ORIGINAL_CONFIG_SHELL}" "$0" ${1+"$@"}
+	else
+	  # Oops.  We lost completely, so just stick with echo.
+	  echo=echo
+	fi
+      fi
+    fi
+  fi
+fi
+
+# Sed substitution that helps us do robust quoting.  It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='sed -e s/^X//'
+sed_quote_subst='s/\([\\"\\`$\\\\]\)/\\\1/g'
+
+# Same as above, but do not quote variable references.
+double_quote_subst='s/\([\\"\\`\\\\]\)/\\\1/g'
+
+# Sed substitution to delay expansion of an escaped shell variable in a
+# double_quote_subst'ed string.
+delay_variable_subst='s/\\\\\\\\\\\$/\\\\\\$/g'
+
+# The name of this program.
+progname=`$echo "X$0" | $Xsed -e 's%^.*/%%'`
+
+# Constants:
+PROGRAM=ltconfig
+PACKAGE=libtool
+VERSION=1.3.5
+TIMESTAMP=" (1.385.2.206 2000/05/27 11:12:27)"
+ac_compile='${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5'
+ac_link='${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5'
+rm="rm -f"
+
+help="Try \`$progname --help' for more information."
+
+# Global variables:
+default_ofile=libtool
+can_build_shared=yes
+enable_shared=yes
+# All known linkers require a `.a' archive for static linking (except M$VC,
+# which needs '.lib').
+enable_static=yes
+enable_fast_install=yes
+enable_dlopen=unknown
+enable_win32_dll=no
+ltmain=
+silent=
+srcdir=
+ac_config_guess=
+ac_config_sub=
+host=
+nonopt=
+ofile="$default_ofile"
+verify_host=yes
+with_gcc=no
+with_gnu_ld=no
+need_locks=yes
+ac_ext=c
+objext=o
+libext=a
+exeext=
+cache_file=
+
+old_AR="$AR"
+old_CC="$CC"
+old_CFLAGS="$CFLAGS"
+old_CPPFLAGS="$CPPFLAGS"
+old_LDFLAGS="$LDFLAGS"
+old_LD="$LD"
+old_LN_S="$LN_S"
+old_LIBS="$LIBS"
+old_NM="$NM"
+old_RANLIB="$RANLIB"
+old_DLLTOOL="$DLLTOOL"
+old_OBJDUMP="$OBJDUMP"
+old_AS="$AS"
+
+# Parse the command line options.
+args=
+prev=
+for option
+do
+  case "$option" in
+  -*=*) optarg=`echo "$option" | sed 's/[-_a-zA-Z0-9]*=//'` ;;
+  *) optarg= ;;
+  esac
+
+  # If the previous option needs an argument, assign it.
+  if test -n "$prev"; then
+    eval "$prev=\$option"
+    prev=
+    continue
+  fi
+
+  case "$option" in
+  --help) cat <<EOM
+Usage: $progname [OPTION]... [HOST [LTMAIN]]
+
+Generate a system-specific libtool script.
+
+    --debug                enable verbose shell tracing
+    --disable-shared       do not build shared libraries
+    --disable-static       do not build static libraries
+    --disable-fast-install do not optimize for fast installation
+    --enable-dlopen        enable dlopen support
+    --enable-win32-dll     enable building dlls on win32 hosts
+    --help                 display this help and exit
+    --no-verify            do not verify that HOST is a valid host type
+-o, --output=FILE          specify the output file [default=$default_ofile]
+    --quiet                same as \`--silent'
+    --silent               do not print informational messages
+    --srcdir=DIR           find \`config.guess' in DIR
+    --version              output version information and exit
+    --with-gcc             assume that the GNU C compiler will be used
+    --with-gnu-ld          assume that the C compiler uses the GNU linker
+    --disable-lock         disable file locking
+    --cache-file=FILE      configure cache file
+
+LTMAIN is the \`ltmain.sh' shell script fragment or \`ltmain.c' program
+that provides basic libtool functionality.
+
+HOST is the canonical host system name [default=guessed].
+EOM
+  exit 0
+  ;;
+
+  --debug)
+    echo "$progname: enabling shell trace mode"
+    set -x
+    ;;
+
+  --disable-shared) enable_shared=no ;;
+
+  --disable-static) enable_static=no ;;
+
+  --disable-fast-install) enable_fast_install=no ;;
+
+  --enable-dlopen) enable_dlopen=yes ;;
+
+  --enable-win32-dll) enable_win32_dll=yes ;;
+
+  --quiet | --silent) silent=yes ;;
+
+  --srcdir) prev=srcdir ;;
+  --srcdir=*) srcdir="$optarg" ;;
+
+  --no-verify) verify_host=no ;;
+
+  --output | -o) prev=ofile ;;
+  --output=*) ofile="$optarg" ;;
+
+  --version) echo "$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP"; exit 0 ;;
+
+  --with-gcc) with_gcc=yes ;;
+  --with-gnu-ld) with_gnu_ld=yes ;;
+
+  --disable-lock) need_locks=no ;;
+
+  --cache-file=*) cache_file="$optarg" ;;
+
+  -*)
+    echo "$progname: unrecognized option \`$option'" 1>&2
+    echo "$help" 1>&2
+    exit 1
+    ;;
+
+  *)
+    if test -z "$ltmain"; then
+      ltmain="$option"
+    elif test -z "$host"; then
+# This generates an unnecessary warning for sparc-sun-solaris4.1.3_U1
+#      if test -n "`echo $option| sed 's/[-a-z0-9.]//g'`"; then
+#        echo "$progname: warning \`$option' is not a valid host type" 1>&2
+#      fi
+      host="$option"
+    else
+      echo "$progname: too many arguments" 1>&2
+      echo "$help" 1>&2
+      exit 1
+    fi ;;
+  esac
+done
+
+if test -z "$ltmain"; then
+  echo "$progname: you must specify a LTMAIN file" 1>&2
+  echo "$help" 1>&2
+  exit 1
+fi
+
+if test ! -f "$ltmain"; then
+  echo "$progname: \`$ltmain' does not exist" 1>&2
+  echo "$help" 1>&2
+  exit 1
+fi
+
+# Quote any args containing shell metacharacters.
+ltconfig_args=
+for arg
+do
+  case "$arg" in
+  *" "*|*"	"*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?]*)
+  ltconfig_args="$ltconfig_args '$arg'" ;;
+  *) ltconfig_args="$ltconfig_args $arg" ;;
+  esac
+done
+
+# A relevant subset of AC_INIT.
+
+# File descriptor usage:
+# 0 standard input
+# 1 file creation
+# 2 errors and warnings
+# 3 some systems may open it to /dev/tty
+# 4 used on the Kubota Titan
+# 5 compiler messages saved in config.log
+# 6 checking for... messages and results
+if test "$silent" = yes; then
+  exec 6>/dev/null
+else
+  exec 6>&1
+fi
+exec 5>>./config.log
+
+# NLS nuisances.
+# Only set LANG and LC_ALL to C if already set.
+# These must not be set unconditionally because not all systems understand
+# e.g. LANG=C (notably SCO).
+if test "X${LC_ALL+set}" = Xset; then LC_ALL=C; export LC_ALL; fi
+if test "X${LANG+set}"   = Xset; then LANG=C;   export LANG;   fi
+
+if test -n "$cache_file" && test -r "$cache_file"; then
+  echo "loading cache $cache_file within ltconfig"
+  . $cache_file
+fi
+
+if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
+  # Stardent Vistra SVR4 grep lacks -e, says ghazi@caip.rutgers.edu.
+  if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn >/dev/null; then
+    ac_n= ac_c='
+' ac_t='	'
+  else
+    ac_n=-n ac_c= ac_t=
+  fi
+else
+  ac_n= ac_c='\c' ac_t=
+fi
+
+if test -z "$srcdir"; then
+  # Assume the source directory is the same one as the path to LTMAIN.
+  srcdir=`$echo "X$ltmain" | $Xsed -e 's%/[^/]*$%%'`
+  test "$srcdir" = "$ltmain" && srcdir=.
+fi
+
+trap "$rm conftest*; exit 1" 1 2 15
+if test "$verify_host" = yes; then
+  # Check for config.guess and config.sub.
+  ac_aux_dir=
+  for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
+    if test -f $ac_dir/config.guess; then
+      ac_aux_dir=$ac_dir
+      break
+    fi
+  done
+  if test -z "$ac_aux_dir"; then
+    echo "$progname: cannot find config.guess in $srcdir $srcdir/.. $srcdir/../.." 1>&2
+    echo "$help" 1>&2
+    exit 1
+  fi
+  ac_config_guess=$ac_aux_dir/config.guess
+  ac_config_sub=$ac_aux_dir/config.sub
+
+  # Make sure we can run config.sub.
+  if $SHELL $ac_config_sub sun4 >/dev/null 2>&1; then :
+  else
+    echo "$progname: cannot run $ac_config_sub" 1>&2
+    echo "$help" 1>&2
+    exit 1
+  fi
+
+  echo $ac_n "checking host system type""... $ac_c" 1>&6
+
+  host_alias=$host
+  case "$host_alias" in
+  "")
+    if host_alias=`$SHELL $ac_config_guess`; then :
+    else
+      echo "$progname: cannot guess host type; you must specify one" 1>&2
+      echo "$help" 1>&2
+      exit 1
+    fi ;;
+  esac
+  host=`$SHELL $ac_config_sub $host_alias`
+  echo "$ac_t$host" 1>&6
+
+  # Make sure the host verified.
+  test -z "$host" && exit 1
+
+elif test -z "$host"; then
+  echo "$progname: you must specify a host type if you use \`--no-verify'" 1>&2
+  echo "$help" 1>&2
+  exit 1
+else
+  host_alias=$host
+fi
+
+# Transform linux* to *-*-linux-gnu*, to support old configure scripts.
+case "$host_os" in
+linux-gnu*) ;;
+linux*) host=`echo $host | sed 's/^\(.*-.*-linux\)\(.*\)$/\1-gnu\2/'`
+esac
+
+host_cpu=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\1/'`
+host_vendor=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\2/'`
+host_os=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\3/'`
+
+case "$host_os" in
+aix3*)
+  # AIX sometimes has problems with the GCC collect2 program.  For some
+  # reason, if we set the COLLECT_NAMES environment variable, the problems
+  # vanish in a puff of smoke.
+  if test "X${COLLECT_NAMES+set}" != Xset; then
+    COLLECT_NAMES=
+    export COLLECT_NAMES
+  fi
+  ;;
+esac
+
+# Determine commands to create old-style static archives.
+old_archive_cmds='$AR cru $oldlib$oldobjs'
+old_postinstall_cmds='chmod 644 $oldlib'
+old_postuninstall_cmds=
+
+# Set a sane default for `AR'.
+test -z "$AR" && AR=ar
+
+# Set a sane default for `OBJDUMP'.
+test -z "$OBJDUMP" && OBJDUMP=objdump
+
+# If RANLIB is not set, then run the test.
+if test "${RANLIB+set}" != "set"; then
+  result=no
+
+  echo $ac_n "checking for ranlib... $ac_c" 1>&6
+  IFS="${IFS= 	}"; save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR}"
+  for dir in $PATH; do
+    test -z "$dir" && dir=.
+    if test -f $dir/ranlib || test -f $dir/ranlib$ac_exeext; then
+      RANLIB="ranlib"
+      result="ranlib"
+      break
+    fi
+  done
+  IFS="$save_ifs"
+
+  echo "$ac_t$result" 1>&6
+fi
+
+if test -n "$RANLIB"; then
+  old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
+  old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+fi
+
+# Set sane defaults for `DLLTOOL', `OBJDUMP', and `AS', used on cygwin.
+test -z "$DLLTOOL" && DLLTOOL=dlltool
+test -z "$OBJDUMP" && OBJDUMP=objdump
+test -z "$AS" && AS=as
+
+# Check to see if we are using GCC.
+if test "$with_gcc" != yes || test -z "$CC"; then
+  # If CC is not set, then try to find GCC or a usable CC.
+  if test -z "$CC"; then
+    echo $ac_n "checking for gcc... $ac_c" 1>&6
+    IFS="${IFS= 	}"; save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR}"
+    for dir in $PATH; do
+      test -z "$dir" && dir=.
+      if test -f $dir/gcc || test -f $dir/gcc$ac_exeext; then
+	CC="gcc"
+	break
+      fi
+    done
+    IFS="$save_ifs"
+
+    if test -n "$CC"; then
+      echo "$ac_t$CC" 1>&6
+    else
+      echo "$ac_t"no 1>&6
+    fi
+  fi
+
+  # Not "gcc", so try "cc", rejecting "/usr/ucb/cc".
+  if test -z "$CC"; then
+    echo $ac_n "checking for cc... $ac_c" 1>&6
+    IFS="${IFS= 	}"; save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR}"
+    cc_rejected=no
+    for dir in $PATH; do
+      test -z "$dir" && dir=.
+      if test -f $dir/cc || test -f $dir/cc$ac_exeext; then
+	if test "$dir/cc" = "/usr/ucb/cc"; then
+	  cc_rejected=yes
+	  continue
+	fi
+	CC="cc"
+	break
+      fi
+    done
+    IFS="$save_ifs"
+    if test $cc_rejected = yes; then
+      # We found a bogon in the path, so make sure we never use it.
+      set dummy $CC
+      shift
+      if test $# -gt 0; then
+	# We chose a different compiler from the bogus one.
+	# However, it has the same name, so the bogon will be chosen
+	# first if we set CC to just the name; use the full file name.
+	shift
+	set dummy "$dir/cc" "$@"
+	shift
+	CC="$@"
+      fi
+    fi
+
+    if test -n "$CC"; then
+      echo "$ac_t$CC" 1>&6
+    else
+      echo "$ac_t"no 1>&6
+    fi
+
+    if test -z "$CC"; then
+      echo "$progname: error: no acceptable cc found in \$PATH" 1>&2
+      exit 1
+    fi
+  fi
+
+  # Now see if the compiler is really GCC.
+  with_gcc=no
+  echo $ac_n "checking whether we are using GNU C... $ac_c" 1>&6
+  echo "$progname:581: checking whether we are using GNU C" >&5
+
+  $rm conftest.c
+  cat > conftest.c <<EOF
+#ifdef __GNUC__
+  yes;
+#endif
+EOF
+  if { ac_try='${CC-cc} -E conftest.c'; { (eval echo $progname:589: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
+    with_gcc=yes
+  fi
+  $rm conftest.c
+  echo "$ac_t$with_gcc" 1>&6
+fi
+
+# Allow CC to be a program name with arguments.
+set dummy $CC
+compiler="$2"
+
+echo $ac_n "checking for object suffix... $ac_c" 1>&6
+$rm conftest*
+echo 'int i = 1;' > conftest.c
+echo "$progname:603: checking for object suffix" >& 5
+if { (eval echo $progname:604: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>conftest.err; }; then
+  # Append any warnings to the config.log.
+  cat conftest.err 1>&5
+
+  for ac_file in conftest.*; do
+    case $ac_file in
+    *.c) ;;
+    *) objext=`echo $ac_file | sed -e s/conftest.//` ;;
+    esac
+  done
+else
+  cat conftest.err 1>&5
+  echo "$progname: failed program was:" >&5
+  cat conftest.c >&5
+fi
+$rm conftest*
+echo "$ac_t$objext" 1>&6
+
+echo $ac_n "checking for executable suffix... $ac_c" 1>&6
+if eval "test \"`echo '$''{'ac_cv_exeext'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  ac_cv_exeext="no"
+  $rm conftest*
+  echo 'main () { return 0; }' > conftest.c
+  echo "$progname:629: checking for executable suffix" >& 5
+  if { (eval echo $progname:630: \"$ac_link\") 1>&5; (eval $ac_link) 2>conftest.err; }; then
+    # Append any warnings to the config.log.
+    cat conftest.err 1>&5
+
+    for ac_file in conftest.*; do
+      case $ac_file in
+      *.c | *.err | *.$objext ) ;;
+      *) ac_cv_exeext=.`echo $ac_file | sed -e s/conftest.//` ;;
+      esac
+    done
+  else
+    cat conftest.err 1>&5
+    echo "$progname: failed program was:" >&5
+    cat conftest.c >&5
+  fi
+  $rm conftest*
+fi
+if test "X$ac_cv_exeext" = Xno; then
+  exeext=""
+else
+  exeext="$ac_cv_exeext"
+fi
+echo "$ac_t$ac_cv_exeext" 1>&6
+
+echo $ac_n "checking for $compiler option to produce PIC... $ac_c" 1>&6
+pic_flag=
+special_shlib_compile_flags=
+wl=
+link_static_flag=
+no_builtin_flag=
+
+if test "$with_gcc" = yes; then
+  wl='-Wl,'
+  link_static_flag='-static'
+
+  case "$host_os" in
+  beos* | irix5* | irix6* | osf3* | osf4* | osf5*)
+    # PIC is the default for these OSes.
+    ;;
+  aix*)
+    # Below there is a dirty hack to force normal static linking with -ldl
+    # The problem is because libdl dynamically linked with both libc and
+    # libC (AIX C++ library), which obviously doesn't included in libraries
+    # list by gcc. This cause undefined symbols with -static flags.
+    # This hack allows C programs to be linked with "-static -ldl", but
+    # we not sure about C++ programs.
+    link_static_flag="$link_static_flag ${wl}-lC"
+    ;;
+  cygwin* | mingw* | os2*)
+    # We can build DLLs from non-PIC.
+    ;;
+  amigaos*)
+    # FIXME: we need at least 68020 code to build shared libraries, but
+    # adding the `-m68020' flag to GCC prevents building anything better,
+    # like `-m68040'.
+    pic_flag='-m68020 -resident32 -malways-restore-a4'
+    ;;
+  sysv4*MP*)
+    if test -d /usr/nec; then
+       pic_flag=-Kconform_pic
+    fi
+    ;;
+  *)
+    pic_flag='-fPIC'
+    ;;
+  esac
+else
+  # PORTME Check for PIC flags for the system compiler.
+  case "$host_os" in
+  aix3* | aix4*)
+    # All AIX code is PIC.
+    link_static_flag='-bnso -bI:/lib/syscalls.exp'
+    ;;
+
+  hpux9* | hpux10* | hpux11*)
+    # Is there a better link_static_flag that works with the bundled CC?
+    wl='-Wl,'
+    link_static_flag="${wl}-a ${wl}archive"
+    pic_flag='+Z'
+    ;;
+
+  irix5* | irix6*)
+    wl='-Wl,'
+    link_static_flag='-non_shared'
+    # PIC (with -KPIC) is the default.
+    ;;
+
+  cygwin* | mingw* | os2*)
+    # We can build DLLs from non-PIC.
+    ;;
+
+  osf3* | osf4* | osf5*)
+    # All OSF/1 code is PIC.
+    wl='-Wl,'
+    link_static_flag='-non_shared'
+    ;;
+
+  sco3.2v5*)
+    pic_flag='-Kpic'
+    link_static_flag='-dn'
+    special_shlib_compile_flags='-belf'
+    ;;
+
+  solaris*)
+    pic_flag='-KPIC'
+    link_static_flag='-Bstatic'
+    wl='-Wl,'
+    ;;
+
+  sunos4*)
+    pic_flag='-PIC'
+    link_static_flag='-Bstatic'
+    wl='-Qoption ld '
+    ;;
+
+  sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+    pic_flag='-KPIC'
+    link_static_flag='-Bstatic'
+    wl='-Wl,'
+    ;;
+
+  uts4*)
+    pic_flag='-pic'
+    link_static_flag='-Bstatic'
+    ;;
+  sysv4*MP*)
+    if test -d /usr/nec ;then
+      pic_flag='-Kconform_pic'
+      link_static_flag='-Bstatic'
+    fi
+    ;;
+  *)
+    can_build_shared=no
+    ;;
+  esac
+fi
+
+if test -n "$pic_flag"; then
+  echo "$ac_t$pic_flag" 1>&6
+
+  # Check to make sure the pic_flag actually works.
+  echo $ac_n "checking if $compiler PIC flag $pic_flag works... $ac_c" 1>&6
+  $rm conftest*
+  echo "int some_variable = 0;" > conftest.c
+  save_CFLAGS="$CFLAGS"
+  CFLAGS="$CFLAGS $pic_flag -DPIC"
+  echo "$progname:776: checking if $compiler PIC flag $pic_flag works" >&5
+  if { (eval echo $progname:777: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>conftest.err; } && test -s conftest.$objext; then
+    # Append any warnings to the config.log.
+    cat conftest.err 1>&5
+    
+    case "$host_os" in
+    hpux9* | hpux10* | hpux11*)
+      # On HP-UX, both CC and GCC only warn that PIC is supported... then they
+      # create non-PIC objects.  So, if there were any warnings, we assume that
+      # PIC is not supported.
+      if test -s conftest.err; then
+	echo "$ac_t"no 1>&6
+	can_build_shared=no
+	pic_flag=
+      else
+	echo "$ac_t"yes 1>&6
+	pic_flag=" $pic_flag"
+      fi
+      ;;
+    *)
+      echo "$ac_t"yes 1>&6
+      pic_flag=" $pic_flag"
+      ;;
+    esac
+  else
+    # Append any errors to the config.log.
+    cat conftest.err 1>&5
+    can_build_shared=no
+    pic_flag=
+    echo "$ac_t"no 1>&6
+  fi
+  CFLAGS="$save_CFLAGS"
+  $rm conftest*
+else
+  echo "$ac_t"none 1>&6
+fi
+
+# Check to see if options -o and -c are simultaneously supported by compiler
+echo $ac_n "checking if $compiler supports -c -o file.o... $ac_c" 1>&6
+$rm -r conftest 2>/dev/null
+mkdir conftest
+cd conftest
+$rm conftest*
+echo "int some_variable = 0;" > conftest.c
+mkdir out
+# According to Tom Tromey, Ian Lance Taylor reported there are C compilers
+# that will create temporary files in the current directory regardless of
+# the output directory.  Thus, making CWD read-only will cause this test
+# to fail, enabling locking or at least warning the user not to do parallel
+# builds.
+chmod -w .
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -o out/conftest2.o"
+echo "$progname:829: checking if $compiler supports -c -o file.o" >&5
+if { (eval echo $progname:830: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>out/conftest.err; } && test -s out/conftest2.o; then
+
+  # The compiler can only warn and ignore the option if not recognized
+  # So say no if there are warnings
+    if test -s out/conftest.err; then
+      echo "$ac_t"no 1>&6
+      compiler_c_o=no
+    else
+      echo "$ac_t"yes 1>&6
+      compiler_c_o=yes
+    fi
+else
+  # Append any errors to the config.log.
+  cat out/conftest.err 1>&5
+  compiler_c_o=no
+  echo "$ac_t"no 1>&6
+fi
+CFLAGS="$save_CFLAGS"
+chmod u+w .
+$rm conftest* out/*
+rmdir out
+cd ..
+rmdir conftest
+$rm -r conftest 2>/dev/null
+
+if test x"$compiler_c_o" = x"yes"; then
+  # Check to see if we can write to a .lo
+  echo $ac_n "checking if $compiler supports -c -o file.lo... $ac_c" 1>&6
+  $rm conftest*
+  echo "int some_variable = 0;" > conftest.c
+  save_CFLAGS="$CFLAGS"
+  CFLAGS="$CFLAGS -c -o conftest.lo"
+  echo "$progname:862: checking if $compiler supports -c -o file.lo" >&5
+if { (eval echo $progname:863: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>conftest.err; } && test -s conftest.lo; then
+
+    # The compiler can only warn and ignore the option if not recognized
+    # So say no if there are warnings
+      if test -s conftest.err; then
+	echo "$ac_t"no 1>&6
+	compiler_o_lo=no
+      else
+	echo "$ac_t"yes 1>&6
+	compiler_o_lo=yes
+      fi
+  else
+    # Append any errors to the config.log.
+    cat conftest.err 1>&5
+    compiler_o_lo=no
+    echo "$ac_t"no 1>&6
+  fi
+  CFLAGS="$save_CFLAGS"
+  $rm conftest*
+else
+  compiler_o_lo=no
+fi
+
+# Check to see if we can do hard links to lock some files if needed
+hard_links="nottested"
+if test "$compiler_c_o" = no && test "$need_locks" != no; then
+  # do not overwrite the value of need_locks provided by the user
+  echo $ac_n "checking if we can lock with hard links... $ac_c" 1>&6
+  hard_links=yes
+  $rm conftest*
+  ln conftest.a conftest.b 2>/dev/null && hard_links=no
+  touch conftest.a
+  ln conftest.a conftest.b 2>&5 || hard_links=no
+  ln conftest.a conftest.b 2>/dev/null && hard_links=no
+  echo "$ac_t$hard_links" 1>&6
+  $rm conftest*
+  if test "$hard_links" = no; then
+    echo "*** WARNING: \`$CC' does not support \`-c -o', so \`make -j' may be unsafe" >&2
+    need_locks=warn
+  fi
+else
+  need_locks=no
+fi
+
+if test "$with_gcc" = yes; then
+  # Check to see if options -fno-rtti -fno-exceptions are supported by compiler
+  echo $ac_n "checking if $compiler supports -fno-rtti -fno-exceptions ... $ac_c" 1>&6
+  $rm conftest*
+  echo "int some_variable = 0;" > conftest.c
+  save_CFLAGS="$CFLAGS"
+  CFLAGS="$CFLAGS -fno-rtti -fno-exceptions -c conftest.c"
+  echo "$progname:914: checking if $compiler supports -fno-rtti -fno-exceptions" >&5
+  if { (eval echo $progname:915: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>conftest.err; } && test -s conftest.o; then
+
+    # The compiler can only warn and ignore the option if not recognized
+    # So say no if there are warnings
+      if test -s conftest.err; then
+	echo "$ac_t"no 1>&6
+	compiler_rtti_exceptions=no
+      else
+	echo "$ac_t"yes 1>&6
+	compiler_rtti_exceptions=yes
+      fi
+  else
+    # Append any errors to the config.log.
+    cat conftest.err 1>&5
+    compiler_rtti_exceptions=no
+    echo "$ac_t"no 1>&6
+  fi
+  CFLAGS="$save_CFLAGS"
+  $rm conftest*
+
+  if test "$compiler_rtti_exceptions" = "yes"; then
+    no_builtin_flag=' -fno-builtin -fno-rtti -fno-exceptions'
+  else
+    no_builtin_flag=' -fno-builtin'
+  fi
+  
+fi
+
+# Check for any special shared library compilation flags.
+if test -n "$special_shlib_compile_flags"; then
+  echo "$progname: warning: \`$CC' requires \`$special_shlib_compile_flags' to build shared libraries" 1>&2
+  if echo "$old_CC $old_CFLAGS " | egrep -e "[ 	]$special_shlib_compile_flags[ 	]" >/dev/null; then :
+  else
+    echo "$progname: add \`$special_shlib_compile_flags' to the CC or CFLAGS env variable and reconfigure" 1>&2
+    can_build_shared=no
+  fi
+fi
+
+echo $ac_n "checking if $compiler static flag $link_static_flag works... $ac_c" 1>&6
+$rm conftest*
+echo 'main(){return(0);}' > conftest.c
+save_LDFLAGS="$LDFLAGS"
+LDFLAGS="$LDFLAGS $link_static_flag"
+echo "$progname:958: checking if $compiler static flag $link_static_flag works" >&5
+if { (eval echo $progname:959: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+  echo "$ac_t$link_static_flag" 1>&6
+else
+  echo "$ac_t"none 1>&6
+  link_static_flag=
+fi
+LDFLAGS="$save_LDFLAGS"
+$rm conftest*
+
+if test -z "$LN_S"; then
+  # Check to see if we can use ln -s, or we need hard links.
+  echo $ac_n "checking whether ln -s works... $ac_c" 1>&6
+  $rm conftest.dat
+  if ln -s X conftest.dat 2>/dev/null; then
+    $rm conftest.dat
+    LN_S="ln -s"
+  else
+    LN_S=ln
+  fi
+  if test "$LN_S" = "ln -s"; then
+    echo "$ac_t"yes 1>&6
+  else
+    echo "$ac_t"no 1>&6
+  fi
+fi
+
+# Make sure LD is an absolute path.
+if test -z "$LD"; then
+  ac_prog=ld
+  if test "$with_gcc" = yes; then
+    # Check if gcc -print-prog-name=ld gives a path.
+    echo $ac_n "checking for ld used by GCC... $ac_c" 1>&6
+    echo "$progname:991: checking for ld used by GCC" >&5
+    ac_prog=`($CC -print-prog-name=ld) 2>&5`
+    case "$ac_prog" in
+    # Accept absolute paths.
+    [\\/]* | [A-Za-z]:[\\/]*)
+      re_direlt='/[^/][^/]*/\.\./'
+      # Canonicalize the path of ld
+      ac_prog=`echo $ac_prog| sed 's%\\\\%/%g'`
+      while echo $ac_prog | grep "$re_direlt" > /dev/null 2>&1; do
+	ac_prog=`echo $ac_prog| sed "s%$re_direlt%/%"`
+      done
+      test -z "$LD" && LD="$ac_prog"
+      ;;
+    "")
+      # If it fails, then pretend we are not using GCC.
+      ac_prog=ld
+      ;;
+    *)
+      # If it is relative, then search for the first ld in PATH.
+      with_gnu_ld=unknown
+      ;;
+    esac
+  elif test "$with_gnu_ld" = yes; then
+    echo $ac_n "checking for GNU ld... $ac_c" 1>&6
+    echo "$progname:1015: checking for GNU ld" >&5
+  else
+    echo $ac_n "checking for non-GNU ld""... $ac_c" 1>&6
+    echo "$progname:1018: checking for non-GNU ld" >&5
+  fi
+
+  if test -z "$LD"; then
+    IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR}"
+    for ac_dir in $PATH; do
+      test -z "$ac_dir" && ac_dir=.
+      if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
+	LD="$ac_dir/$ac_prog"
+	# Check to see if the program is GNU ld.  I'd rather use --version,
+	# but apparently some GNU ld's only accept -v.
+	# Break only if it was the GNU/non-GNU ld that we prefer.
+	if "$LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > /dev/null; then
+	  test "$with_gnu_ld" != no && break
+	else
+	  test "$with_gnu_ld" != yes && break
+	fi
+      fi
+    done
+    IFS="$ac_save_ifs"
+  fi
+
+  if test -n "$LD"; then
+    echo "$ac_t$LD" 1>&6
+  else
+    echo "$ac_t"no 1>&6
+  fi
+
+  if test -z "$LD"; then
+    echo "$progname: error: no acceptable ld found in \$PATH" 1>&2
+    exit 1
+  fi
+fi
+
+# Check to see if it really is or is not GNU ld.
+echo $ac_n "checking if the linker ($LD) is GNU ld... $ac_c" 1>&6
+# I'd rather use --version here, but apparently some GNU ld's only accept -v.
+if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then
+  with_gnu_ld=yes
+else
+  with_gnu_ld=no
+fi
+echo "$ac_t$with_gnu_ld" 1>&6
+
+# See if the linker supports building shared libraries.
+echo $ac_n "checking whether the linker ($LD) supports shared libraries... $ac_c" 1>&6
+
+allow_undefined_flag=
+no_undefined_flag=
+need_lib_prefix=unknown
+need_version=unknown
+# when you set need_version to no, make sure it does not cause -set_version
+# flags to be left without arguments
+archive_cmds=
+archive_expsym_cmds=
+old_archive_from_new_cmds=
+export_dynamic_flag_spec=
+whole_archive_flag_spec=
+thread_safe_flag_spec=
+hardcode_libdir_flag_spec=
+hardcode_libdir_separator=
+hardcode_direct=no
+hardcode_minus_L=no
+hardcode_shlibpath_var=unsupported
+runpath_var=
+always_export_symbols=no
+export_symbols_cmds='$NM $libobjs $convenience | $global_symbol_pipe | sed '\''s/.* //'\'' | sort | uniq > $export_symbols'
+# include_expsyms should be a list of space-separated symbols to be *always*
+# included in the symbol list
+include_expsyms=
+# exclude_expsyms can be an egrep regular expression of symbols to exclude
+# it will be wrapped by ` (' and `)$', so one must not match beginning or
+# end of line.  Example: `a|bc|.*d.*' will exclude the symbols `a' and `bc',
+# as well as any symbol that contains `d'.
+exclude_expsyms="_GLOBAL_OFFSET_TABLE_"
+# Although _GLOBAL_OFFSET_TABLE_ is a valid symbol C name, most a.out
+# platforms (ab)use it in PIC code, but their linkers get confused if
+# the symbol is explicitly referenced.  Since portable code cannot
+# rely on this symbol name, it's probably fine to never include it in
+# preloaded symbol tables.
+
+case "$host_os" in
+cygwin* | mingw*)
+  # FIXME: the MSVC++ port hasn't been tested in a loooong time
+  # When not using gcc, we currently assume that we are using
+  # Microsoft Visual C++.
+  if test "$with_gcc" != yes; then
+    with_gnu_ld=no
+  fi
+  ;;
+
+esac
+
+ld_shlibs=yes
+if test "$with_gnu_ld" = yes; then
+  # If archive_cmds runs LD, not CC, wlarc should be empty
+  wlarc='${wl}'
+
+  # See if GNU ld supports shared libraries.
+  case "$host_os" in
+  aix3* | aix4*)
+    # On AIX, the GNU linker is very broken
+    ld_shlibs=no
+    cat <<EOF 1>&2
+
+*** Warning: the GNU linker, at least up to release 2.9.1, is reported
+*** to be unable to reliably create shared libraries on AIX.
+*** Therefore, libtool is disabling shared libraries support.  If you
+*** really care for shared libraries, you may want to modify your PATH
+*** so that a non-GNU linker is found, and then restart.
+
+EOF
+    ;;
+
+  amigaos*)
+    archive_cmds='$rm $objdir/a2ixlibrary.data~$echo "#define NAME $libname" > $objdir/a2ixlibrary.data~$echo "#define LIBRARY_ID 1" >> $objdir/a2ixlibrary.data~$echo "#define VERSION $major" >> $objdir/a2ixlibrary.data~$echo "#define REVISION $revision" >> $objdir/a2ixlibrary.data~$AR cru $lib $libobjs~$RANLIB $lib~(cd $objdir && a2ixlibrary -32)'
+    hardcode_libdir_flag_spec='-L$libdir'
+    hardcode_minus_L=yes
+
+    # Samuel A. Falvo II <kc5tja@dolphin.openprojects.net> reports
+    # that the semantics of dynamic libraries on AmigaOS, at least up
+    # to version 4, is to share data among multiple programs linked
+    # with the same dynamic library.  Since this doesn't match the
+    # behavior of shared libraries on other platforms, we can use
+    # them.
+    ld_shlibs=no
+    ;;
+
+  beos*)
+    if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+      allow_undefined_flag=unsupported
+      # Joseph Beckenbach <jrb3@best.com> says some releases of gcc
+      # support --undefined.  This deserves some investigation.  FIXME
+      archive_cmds='$CC -nostart $libobjs $deplibs $linkopts ${wl}-soname $wl$soname -o $lib'
+    else
+      ld_shlibs=no
+    fi
+    ;;
+
+  cygwin* | mingw*)
+    # hardcode_libdir_flag_spec is actually meaningless, as there is
+    # no search path for DLLs.
+    hardcode_libdir_flag_spec='-L$libdir'
+    allow_undefined_flag=unsupported
+    always_export_symbols=yes
+
+    # Extract the symbol export list from an `--export-all' def file,
+    # then regenerate the def file from the symbol export list, so that
+    # the compiled dll only exports the symbol export list.
+    # Be careful not to strip the DATA tag left by newer dlltools.
+    export_symbols_cmds='test -f $objdir/$soname-ltdll.c || sed -e "/^# \/\* ltdll\.c starts here \*\//,/^# \/\* ltdll.c ends here \*\// { s/^# //; p; }" -e d < $0 > $objdir/$soname-ltdll.c~
+      test -f $objdir/$soname-ltdll.$objext || (cd $objdir && $CC -c $soname-ltdll.c)~
+      $DLLTOOL --export-all --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --output-def $objdir/$soname-def  $objdir/$soname-ltdll.$objext $libobjs $convenience~
+      sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//" < $objdir/$soname-def > $export_symbols'
+
+    # If DATA tags from a recent dlltool are present, honour them!
+    archive_expsym_cmds='echo EXPORTS > $objdir/$soname-def~
+      _lt_hint=1;
+      cat $export_symbols | while read symbol; do
+        set dummy \$symbol;
+        case \$# in
+          2) echo "	\$2 @ \$_lt_hint ; " >> $objdir/$soname-def;;
+          *) echo "     \$2 @ \$_lt_hint \$3 ; " >> $objdir/$soname-def;;
+        esac;
+	_lt_hint=`expr 1 + \$_lt_hint`;
+      done~
+      test -f $objdir/$soname-ltdll.c || sed -e "/^# \/\* ltdll\.c starts here \*\//,/^# \/\* ltdll.c ends here \*\// { s/^# //; p; }" -e d < $0 > $objdir/$soname-ltdll.c~
+      test -f $objdir/$soname-ltdll.$objext || (cd $objdir && $CC -c $soname-ltdll.c)~
+      $CC -Wl,--base-file,$objdir/$soname-base -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o $lib $objdir/$soname-ltdll.$objext $libobjs $deplibs $linkopts~
+      $DLLTOOL --as=$AS --dllname $soname --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --def $objdir/$soname-def --base-file $objdir/$soname-base --output-exp $objdir/$soname-exp~
+      $CC -Wl,--base-file,$objdir/$soname-base $objdir/$soname-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o $lib $objdir/$soname-ltdll.$objext $libobjs $deplibs $linkopts~
+      $DLLTOOL --as=$AS --dllname $soname --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --def $objdir/$soname-def --base-file $objdir/$soname-base --output-exp $objdir/$soname-exp~
+      $CC $objdir/$soname-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o $lib $objdir/$soname-ltdll.$objext $libobjs $deplibs $linkopts'
+
+      old_archive_from_new_cmds='$DLLTOOL --as=$AS --dllname $soname --def $objdir/$soname-def --output-lib $objdir/$libname.a' 
+    ;;
+
+  netbsd*)
+    if echo __ELF__ | $CC -E - | grep __ELF__ >/dev/null; then
+      archive_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname $wl$soname -o $lib'
+      archive_expsym_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+    else
+      archive_cmds='$LD -Bshareable $libobjs $deplibs $linkopts -o $lib'
+      # can we support soname and/or expsyms with a.out? -oliva
+    fi
+    ;;
+
+  solaris* | sysv5*)
+    if $LD -v 2>&1 | egrep 'BFD 2\.8' > /dev/null; then
+      ld_shlibs=no
+      cat <<EOF 1>&2
+
+*** Warning: The releases 2.8.* of the GNU linker cannot reliably
+*** create shared libraries on Solaris systems.  Therefore, libtool
+*** is disabling shared libraries support.  We urge you to upgrade GNU
+*** binutils to release 2.9.1 or newer.  Another option is to modify
+*** your PATH or compiler configuration so that the native linker is
+*** used, and then restart.
+
+EOF
+    elif $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+      archive_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname $wl$soname -o $lib'
+      archive_expsym_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+    else
+      ld_shlibs=no
+    fi
+    ;;      
+
+  sunos4*)
+    archive_cmds='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linkopts'
+    wlarc=
+    hardcode_direct=yes
+    hardcode_shlibpath_var=no
+    ;;
+
+  *)
+    if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+      archive_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname $wl$soname -o $lib'
+      archive_expsym_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+    else
+      ld_shlibs=no
+    fi
+    ;;
+  esac
+
+  if test "$ld_shlibs" = yes; then
+    runpath_var=LD_RUN_PATH
+    hardcode_libdir_flag_spec='${wl}--rpath ${wl}$libdir'
+    export_dynamic_flag_spec='${wl}--export-dynamic'
+    case $host_os in
+    cygwin* | mingw*)
+      # dlltool doesn't understand --whole-archive et. al.
+      whole_archive_flag_spec=
+      ;;
+    *)
+      # ancient GNU ld didn't support --whole-archive et. al.
+      if $LD --help 2>&1 | egrep 'no-whole-archive' > /dev/null; then
+        whole_archive_flag_spec="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
+      else
+        whole_archive_flag_spec=
+      fi
+      ;;
+    esac
+  fi
+else
+  # PORTME fill in a description of your system's linker (not GNU ld)
+  case "$host_os" in
+  aix3*)
+    allow_undefined_flag=unsupported
+    always_export_symbols=yes
+    archive_expsym_cmds='$LD -o $objdir/$soname $libobjs $deplibs $linkopts -bE:$export_symbols -T512 -H512 -bM:SRE~$AR cru $lib $objdir/$soname'
+    # Note: this linker hardcodes the directories in LIBPATH if there
+    # are no directories specified by -L.
+    hardcode_minus_L=yes
+    if test "$with_gcc" = yes && test -z "$link_static_flag"; then
+      # Neither direct hardcoding nor static linking is supported with a
+      # broken collect2.
+      hardcode_direct=unsupported
+    fi
+    ;;
+
+  aix4*)
+    hardcode_libdir_flag_spec='${wl}-b ${wl}nolibpath ${wl}-b ${wl}libpath:$libdir:/usr/lib:/lib'
+    hardcode_libdir_separator=':'
+    if test "$with_gcc" = yes; then
+      collect2name=`${CC} -print-prog-name=collect2`
+      if test -f "$collect2name" && \
+	 strings "$collect2name" | grep resolve_lib_name >/dev/null
+      then
+	# We have reworked collect2
+	hardcode_direct=yes
+      else
+	# We have old collect2
+	hardcode_direct=unsupported
+	# It fails to find uninstalled libraries when the uninstalled
+	# path is not listed in the libpath.  Setting hardcode_minus_L
+	# to unsupported forces relinking
+	hardcode_minus_L=yes
+	hardcode_libdir_flag_spec='-L$libdir'
+	hardcode_libdir_separator=
+      fi
+      shared_flag='-shared'
+    else
+      shared_flag='${wl}-bM:SRE'
+      hardcode_direct=yes
+    fi
+    allow_undefined_flag=' ${wl}-berok'
+    archive_cmds="\$CC $shared_flag"' -o $objdir/$soname $libobjs $deplibs $linkopts ${wl}-bexpall ${wl}-bnoentry${allow_undefined_flag}'
+    archive_expsym_cmds="\$CC $shared_flag"' -o $objdir/$soname $libobjs $deplibs $linkopts ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}'
+    case "$host_os" in aix4.[01]|aix4.[01].*)
+      # According to Greg Wooledge, -bexpall is only supported from AIX 4.2 on
+      always_export_symbols=yes ;;
+    esac
+   ;;
+
+  amigaos*)
+    archive_cmds='$rm $objdir/a2ixlibrary.data~$echo "#define NAME $libname" > $objdir/a2ixlibrary.data~$echo "#define LIBRARY_ID 1" >> $objdir/a2ixlibrary.data~$echo "#define VERSION $major" >> $objdir/a2ixlibrary.data~$echo "#define REVISION $revision" >> $objdir/a2ixlibrary.data~$AR cru $lib $libobjs~$RANLIB $lib~(cd $objdir && a2ixlibrary -32)'
+    hardcode_libdir_flag_spec='-L$libdir'
+    hardcode_minus_L=yes
+    # see comment about different semantics on the GNU ld section
+    ld_shlibs=no
+    ;;
+
+  cygwin* | mingw*)
+    # When not using gcc, we currently assume that we are using
+    # Microsoft Visual C++.
+    # hardcode_libdir_flag_spec is actually meaningless, as there is
+    # no search path for DLLs.
+    hardcode_libdir_flag_spec=' '
+    allow_undefined_flag=unsupported
+    # Tell ltmain to make .lib files, not .a files.
+    libext=lib
+    # FIXME: Setting linknames here is a bad hack.
+    archive_cmds='$CC -o $lib $libobjs $linkopts `echo "$deplibs" | sed -e '\''s/ -lc$//'\''` -link -dll~linknames='
+    # The linker will automatically build a .lib file if we build a DLL.
+    old_archive_from_new_cmds='true'
+    # FIXME: Should let the user specify the lib program.
+    old_archive_cmds='lib /OUT:$oldlib$oldobjs'
+    fix_srcfile_path='`cygpath -w $srcfile`'
+    ;;
+
+  freebsd1*)
+    ld_shlibs=no
+    ;;
+
+  # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
+  # support.  Future versions do this automatically, but an explicit c++rt0.o
+  # does not break anything, and helps significantly (at the cost of a little
+  # extra space).
+  freebsd2.2*)
+    archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linkopts /usr/lib/c++rt0.o'
+    hardcode_libdir_flag_spec='-R$libdir'
+    hardcode_direct=yes
+    hardcode_shlibpath_var=no
+    ;;
+
+  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
+  freebsd2*)
+    archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linkopts'
+    hardcode_direct=yes
+    hardcode_minus_L=yes
+    hardcode_shlibpath_var=no
+    ;;
+
+  # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
+  freebsd*)
+    archive_cmds='$CC -shared -o $lib $libobjs $deplibs $linkopts'
+    hardcode_libdir_flag_spec='-R$libdir'
+    hardcode_direct=yes
+    hardcode_shlibpath_var=no
+    ;;
+
+  hpux9* | hpux10* | hpux11*)
+    case "$host_os" in
+    hpux9*) archive_cmds='$rm $objdir/$soname~$LD -b +b $install_libdir -o $objdir/$soname $libobjs $deplibs $linkopts~test $objdir/$soname = $lib || mv $objdir/$soname $lib' ;;
+    *) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linkopts' ;;
+    esac
+    hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+    hardcode_libdir_separator=:
+    hardcode_direct=yes
+    hardcode_minus_L=yes # Not in the search PATH, but as the default
+			 # location of the library.
+    export_dynamic_flag_spec='${wl}-E'
+    ;;
+
+  irix5* | irix6*)
+    if test "$with_gcc" = yes; then
+      archive_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+    else
+      archive_cmds='$LD -shared $libobjs $deplibs $linkopts -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+    fi
+    hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
+    hardcode_libdir_separator=:
+    ;;
+
+  netbsd*)
+    if echo __ELF__ | $CC -E - | grep __ELF__ >/dev/null; then
+      archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linkopts'  # a.out
+    else
+      archive_cmds='$LD -shared -o $lib $libobjs $deplibs $linkopts'      # ELF
+    fi
+    hardcode_libdir_flag_spec='${wl}-R$libdir'
+    hardcode_direct=yes
+    hardcode_shlibpath_var=no
+    ;;
+
+  openbsd*)
+    archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linkopts'
+    hardcode_libdir_flag_spec='-R$libdir'
+    hardcode_direct=yes
+    hardcode_shlibpath_var=no
+    ;;
+
+  os2*)
+    hardcode_libdir_flag_spec='-L$libdir'
+    hardcode_minus_L=yes
+    allow_undefined_flag=unsupported
+    archive_cmds='$echo "LIBRARY $libname INITINSTANCE" > $objdir/$libname.def~$echo "DESCRIPTION \"$libname\"" >> $objdir/$libname.def~$echo DATA >> $objdir/$libname.def~$echo " SINGLE NONSHARED" >> $objdir/$libname.def~$echo EXPORTS >> $objdir/$libname.def~emxexp $libobjs >> $objdir/$libname.def~$CC -Zdll -Zcrtdll -o $lib $libobjs $deplibs $linkopts $objdir/$libname.def'
+    old_archive_from_new_cmds='emximp -o $objdir/$libname.a $objdir/$libname.def'
+    ;;
+
+  osf3*)
+    if test "$with_gcc" = yes; then
+      allow_undefined_flag=' ${wl}-expect_unresolved ${wl}\*'
+      archive_cmds='$CC -shared${allow_undefined_flag} $libobjs $deplibs $linkopts ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+    else
+      allow_undefined_flag=' -expect_unresolved \*'
+      archive_cmds='$LD -shared${allow_undefined_flag} $libobjs $deplibs $linkopts -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+    fi
+    hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
+    hardcode_libdir_separator=:
+    ;;
+
+  osf4* | osf5*)  # As osf3* with the addition of the -msym flag
+    if test "$with_gcc" = yes; then
+      allow_undefined_flag=' ${wl}-expect_unresolved ${wl}\*'
+      archive_cmds='$CC -shared${allow_undefined_flag} $libobjs $deplibs $linkopts ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+    else
+      allow_undefined_flag=' -expect_unresolved \*'
+      archive_cmds='$LD -shared${allow_undefined_flag} $libobjs $deplibs $linkopts -msym -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+    fi
+    hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
+    hardcode_libdir_separator=:
+    ;;
+  rhapsody*)
+    archive_cmds='$CC -bundle -undefined suppress -o $lib $libobjs $deplibs $linkopts'
+    hardcode_libdir_flags_spec='-L$libdir'
+    hardcode_direct=yes
+    hardcode_shlibpath_var=no
+    ;;
+                                       
+  sco3.2v5*)
+    archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+    hardcode_shlibpath_var=no
+    runpath_var=LD_RUN_PATH
+    hardcode_runpath_var=yes
+    ;;
+
+  solaris*)
+    no_undefined_flag=' -z text'
+    # $CC -shared without GNU ld will not create a library from C++
+    # object files and a static libstdc++, better avoid it by now
+    archive_cmds='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linkopts'
+    archive_expsym_cmds='$echo "{ global:" > $lib.exp~cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
+		$LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linkopts~$rm $lib.exp'
+    hardcode_libdir_flag_spec='-R$libdir'
+    hardcode_shlibpath_var=no
+    case "$host_os" in
+    solaris2.[0-5] | solaris2.[0-5].*) ;;
+    *) # Supported since Solaris 2.6 (maybe 2.5.1?)
+      whole_archive_flag_spec='-z allextract$convenience -z defaultextract' ;;
+    esac
+    ;;
+
+  sunos4*)
+    archive_cmds='$LD -assert pure-text -Bstatic -o $lib $libobjs $deplibs $linkopts'
+    hardcode_libdir_flag_spec='-L$libdir'
+    hardcode_direct=yes
+    hardcode_minus_L=yes
+    hardcode_shlibpath_var=no
+    ;;
+
+  sysv4)
+    if test "x$host_vendor" = xsequent; then
+      # Use $CC to link under sequent, because it throws in some extra .o 
+      # files that make .init and .fini sections work.
+      archive_cmds='$CC -G ${wl}-h $soname -o $lib $libobjs $deplibs $linkopts'
+    else
+      archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+    fi
+    runpath_var='LD_RUN_PATH'
+    hardcode_shlibpath_var=no
+    hardcode_direct=no #Motorola manual says yes, but my tests say they lie 
+    ;;  
+
+  sysv4.3*)
+    archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+    hardcode_shlibpath_var=no
+    export_dynamic_flag_spec='-Bexport'
+    ;;
+
+  sysv5*)
+    no_undefined_flag=' -z text'
+    # $CC -shared without GNU ld will not create a library from C++
+    # object files and a static libstdc++, better avoid it by now
+    archive_cmds='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linkopts'
+    archive_expsym_cmds='$echo "{ global:" > $lib.exp~cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
+		$LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linkopts~$rm $lib.exp'
+    hardcode_libdir_flag_spec=
+    hardcode_shlibpath_var=no
+    runpath_var='LD_RUN_PATH'
+    ;;
+
+  uts4*)
+    archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+    hardcode_libdir_flag_spec='-L$libdir'
+    hardcode_shlibpath_var=no
+    ;;
+
+  dgux*)
+    archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+    hardcode_libdir_flag_spec='-L$libdir'
+    hardcode_shlibpath_var=no
+    ;;
+
+  sysv4*MP*)
+    if test -d /usr/nec; then
+      archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+      hardcode_shlibpath_var=no
+      runpath_var=LD_RUN_PATH
+      hardcode_runpath_var=yes
+      ld_shlibs=yes
+    fi
+    ;;
+
+  sysv4.2uw2*)
+    archive_cmds='$LD -G -o $lib $libobjs $deplibs $linkopts'
+    hardcode_direct=yes
+    hardcode_minus_L=no
+    hardcode_shlibpath_var=no
+    hardcode_runpath_var=yes
+    runpath_var=LD_RUN_PATH
+    ;;
+
+  unixware7*)
+    archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+    runpath_var='LD_RUN_PATH'
+    hardcode_shlibpath_var=no
+    ;;
+
+  *)
+    ld_shlibs=no
+    ;;
+  esac
+fi
+echo "$ac_t$ld_shlibs" 1>&6
+test "$ld_shlibs" = no && can_build_shared=no
+
+if test -z "$NM"; then
+  echo $ac_n "checking for BSD-compatible nm... $ac_c" 1>&6
+  case "$NM" in
+  [\\/]* | [A-Za-z]:[\\/]*) ;; # Let the user override the test with a path.
+  *)
+    IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR}"
+    for ac_dir in $PATH /usr/ucb /usr/ccs/bin /bin; do
+      test -z "$ac_dir" && ac_dir=.
+      if test -f $ac_dir/nm || test -f $ac_dir/nm$ac_exeext; then
+	# Check to see if the nm accepts a BSD-compat flag.
+	# Adding the `sed 1q' prevents false positives on HP-UX, which says:
+	#   nm: unknown option "B" ignored
+	if ($ac_dir/nm -B /dev/null 2>&1 | sed '1q'; exit 0) | egrep /dev/null >/dev/null; then
+	  NM="$ac_dir/nm -B"
+	  break
+	elif ($ac_dir/nm -p /dev/null 2>&1 | sed '1q'; exit 0) | egrep /dev/null >/dev/null; then
+	  NM="$ac_dir/nm -p"
+	  break
+	else
+	  NM=${NM="$ac_dir/nm"} # keep the first match, but
+	  continue # so that we can try to find one that supports BSD flags
+	fi
+      fi
+    done
+    IFS="$ac_save_ifs"
+    test -z "$NM" && NM=nm
+    ;;
+  esac
+  echo "$ac_t$NM" 1>&6
+fi
+
+# Check for command to grab the raw symbol name followed by C symbol from nm.
+echo $ac_n "checking command to parse $NM output... $ac_c" 1>&6
+
+# These are sane defaults that work on at least a few old systems.
+# [They come from Ultrix.  What could be older than Ultrix?!! ;)]
+
+# Character class describing NM global symbol codes.
+symcode='[BCDEGRST]'
+
+# Regexp to match symbols that can be accessed directly from C.
+sympat='\([_A-Za-z][_A-Za-z0-9]*\)'
+
+# Transform the above into a raw symbol and a C symbol.
+symxfrm='\1 \2\3 \3'
+
+# Transform an extracted symbol line into a proper C declaration
+global_symbol_to_cdecl="sed -n -e 's/^. .* \(.*\)$/extern char \1;/p'"
+
+# Define system-specific variables.
+case "$host_os" in
+aix*)
+  symcode='[BCDT]'
+  ;;
+cygwin* | mingw*)
+  symcode='[ABCDGISTW]'
+  ;;
+hpux*) # Its linker distinguishes data from code symbols
+  global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern char \1();/p' -e 's/^. .* \(.*\)$/extern char \1;/p'"
+  ;;
+irix*)
+  symcode='[BCDEGRST]'
+  ;;
+solaris*)
+  symcode='[BDT]'
+  ;;
+sysv4)
+  symcode='[DFNSTU]'
+  ;;
+esac
+
+# If we're using GNU nm, then use its standard symbol codes.
+if $NM -V 2>&1 | egrep '(GNU|with BFD)' > /dev/null; then
+  symcode='[ABCDGISTW]'
+fi
+
+# Try without a prefix undercore, then with it.
+for ac_symprfx in "" "_"; do
+
+  # Write the raw and C identifiers.
+  global_symbol_pipe="sed -n -e 's/^.*[ 	]\($symcode\)[ 	][ 	]*\($ac_symprfx\)$sympat$/$symxfrm/p'"
+
+  # Check to see that the pipe works correctly.
+  pipe_works=no
+  $rm conftest*
+  cat > conftest.c <<EOF
+#ifdef __cplusplus
+extern "C" {
+#endif
+char nm_test_var;
+void nm_test_func(){}
+#ifdef __cplusplus
+}
+#endif
+main(){nm_test_var='a';nm_test_func();return(0);}
+EOF
+
+  echo "$progname:1653: checking if global_symbol_pipe works" >&5
+  if { (eval echo $progname:1654: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; } && test -s conftest.$objext; then
+    # Now try to grab the symbols.
+    nlist=conftest.nm
+    if { echo "$progname:1657: eval \"$NM conftest.$objext | $global_symbol_pipe > $nlist\"" >&5; eval "$NM conftest.$objext | $global_symbol_pipe > $nlist 2>&5"; } && test -s "$nlist"; then
+
+      # Try sorting and uniquifying the output.
+      if sort "$nlist" | uniq > "$nlist"T; then
+	mv -f "$nlist"T "$nlist"
+      else
+	rm -f "$nlist"T
+      fi
+
+      # Make sure that we snagged all the symbols we need.
+      if egrep ' nm_test_var$' "$nlist" >/dev/null; then
+	if egrep ' nm_test_func$' "$nlist" >/dev/null; then
+	  cat <<EOF > conftest.c
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+EOF
+	  # Now generate the symbol file.
+	  eval "$global_symbol_to_cdecl"' < "$nlist" >> conftest.c'
+
+	  cat <<EOF >> conftest.c
+#if defined (__STDC__) && __STDC__
+# define lt_ptr_t void *
+#else
+# define lt_ptr_t char *
+# define const
+#endif
+
+/* The mapping between symbol names and symbols. */
+const struct {
+  const char *name;
+  lt_ptr_t address;
+}
+lt_preloaded_symbols[] =
+{
+EOF
+	  sed 's/^. \(.*\) \(.*\)$/  {"\2", (lt_ptr_t) \&\2},/' < "$nlist" >> conftest.c
+	  cat <<\EOF >> conftest.c
+  {0, (lt_ptr_t) 0}
+};
+
+#ifdef __cplusplus
+}
+#endif
+EOF
+	  # Now try linking the two files.
+	  mv conftest.$objext conftstm.$objext
+	  save_LIBS="$LIBS"
+	  save_CFLAGS="$CFLAGS"
+	  LIBS="conftstm.$objext"
+	  CFLAGS="$CFLAGS$no_builtin_flag"
+	  if { (eval echo $progname:1709: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+	    pipe_works=yes
+	  else
+	    echo "$progname: failed program was:" >&5
+	    cat conftest.c >&5
+	  fi
+	  LIBS="$save_LIBS"
+	else
+	  echo "cannot find nm_test_func in $nlist" >&5
+	fi
+      else
+	echo "cannot find nm_test_var in $nlist" >&5
+      fi
+    else
+      echo "cannot run $global_symbol_pipe" >&5
+    fi
+  else
+    echo "$progname: failed program was:" >&5
+    cat conftest.c >&5
+  fi
+  $rm conftest* conftst*
+
+  # Do not use the global_symbol_pipe unless it works.
+  if test "$pipe_works" = yes; then
+    break
+  else
+    global_symbol_pipe=
+  fi
+done
+if test "$pipe_works" = yes; then
+  echo "${ac_t}ok" 1>&6
+else
+  echo "${ac_t}failed" 1>&6
+fi
+
+if test -z "$global_symbol_pipe"; then
+  global_symbol_to_cdecl=
+fi
+
+# Check hardcoding attributes.
+echo $ac_n "checking how to hardcode library paths into programs... $ac_c" 1>&6
+hardcode_action=
+if test -n "$hardcode_libdir_flag_spec" || \
+   test -n "$runpath_var"; then
+
+  # We can hardcode non-existant directories.
+  if test "$hardcode_direct" != no &&
+     # If the only mechanism to avoid hardcoding is shlibpath_var, we
+     # have to relink, otherwise we might link with an installed library
+     # when we should be linking with a yet-to-be-installed one
+     ## test "$hardcode_shlibpath_var" != no &&
+     test "$hardcode_minus_L" != no; then
+    # Linking always hardcodes the temporary library directory.
+    hardcode_action=relink
+  else
+    # We can link without hardcoding, and we can hardcode nonexisting dirs.
+    hardcode_action=immediate
+  fi
+else
+  # We cannot hardcode anything, or else we can only hardcode existing
+  # directories.
+  hardcode_action=unsupported
+fi
+echo "$ac_t$hardcode_action" 1>&6
+
+
+reload_flag=
+reload_cmds='$LD$reload_flag -o $output$reload_objs'
+echo $ac_n "checking for $LD option to reload object files... $ac_c" 1>&6
+# PORTME Some linkers may need a different reload flag.
+reload_flag='-r'
+echo "$ac_t$reload_flag" 1>&6
+test -n "$reload_flag" && reload_flag=" $reload_flag"
+
+# PORTME Fill in your ld.so characteristics
+library_names_spec=
+libname_spec='lib$name'
+soname_spec=
+postinstall_cmds=
+postuninstall_cmds=
+finish_cmds=
+finish_eval=
+shlibpath_var=
+shlibpath_overrides_runpath=unknown
+version_type=none
+dynamic_linker="$host_os ld.so"
+sys_lib_dlsearch_path_spec="/lib /usr/lib"
+sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
+file_magic_cmd=
+file_magic_test_file=
+deplibs_check_method='unknown'
+# Need to set the preceding variable on all platforms that support
+# interlibrary dependencies.
+# 'none' -- dependencies not supported.
+# `unknown' -- same as none, but documents that we really don't know.
+# 'pass_all' -- all dependencies passed with no checks.
+# 'test_compile' -- check by making test program.
+# 'file_magic [regex]' -- check by looking for files in library path
+# which responds to the $file_magic_cmd with a given egrep regex.
+# If you have `file' or equivalent on your system and you're not sure
+# whether `pass_all' will *always* work, you probably want this one.
+echo $ac_n "checking dynamic linker characteristics... $ac_c" 1>&6
+case "$host_os" in
+aix3*)
+  version_type=linux
+  library_names_spec='${libname}${release}.so$versuffix $libname.a'
+  shlibpath_var=LIBPATH
+
+  # AIX has no versioning support, so we append a major version to the name.
+  soname_spec='${libname}${release}.so$major'
+  ;;
+
+aix4*)
+  version_type=linux
+  # AIX has no versioning support, so currently we can not hardcode correct
+  # soname into executable. Probably we can add versioning support to
+  # collect2, so additional links can be useful in future.
+  # We preserve .a as extension for shared libraries though AIX4.2
+  # and later linker supports .so
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.a'
+  shlibpath_var=LIBPATH
+  deplibs_check_method=pass_all
+  ;;
+
+amigaos*)
+  library_names_spec='$libname.ixlibrary $libname.a'
+  # Create ${libname}_ixlibrary.a entries in /sys/libs.
+  finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do libname=`$echo "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`; test $rm /sys/libs/${libname}_ixlibrary.a; $show "(cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a)"; (cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a) || exit 1; done'
+  ;;
+
+beos*)
+  library_names_spec='${libname}.so'
+  dynamic_linker="$host_os ld.so"
+  shlibpath_var=LIBRARY_PATH
+  deplibs_check_method=pass_all
+  lt_cv_dlopen="load_add_on"
+  lt_cv_dlopen_libs=
+  lt_cv_dlopen_self=yes
+  ;;
+
+bsdi4*)
+  version_type=linux
+  need_version=no
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
+  soname_spec='${libname}${release}.so$major'
+  finish_cmds='PATH="\$PATH:/sbin" ldconfig $libdir'
+  shlibpath_var=LD_LIBRARY_PATH
+  deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB (shared object|dynamic lib)'
+  file_magic_cmd=/usr/bin/file
+  file_magic_test_file=/shlib/libc.so
+  sys_lib_search_path_spec="/shlib /usr/lib /usr/X11/lib /usr/contrib/lib /lib /usr/local/lib"
+  sys_lib_dlsearch_path_spec="/shlib /usr/lib /usr/local/lib"
+  export_dynamic_flag_spec=-rdynamic
+  # the default ld.so.conf also contains /usr/contrib/lib and
+  # /usr/X11R6/lib (/usr/X11 is a link to /usr/X11R6), but let us allow
+  # libtool to hard-code these into programs
+  ;;
+
+cygwin* | mingw*)
+  version_type=windows
+  need_version=no
+  need_lib_prefix=no
+  if test "$with_gcc" = yes; then
+    library_names_spec='${libname}`echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll $libname.a'
+  else
+    library_names_spec='${libname}`echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll $libname.lib'
+  fi
+  dynamic_linker='Win32 ld.exe'
+  deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?'
+  file_magic_cmd='${OBJDUMP} -f'
+  # FIXME: first we should search . and the directory the executable is in
+  shlibpath_var=PATH
+  lt_cv_dlopen="LoadLibrary"
+  lt_cv_dlopen_libs=
+  ;;
+
+freebsd1*)
+  dynamic_linker=no
+  ;;
+  
+freebsd*)
+  objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
+  version_type=freebsd-$objformat
+  case "$version_type" in
+    freebsd-elf*)
+      deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB shared object'
+      file_magic_cmd=/usr/bin/file
+      file_magic_test_file=`echo /usr/lib/libc.so*`
+      library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so $libname.so'
+      need_version=no
+      need_lib_prefix=no
+      ;;
+    freebsd-*)
+      deplibs_check_method=unknown
+      library_names_spec='${libname}${release}.so$versuffix $libname.so$versuffix'
+      need_version=yes
+      ;;
+  esac
+  shlibpath_var=LD_LIBRARY_PATH
+  case "$host_os" in
+  freebsd2* | freebsd3.[01]* | freebsdelf3.[01]*)
+    shlibpath_overrides_runpath=yes
+    ;;
+  *) # from 3.2 on
+    shlibpath_overrides_runpath=no
+    ;;
+  esac
+  ;;
+
+gnu*)
+  version_type=linux
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so${major} ${libname}.so'
+  soname_spec='${libname}${release}.so$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  ;;
+
+hpux9* | hpux10* | hpux11*)
+  # Give a soname corresponding to the major version so that dld.sl refuses to
+  # link against other versions.
+  dynamic_linker="$host_os dld.sl"
+  version_type=sunos
+  need_lib_prefix=no
+  need_version=no
+  shlibpath_var=SHLIB_PATH
+  shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
+  library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major $libname.sl'
+  soname_spec='${libname}${release}.sl$major'
+  # HP-UX runs *really* slowly unless shared libraries are mode 555.
+  postinstall_cmds='chmod 555 $lib'
+  case "$host_os" in
+  hpux10.20*)
+    # TODO:  Does this work for hpux-11 too?
+    deplibs_check_method='file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library'
+    file_magic_cmd=/usr/bin/file
+    file_magic_test_file=/usr/lib/libc.sl
+    ;;
+  esac
+  ;;
+
+irix5* | irix6*)
+  version_type=irix
+  need_lib_prefix=no
+  need_version=no
+  soname_spec='${libname}${release}.so.$major'
+  library_names_spec='${libname}${release}.so.$versuffix ${libname}${release}.so.$major ${libname}${release}.so $libname.so'
+  case "$host_os" in
+  irix5*)
+    libsuff= shlibsuff=
+    # this will be overridden with pass_all, but let us keep it just in case
+    deplibs_check_method="file_magic ELF 32-bit MSB dynamic lib MIPS - version 1"
+    ;;
+  *)
+    case "$LD" in # libtool.m4 will add one of these switches to LD
+    *-32|*"-32 ") libsuff= shlibsuff= libmagic=32-bit;;
+    *-n32|*"-n32 ") libsuff=32 shlibsuff=N32 libmagic=N32;;
+    *-64|*"-64 ") libsuff=64 shlibsuff=64 libmagic=64-bit;;
+    *) libsuff= shlibsuff= libmagic=never-match;;
+    esac
+    ;;
+  esac
+  shlibpath_var=LD_LIBRARY${shlibsuff}_PATH
+  shlibpath_overrides_runpath=no
+  sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
+  sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
+  file_magic_cmd=/usr/bin/file
+  file_magic_test_file=`echo /lib${libsuff}/libc.so*`
+  deplibs_check_method='pass_all'
+  ;;
+
+# No shared lib support for Linux oldld, aout, or coff.
+linux-gnuoldld* | linux-gnuaout* | linux-gnucoff*)
+  dynamic_linker=no
+  ;;
+
+# This must be Linux ELF.
+linux-gnu*)
+  version_type=linux
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
+  soname_spec='${libname}${release}.so$major'
+  finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
+  shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=no
+  deplibs_check_method=pass_all
+
+  if test -f /lib/ld.so.1; then
+    dynamic_linker='GNU ld.so'
+  else
+    # Only the GNU ld.so supports shared libraries on MkLinux.
+    case "$host_cpu" in
+    powerpc*) dynamic_linker=no ;;
+    *) dynamic_linker='Linux ld.so' ;;
+    esac
+  fi
+  ;;
+
+netbsd*)
+  version_type=sunos
+  if echo __ELF__ | $CC -E - | grep __ELF__ >/dev/null; then
+    library_names_spec='${libname}${release}.so$versuffix ${libname}.so$versuffix'
+    finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
+    dynamic_linker='NetBSD (a.out) ld.so'
+  else
+    library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major ${libname}${release}.so ${libname}.so'
+    soname_spec='${libname}${release}.so$major'
+    dynamic_linker='NetBSD ld.elf_so'
+  fi
+  shlibpath_var=LD_LIBRARY_PATH
+  ;;
+
+openbsd*)
+  version_type=sunos
+  if test "$with_gnu_ld" = yes; then
+    need_lib_prefix=no
+    need_version=no
+  fi
+  library_names_spec='${libname}${release}.so$versuffix ${libname}.so$versuffix'
+  finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
+  shlibpath_var=LD_LIBRARY_PATH
+  ;;
+
+os2*)
+  libname_spec='$name'
+  need_lib_prefix=no
+  library_names_spec='$libname.dll $libname.a'
+  dynamic_linker='OS/2 ld.exe'
+  shlibpath_var=LIBPATH
+  ;;
+
+osf3* | osf4* | osf5*)
+  version_type=osf
+  need_version=no
+  soname_spec='${libname}${release}.so'
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so $libname.so'
+  shlibpath_var=LD_LIBRARY_PATH
+  # this will be overridden with pass_all, but let us keep it just in case
+  deplibs_check_method='file_magic COFF format alpha shared library'
+  file_magic_cmd=/usr/bin/file
+  file_magic_test_file=/shlib/libc.so
+  deplibs_check_method='pass_all'
+  sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /usr/local/lib /var/shlib"
+  sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
+  ;;
+
+rhapsody*)
+  version_type=sunos
+  library_names_spec='${libname}.so'
+  soname_spec='${libname}.so'
+  shlibpath_var=DYLD_LIBRARY_PATH
+  deplibs_check_method=pass_all
+  ;;
+
+sco3.2v5*)
+  version_type=osf
+  soname_spec='${libname}${release}.so$major'
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
+  shlibpath_var=LD_LIBRARY_PATH
+  ;;
+
+solaris*)
+  version_type=linux
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
+  soname_spec='${libname}${release}.so$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=yes
+  # ldd complains unless libraries are executable
+  postinstall_cmds='chmod +x $lib'
+  deplibs_check_method="file_magic ELF [0-9][0-9]-bit [LM]SB dynamic lib"
+  file_magic_cmd=/usr/bin/file
+  file_magic_test_file=/lib/libc.so
+  ;;
+
+sunos4*)
+  version_type=sunos
+  library_names_spec='${libname}${release}.so$versuffix ${libname}.so$versuffix'
+  finish_cmds='PATH="\$PATH:/usr/etc" ldconfig $libdir'
+  shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=yes
+  if test "$with_gnu_ld" = yes; then
+    need_lib_prefix=no
+  fi
+  need_version=yes
+  ;;
+
+sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+  version_type=linux
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
+  soname_spec='${libname}${release}.so$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  case "$host_vendor" in
+    sequent)
+      file_magic_cmd='/bin/file'
+      deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )'
+      ;;
+    ncr)
+      deplibs_check_method='pass_all'
+      ;;
+    motorola)
+      need_lib_prefix=no
+      need_version=no
+      shlibpath_overrides_runpath=no
+      sys_lib_search_path_spec='/lib /usr/lib /usr/ccs/lib'
+      deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB (shared object|dynamic lib) M[0-9][0-9]* Version [0-9]'
+      file_magic_cmd=/usr/bin/file
+      file_magic_test_file=`echo /usr/lib/libc.so*`
+      ;;
+  esac
+  ;;
+
+uts4*)
+  version_type=linux
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
+  soname_spec='${libname}${release}.so$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  ;;
+
+dgux*)
+  version_type=linux
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
+  soname_spec='${libname}${release}.so$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  ;;
+
+sysv4*MP*)
+  if test -d /usr/nec ;then
+    version_type=linux
+    library_names_spec='$libname.so.$versuffix $libname.so.$major $libname.so'
+    soname_spec='$libname.so.$major'
+    shlibpath_var=LD_LIBRARY_PATH
+  fi
+  ;;
+
+*)
+  dynamic_linker=no
+  ;;
+esac
+echo "$ac_t$dynamic_linker" 1>&6
+test "$dynamic_linker" = no && can_build_shared=no
+
+# Report the final consequences.
+echo "checking if libtool supports shared libraries... $can_build_shared" 1>&6
+
+# Only try to build win32 dlls if AC_LIBTOOL_WIN32_DLL was used in
+# configure.in, otherwise build static only libraries.
+case "$host_os" in
+cygwin* | mingw* | os2*)
+  if test x$can_build_shared = xyes; then
+    test x$enable_win32_dll = xno && can_build_shared=no
+    echo "checking if package supports dlls... $can_build_shared" 1>&6
+  fi
+;;
+esac
+
+if test -n "$file_magic_test_file" && test -n "$file_magic_cmd"; then
+  case "$deplibs_check_method" in
+  "file_magic "*)
+    file_magic_regex="`expr \"$deplibs_check_method\" : \"file_magic \(.*\)\"`"
+    if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
+       egrep "$file_magic_regex" > /dev/null; then
+      :
+    else
+      cat <<EOF 1>&2
+
+*** Warning: the command libtool uses to detect shared libraries,
+*** $file_magic_cmd, produces output that libtool cannot recognize.
+*** The result is that libtool may fail to recognize shared libraries
+*** as such.  This will affect the creation of libtool libraries that
+*** depend on shared libraries, but programs linked with such libtool
+*** libraries will work regardless of this problem.  Nevertheless, you
+*** may want to report the problem to your system manager and/or to
+*** bug-libtool@gnu.org
+
+EOF
+    fi ;;
+  esac
+fi
+
+echo $ac_n "checking whether to build shared libraries... $ac_c" 1>&6
+test "$can_build_shared" = "no" && enable_shared=no
+
+# On AIX, shared libraries and static libraries use the same namespace, and
+# are all built from PIC.
+case "$host_os" in
+aix3*)
+  test "$enable_shared" = yes && enable_static=no
+  if test -n "$RANLIB"; then
+    archive_cmds="$archive_cmds~\$RANLIB \$lib"
+    postinstall_cmds='$RANLIB $lib'
+  fi
+  ;;
+
+aix4*)
+  test "$enable_shared" = yes && enable_static=no
+  ;;
+esac
+
+echo "$ac_t$enable_shared" 1>&6
+
+# Make sure either enable_shared or enable_static is yes.
+test "$enable_shared" = yes || enable_static=yes
+
+echo "checking whether to build static libraries... $enable_static" 1>&6
+
+if test "$hardcode_action" = relink; then
+  # Fast installation is not supported
+  enable_fast_install=no
+elif test "$shlibpath_overrides_runpath" = yes ||
+     test "$enable_shared" = no; then
+  # Fast installation is not necessary
+  enable_fast_install=needless
+fi
+
+echo $ac_n "checking for objdir... $ac_c" 1>&6
+rm -f .libs 2>/dev/null
+mkdir .libs 2>/dev/null
+if test -d .libs; then
+  objdir=.libs
+else
+  # MS-DOS does not allow filenames that begin with a dot.
+  objdir=_libs
+fi
+rmdir .libs 2>/dev/null
+echo "$ac_t$objdir" 1>&6
+
+if test "x$enable_dlopen" != xyes; then
+  enable_dlopen=unknown
+  enable_dlopen_self=unknown
+  enable_dlopen_self_static=unknown
+else
+if eval "test \"`echo '$''{'lt_cv_dlopen'+set}'`\" != set"; then
+  lt_cv_dlopen=no lt_cv_dlopen_libs=
+echo $ac_n "checking for dlopen in -ldl""... $ac_c" 1>&6
+echo "$progname:2248: checking for dlopen in -ldl" >&5
+ac_lib_var=`echo dl'_'dlopen | sed 'y%./+-%__p_%'`
+if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  ac_save_LIBS="$LIBS"
+LIBS="-ldl  $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 2256 "ltconfig"
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char dlopen();
+
+int main() {
+dlopen()
+; return 0; }
+EOF
+if { (eval echo $progname:2269: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=yes"
+else
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+LIBS="$ac_save_LIBS"
+
+fi
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"
+else
+  echo "$ac_t""no" 1>&6
+echo $ac_n "checking for dlopen""... $ac_c" 1>&6
+echo "$progname:2288: checking for dlopen" >&5
+if eval "test \"`echo '$''{'ac_cv_func_dlopen'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat > conftest.$ac_ext <<EOF
+#line 2293 "ltconfig"
+/* System header to define __stub macros and hopefully few prototypes,
+    which can conflict with char dlopen(); below.  */
+#include <assert.h>
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char dlopen();
+
+int main() {
+
+/* The GNU C library defines this for functions which it implements
+    to always fail with ENOSYS.  Some functions are actually named
+    something starting with __ and the normal name is an alias.  */
+#if defined (__stub_dlopen) || defined (__stub___dlopen)
+choke me
+#else
+dlopen();
+#endif
+
+; return 0; }
+EOF
+if { (eval echo $progname:2318: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+  rm -rf conftest*
+  eval "ac_cv_func_dlopen=yes"
+else
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_func_dlopen=no"
+fi
+rm -f conftest*
+fi
+if eval "test \"`echo '$ac_cv_func_'dlopen`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  lt_cv_dlopen="dlopen"
+else
+  echo "$ac_t""no" 1>&6
+echo $ac_n "checking for dld_link in -ldld""... $ac_c" 1>&6
+echo "$progname:2335: checking for dld_link in -ldld" >&5
+ac_lib_var=`echo dld'_'dld_link | sed 'y%./+-%__p_%'`
+if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  ac_save_LIBS="$LIBS"
+LIBS="-ldld  $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 2343 "ltconfig"
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char dld_link();
+
+int main() {
+dld_link()
+; return 0; }
+EOF
+if { (eval echo $progname:2356: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=yes"
+else
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+LIBS="$ac_save_LIBS"
+
+fi
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-ldld"
+else
+  echo "$ac_t""no" 1>&6
+echo $ac_n "checking for shl_load""... $ac_c" 1>&6
+echo "$progname:2375: checking for shl_load" >&5
+if eval "test \"`echo '$''{'ac_cv_func_shl_load'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat > conftest.$ac_ext <<EOF
+#line 2380 "ltconfig"
+/* System header to define __stub macros and hopefully few prototypes,
+    which can conflict with char shl_load(); below.  */
+#include <assert.h>
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char shl_load();
+
+int main() {
+
+/* The GNU C library defines this for functions which it implements
+    to always fail with ENOSYS.  Some functions are actually named
+    something starting with __ and the normal name is an alias.  */
+#if defined (__stub_shl_load) || defined (__stub___shl_load)
+choke me
+#else
+shl_load();
+#endif
+
+; return 0; }
+EOF
+if { (eval echo $progname:2405: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+  rm -rf conftest*
+  eval "ac_cv_func_shl_load=yes"
+else
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_func_shl_load=no"
+fi
+rm -f conftest*
+fi
+
+if eval "test \"`echo '$ac_cv_func_'shl_load`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  lt_cv_dlopen="shl_load"
+else
+  echo "$ac_t""no" 1>&6
+echo $ac_n "checking for shl_load in -ldld""... $ac_c" 1>&6
+echo "$progname:2423: checking for shl_load in -ldld" >&5
+ac_lib_var=`echo dld'_'shl_load | sed 'y%./+-%__p_%'`
+if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  ac_save_LIBS="$LIBS"
+LIBS="-ldld  $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 2431 "ltconfig"
+#include "confdefs.h"
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char shl_load();
+
+int main() {
+shl_load()
+; return 0; }
+EOF
+if { (eval echo $progname:2445: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=yes"
+else
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+LIBS="$ac_save_LIBS"
+
+fi
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-ldld"
+else
+  echo "$ac_t""no" 1>&6
+fi
+
+
+fi
+
+    
+fi
+
+  
+fi
+
+
+fi
+
+fi
+
+  if test "x$lt_cv_dlopen" != xno; then
+    enable_dlopen=yes
+  fi
+
+  case "$lt_cv_dlopen" in
+  dlopen)
+for ac_hdr in dlfcn.h; do
+ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'`
+echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6
+echo "$progname:2488: checking for $ac_hdr" >&5
+if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat > conftest.$ac_ext <<EOF
+#line 2493 "ltconfig"
+#include <$ac_hdr>
+int fnord = 0;
+EOF
+ac_try="$ac_compile >/dev/null 2>conftest.out"
+{ (eval echo $progname:2498: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
+if test -z "$ac_err"; then
+  rm -rf conftest*
+  eval "ac_cv_header_$ac_safe=yes"
+else
+  echo "$ac_err" >&5
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_header_$ac_safe=no"
+fi
+rm -f conftest*
+fi
+if eval "test \"`echo '$ac_cv_header_'$ac_safe`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+else
+  echo "$ac_t""no" 1>&6
+fi
+done
+
+    if test "x$ac_cv_header_dlfcn_h" = xyes; then
+      CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
+    fi
+    eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
+    LIBS="$lt_cv_dlopen_libs $LIBS"
+
+  echo $ac_n "checking whether a program can dlopen itself""... $ac_c" 1>&6
+echo "$progname:2526: checking whether a program can dlopen itself" >&5
+if test "${lt_cv_dlopen_self+set}" = set; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  if test "$cross_compiling" = yes; then
+    lt_cv_dlopen_self=cross
+  else
+    cat > conftest.c <<EOF
+#line 2534 "ltconfig"
+
+#if HAVE_DLFCN_H
+#include <dlfcn.h>
+#endif
+
+#include <stdio.h>
+
+#ifdef RTLD_GLOBAL
+# define LTDL_GLOBAL	RTLD_GLOBAL
+#else
+# ifdef DL_GLOBAL
+#  define LTDL_GLOBAL	DL_GLOBAL
+# else
+#  define LTDL_GLOBAL	0
+# endif
+#endif
+
+/* We may have to define LTDL_LAZY_OR_NOW in the command line if we
+   find out it does not work in some platform. */
+#ifndef LTDL_LAZY_OR_NOW
+# ifdef RTLD_LAZY
+#  define LTDL_LAZY_OR_NOW	RTLD_LAZY
+# else
+#  ifdef DL_LAZY
+#   define LTDL_LAZY_OR_NOW	DL_LAZY
+#  else
+#   ifdef RTLD_NOW
+#    define LTDL_LAZY_OR_NOW	RTLD_NOW
+#   else
+#    ifdef DL_NOW
+#     define LTDL_LAZY_OR_NOW	DL_NOW
+#    else
+#     define LTDL_LAZY_OR_NOW	0
+#    endif
+#   endif
+#  endif
+# endif
+#endif
+
+fnord() { int i=42;}
+main() { void *self, *ptr1, *ptr2; self=dlopen(0,LTDL_GLOBAL|LTDL_LAZY_OR_NOW);
+    if(self) { ptr1=dlsym(self,"fnord"); ptr2=dlsym(self,"_fnord");
+	       if(ptr1 || ptr2) { dlclose(self); exit(0); } } exit(1); } 
+
+EOF
+if { (eval echo $progname:2580: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest && (./conftest; exit) 2>/dev/null
+then
+  lt_cv_dlopen_self=yes
+else
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -fr conftest*
+  lt_cv_dlopen_self=no
+fi
+rm -fr conftest*
+fi
+
+fi
+
+echo "$ac_t""$lt_cv_dlopen_self" 1>&6
+
+  if test "$lt_cv_dlopen_self" = yes; then
+    LDFLAGS="$LDFLAGS $link_static_flag"
+  echo $ac_n "checking whether a statically linked program can dlopen itself""... $ac_c" 1>&6
+echo "$progname:2599: checking whether a statically linked program can dlopen itself" >&5
+if test "${lt_cv_dlopen_self_static+set}" = set; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  if test "$cross_compiling" = yes; then
+    lt_cv_dlopen_self_static=cross
+  else
+    cat > conftest.c <<EOF
+#line 2607 "ltconfig"
+
+#if HAVE_DLFCN_H
+#include <dlfcn.h>
+#endif
+
+#include <stdio.h>
+
+#ifdef RTLD_GLOBAL
+# define LTDL_GLOBAL	RTLD_GLOBAL
+#else
+# ifdef DL_GLOBAL
+#  define LTDL_GLOBAL	DL_GLOBAL
+# else
+#  define LTDL_GLOBAL	0
+# endif
+#endif
+
+/* We may have to define LTDL_LAZY_OR_NOW in the command line if we
+   find out it does not work in some platform. */
+#ifndef LTDL_LAZY_OR_NOW
+# ifdef RTLD_LAZY
+#  define LTDL_LAZY_OR_NOW	RTLD_LAZY
+# else
+#  ifdef DL_LAZY
+#   define LTDL_LAZY_OR_NOW	DL_LAZY
+#  else
+#   ifdef RTLD_NOW
+#    define LTDL_LAZY_OR_NOW	RTLD_NOW
+#   else
+#    ifdef DL_NOW
+#     define LTDL_LAZY_OR_NOW	DL_NOW
+#    else
+#     define LTDL_LAZY_OR_NOW	0
+#    endif
+#   endif
+#  endif
+# endif
+#endif
+
+fnord() { int i=42;}
+main() { void *self, *ptr1, *ptr2; self=dlopen(0,LTDL_GLOBAL|LTDL_LAZY_OR_NOW);
+    if(self) { ptr1=dlsym(self,"fnord"); ptr2=dlsym(self,"_fnord");
+    if(ptr1 || ptr2) { dlclose(self); exit(0); } } exit(1); } 
+
+EOF
+if { (eval echo $progname:2653: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest && (./conftest; exit) 2>/dev/null
+then
+  lt_cv_dlopen_self_static=yes
+else
+  echo "$progname: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -fr conftest*
+  lt_cv_dlopen_self_static=no
+fi
+rm -fr conftest*
+fi
+
+fi
+
+echo "$ac_t""$lt_cv_dlopen_self_static" 1>&6
+fi
+    ;;
+  esac
+
+  case "$lt_cv_dlopen_self" in
+  yes|no) enable_dlopen_self=$lt_cv_dlopen_self ;;
+  *) enable_dlopen_self=unknown ;;
+  esac
+
+  case "$lt_cv_dlopen_self_static" in
+  yes|no) enable_dlopen_self_static=$lt_cv_dlopen_self_static ;;
+  *) enable_dlopen_self_static=unknown ;;
+  esac
+fi
+
+# Copy echo and quote the copy, instead of the original, because it is
+# used later.
+ltecho="$echo"
+if test "X$ltecho" = "X$CONFIG_SHELL $0 --fallback-echo"; then
+   ltecho="$CONFIG_SHELL \$0 --fallback-echo"
+fi
+LTSHELL="$SHELL"
+
+LTCONFIG_VERSION="$VERSION"
+
+# Only quote variables if we're using ltmain.sh.
+case "$ltmain" in
+*.sh)
+  # Now quote all the things that may contain metacharacters.
+  for var in ltecho old_CC old_CFLAGS old_CPPFLAGS \
+    old_LD old_LDFLAGS old_LIBS \
+    old_NM old_RANLIB old_LN_S old_DLLTOOL old_OBJDUMP old_AS \
+    AR CC LD LN_S NM LTSHELL LTCONFIG_VERSION \
+    reload_flag reload_cmds wl \
+    pic_flag link_static_flag no_builtin_flag export_dynamic_flag_spec \
+    thread_safe_flag_spec whole_archive_flag_spec libname_spec \
+    library_names_spec soname_spec \
+    RANLIB old_archive_cmds old_archive_from_new_cmds old_postinstall_cmds \
+    old_postuninstall_cmds archive_cmds archive_expsym_cmds postinstall_cmds postuninstall_cmds \
+    file_magic_cmd export_symbols_cmds deplibs_check_method allow_undefined_flag no_undefined_flag \
+    finish_cmds finish_eval global_symbol_pipe global_symbol_to_cdecl \
+    hardcode_libdir_flag_spec hardcode_libdir_separator  \
+    sys_lib_search_path_spec sys_lib_dlsearch_path_spec \
+    compiler_c_o compiler_o_lo need_locks exclude_expsyms include_expsyms; do
+
+    case "$var" in
+    reload_cmds | old_archive_cmds | old_archive_from_new_cmds | \
+    old_postinstall_cmds | old_postuninstall_cmds | \
+    export_symbols_cmds | archive_cmds | archive_expsym_cmds | \
+    postinstall_cmds | postuninstall_cmds | \
+    finish_cmds | sys_lib_search_path_spec | sys_lib_dlsearch_path_spec)
+      # Double-quote double-evaled strings.
+      eval "$var=\\\"\`\$echo \"X\$$var\" | \$Xsed -e \"\$double_quote_subst\" -e \"\$sed_quote_subst\" -e \"\$delay_variable_subst\"\`\\\""
+      ;;
+    *)
+      eval "$var=\\\"\`\$echo \"X\$$var\" | \$Xsed -e \"\$sed_quote_subst\"\`\\\""
+      ;;
+    esac
+  done
+
+  case "$ltecho" in
+  *'\$0 --fallback-echo"')
+    ltecho=`$echo "X$ltecho" | $Xsed -e 's/\\\\\\\$0 --fallback-echo"$/$0 --fallback-echo"/'`
+    ;;
+  esac
+
+  trap "$rm \"$ofile\"; exit 1" 1 2 15
+  echo "creating $ofile"
+  $rm "$ofile"
+  cat <<EOF > "$ofile"
+#! $SHELL
+
+# `$echo "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building support services.
+# Generated automatically by $PROGRAM (GNU $PACKAGE $VERSION$TIMESTAMP)
+# NOTE: Changes made to this file will be lost: look at ltconfig or ltmain.sh.
+#
+# Copyright (C) 1996-1999 Free Software Foundation, Inc.
+# Originally by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# Sed that helps us avoid accidentally triggering echo(1) options like -n.
+Xsed="sed -e s/^X//"
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+if test "X\${CDPATH+set}" = Xset; then CDPATH=:; export CDPATH; fi
+
+### BEGIN LIBTOOL CONFIG
+EOF
+  cfgfile="$ofile"
+  ;;
+
+*)
+  # Double-quote the variables that need it (for aesthetics).
+  for var in old_CC old_CFLAGS old_CPPFLAGS \
+    old_LD old_LDFLAGS old_LIBS \
+    old_NM old_RANLIB old_LN_S old_DLLTOOL old_OBJDUMP old_AS; do
+    eval "$var=\\\"\$var\\\""
+  done
+
+  # Just create a config file.
+  cfgfile="$ofile.cfg"
+  trap "$rm \"$cfgfile\"; exit 1" 1 2 15
+  echo "creating $cfgfile"
+  $rm "$cfgfile"
+  cat <<EOF > "$cfgfile"
+# `$echo "$cfgfile" | sed 's%^.*/%%'` - Libtool configuration file.
+# Generated automatically by $PROGRAM (GNU $PACKAGE $VERSION$TIMESTAMP)
+EOF
+  ;;
+esac
+
+cat <<EOF >> "$cfgfile"
+# Libtool was configured as follows, on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
+#
+# CC=$old_CC CFLAGS=$old_CFLAGS CPPFLAGS=$old_CPPFLAGS \\
+# LD=$old_LD LDFLAGS=$old_LDFLAGS LIBS=$old_LIBS \\
+# NM=$old_NM RANLIB=$old_RANLIB LN_S=$old_LN_S \\
+# DLLTOOL=$old_DLLTOOL OBJDUMP=$old_OBJDUMP AS=$old_AS \\
+#   $0$ltconfig_args
+#
+# Compiler and other test output produced by $progname, useful for
+# debugging $progname, is in ./config.log if it exists.
+
+# The version of $progname that generated this script.
+LTCONFIG_VERSION=$LTCONFIG_VERSION
+
+# Shell to use when invoking shell scripts.
+SHELL=$LTSHELL
+
+# Whether or not to build shared libraries.
+build_libtool_libs=$enable_shared
+
+# Whether or not to build static libraries.
+build_old_libs=$enable_static
+
+# Whether or not to optimize for fast installation.
+fast_install=$enable_fast_install
+
+# The host system.
+host_alias=$host_alias
+host=$host
+
+# An echo program that does not interpret backslashes.
+echo=$ltecho
+
+# The archiver.
+AR=$AR
+
+# The default C compiler.
+CC=$CC
+
+# The linker used to build libraries.
+LD=$LD
+
+# Whether we need hard or soft links.
+LN_S=$LN_S
+
+# A BSD-compatible nm program.
+NM=$NM
+
+# Used on cygwin: DLL creation program.
+DLLTOOL="$DLLTOOL"
+
+# Used on cygwin: object dumper.
+OBJDUMP="$OBJDUMP"
+
+# Used on cygwin: assembler.
+AS="$AS"
+
+# The name of the directory that contains temporary libtool files.
+objdir=$objdir
+
+# How to create reloadable object files.
+reload_flag=$reload_flag
+reload_cmds=$reload_cmds
+
+# How to pass a linker flag through the compiler.
+wl=$wl
+
+# Object file suffix (normally "o").
+objext="$objext"
+
+# Old archive suffix (normally "a").
+libext="$libext"
+
+# Executable file suffix (normally "").
+exeext="$exeext"
+
+# Additional compiler flags for building library objects.
+pic_flag=$pic_flag
+
+# Does compiler simultaneously support -c and -o options?
+compiler_c_o=$compiler_c_o
+
+# Can we write directly to a .lo ?
+compiler_o_lo=$compiler_o_lo
+
+# Must we lock files when doing compilation ?
+need_locks=$need_locks
+
+# Do we need the lib prefix for modules?
+need_lib_prefix=$need_lib_prefix
+
+# Do we need a version for libraries?
+need_version=$need_version
+
+# Whether dlopen is supported.
+dlopen=$enable_dlopen
+
+# Whether dlopen of programs is supported.
+dlopen_self=$enable_dlopen_self
+
+# Whether dlopen of statically linked programs is supported.
+dlopen_self_static=$enable_dlopen_self_static
+
+# Compiler flag to prevent dynamic linking.
+link_static_flag=$link_static_flag
+
+# Compiler flag to turn off builtin functions.
+no_builtin_flag=$no_builtin_flag
+
+# Compiler flag to allow reflexive dlopens.
+export_dynamic_flag_spec=$export_dynamic_flag_spec
+
+# Compiler flag to generate shared objects directly from archives.
+whole_archive_flag_spec=$whole_archive_flag_spec
+
+# Compiler flag to generate thread-safe objects.
+thread_safe_flag_spec=$thread_safe_flag_spec
+
+# Library versioning type.
+version_type=$version_type
+
+# Format of library name prefix.
+libname_spec=$libname_spec
+
+# List of archive names.  First name is the real one, the rest are links.
+# The last name is the one that the linker finds with -lNAME.
+library_names_spec=$library_names_spec
+
+# The coded name of the library, if different from the real name.
+soname_spec=$soname_spec
+
+# Commands used to build and install an old-style archive.
+RANLIB=$RANLIB
+old_archive_cmds=$old_archive_cmds
+old_postinstall_cmds=$old_postinstall_cmds
+old_postuninstall_cmds=$old_postuninstall_cmds
+
+# Create an old-style archive from a shared archive.
+old_archive_from_new_cmds=$old_archive_from_new_cmds
+
+# Commands used to build and install a shared archive.
+archive_cmds=$archive_cmds
+archive_expsym_cmds=$archive_expsym_cmds
+postinstall_cmds=$postinstall_cmds
+postuninstall_cmds=$postuninstall_cmds
+
+# Method to check whether dependent libraries are shared objects.
+deplibs_check_method=$deplibs_check_method
+
+# Command to use when deplibs_check_method == file_magic.
+file_magic_cmd=$file_magic_cmd
+
+# Flag that allows shared libraries with undefined symbols to be built.
+allow_undefined_flag=$allow_undefined_flag
+
+# Flag that forces no undefined symbols.
+no_undefined_flag=$no_undefined_flag
+
+# Commands used to finish a libtool library installation in a directory.
+finish_cmds=$finish_cmds
+
+# Same as above, but a single script fragment to be evaled but not shown.
+finish_eval=$finish_eval
+
+# Take the output of nm and produce a listing of raw symbols and C names.
+global_symbol_pipe=$global_symbol_pipe
+
+# Transform the output of nm in a proper C declaration
+global_symbol_to_cdecl=$global_symbol_to_cdecl
+
+# This is the shared library runtime path variable.
+runpath_var=$runpath_var
+
+# This is the shared library path variable.
+shlibpath_var=$shlibpath_var
+
+# Is shlibpath searched before the hard-coded library search path?
+shlibpath_overrides_runpath=$shlibpath_overrides_runpath
+
+# How to hardcode a shared library path into an executable.
+hardcode_action=$hardcode_action
+
+# Flag to hardcode \$libdir into a binary during linking.
+# This must work even if \$libdir does not exist.
+hardcode_libdir_flag_spec=$hardcode_libdir_flag_spec
+
+# Whether we need a single -rpath flag with a separated argument.
+hardcode_libdir_separator=$hardcode_libdir_separator
+
+# Set to yes if using DIR/libNAME.so during linking hardcodes DIR into the
+# resulting binary.
+hardcode_direct=$hardcode_direct
+
+# Set to yes if using the -LDIR flag during linking hardcodes DIR into the
+# resulting binary.
+hardcode_minus_L=$hardcode_minus_L
+
+# Set to yes if using SHLIBPATH_VAR=DIR during linking hardcodes DIR into
+# the resulting binary.
+hardcode_shlibpath_var=$hardcode_shlibpath_var
+
+# Compile-time system search path for libraries
+sys_lib_search_path_spec=$sys_lib_search_path_spec
+
+# Run-time system search path for libraries
+sys_lib_dlsearch_path_spec=$sys_lib_dlsearch_path_spec
+
+# Fix the shell variable \$srcfile for the compiler.
+fix_srcfile_path="$fix_srcfile_path"
+
+# Set to yes if exported symbols are required.
+always_export_symbols=$always_export_symbols
+
+# The commands to list exported symbols.
+export_symbols_cmds=$export_symbols_cmds
+
+# Symbols that should not be listed in the preloaded symbols.
+exclude_expsyms=$exclude_expsyms
+
+# Symbols that must always be exported.
+include_expsyms=$include_expsyms
+
+EOF
+
+case "$ltmain" in
+*.sh)
+  echo '### END LIBTOOL CONFIG' >> "$ofile"
+  echo >> "$ofile"
+  case "$host_os" in
+  aix3*)
+    cat <<\EOF >> "$ofile"
+
+# AIX sometimes has problems with the GCC collect2 program.  For some
+# reason, if we set the COLLECT_NAMES environment variable, the problems
+# vanish in a puff of smoke.
+if test "X${COLLECT_NAMES+set}" != Xset; then
+  COLLECT_NAMES=
+  export COLLECT_NAMES
+fi
+EOF
+    ;;
+  esac
+
+  # Append the ltmain.sh script.
+  sed '$q' "$ltmain" >> "$ofile" || (rm -f "$ofile"; exit 1)
+  # We use sed instead of cat because bash on DJGPP gets confused if
+  # if finds mixed CR/LF and LF-only lines.  Since sed operates in
+  # text mode, it properly converts lines to CR/LF.  This bash problem
+  # is reportedly fixed, but why not run on old versions too?
+
+  chmod +x "$ofile"
+  ;;
+
+*)
+  # Compile the libtool program.
+  echo "FIXME: would compile $ltmain"
+  ;;
+esac
+
+test -n "$cache_file" || exit 0
+
+# AC_CACHE_SAVE
+trap '' 1 2 15
+cat > confcache <<\EOF
+# This file is a shell script that caches the results of configure
+# tests run on this system so they can be shared between configure
+# scripts and configure runs.  It is not useful on other systems.
+# If it contains results you don't want to keep, you may remove or edit it.
+#
+# By default, configure uses ./config.cache as the cache file,
+# creating it if it does not exist already.  You can give configure
+# the --cache-file=FILE option to use a different cache file; that is
+# what configure does when it calls configure scripts in
+# subdirectories, so they share the cache.
+# Giving --cache-file=/dev/null disables caching, for debugging configure.
+# config.status only pays attention to the cache file if you give it the
+# --recheck option to rerun configure.
+#
+EOF
+# The following way of writing the cache mishandles newlines in values,
+# but we know of no workaround that is simple, portable, and efficient.
+# So, don't put newlines in cache variables' values.
+# Ultrix sh set writes to stderr and can't be redirected directly,
+# and sets the high bit in the cache file unless we assign to the vars.
+(set) 2>&1 |
+  case `(ac_space=' '; set | grep ac_space) 2>&1` in
+  *ac_space=\ *)
+    # `set' does not quote correctly, so add quotes (double-quote substitution
+    # turns \\\\ into \\, and sed turns \\ into \).
+    sed -n \
+      -e "s/'/'\\\\''/g" \
+      -e "s/^\\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\\)=\\(.*\\)/\\1=\${\\1='\\2'}/p"
+    ;;
+  *)
+    # `set' quotes correctly as required by POSIX, so do not add quotes.
+    sed -n -e 's/^\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\)=\(.*\)/\1=${\1=\2}/p'
+    ;;
+  esac >> confcache
+if cmp -s $cache_file confcache; then
+  :
+else
+  if test -w $cache_file; then
+    echo "updating cache $cache_file"
+    cat confcache > $cache_file
+  else
+    echo "not updating unwritable cache $cache_file"
+  fi
+fi
+rm -f confcache
+
+exit 0
+
+# Local Variables:
+# mode:shell-script
+# sh-indentation:2
+# End:
diff --git a/ltmain.sh b/ltmain.sh
new file mode 100644
index 0000000..766732d
--- /dev/null
+++ b/ltmain.sh
@@ -0,0 +1,4024 @@
+# ltmain.sh - Provide generalized library-building support services.
+# NOTE: Changing this file will not affect anything until you rerun ltconfig.
+#
+# Copyright (C) 1996-1999 Free Software Foundation, Inc.
+# Originally by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# Check that we have a working $echo.
+if test "X$1" = X--no-reexec; then
+  # Discard the --no-reexec flag, and continue.
+  shift
+elif test "X$1" = X--fallback-echo; then
+  # Avoid inline document here, it may be left over
+  :
+elif test "X`($echo '\t') 2>/dev/null`" = 'X\t'; then
+  # Yippee, $echo works!
+  :
+else
+  # Restart under the correct shell, and then maybe $echo will work.
+  exec $SHELL "$0" --no-reexec ${1+"$@"}
+fi
+
+if test "X$1" = X--fallback-echo; then
+  # used as fallback echo
+  shift
+  cat <<EOF
+$*
+EOF
+  exit 0
+fi
+
+# The name of this program.
+progname=`$echo "$0" | sed 's%^.*/%%'`
+modename="$progname"
+
+# Constants.
+PROGRAM=ltmain.sh
+PACKAGE=libtool
+VERSION=1.3.5
+TIMESTAMP=" (1.385.2.206 2000/05/27 11:12:27)"
+
+default_mode=
+help="Try \`$progname --help' for more information."
+magic="%%%MAGIC variable%%%"
+mkdir="mkdir"
+mv="mv -f"
+rm="rm -f"
+
+# Sed substitution that helps us do robust quoting.  It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='sed -e 1s/^X//'
+sed_quote_subst='s/\([\\`\\"$\\\\]\)/\\\1/g'
+SP2NL='tr \040 \012'
+NL2SP='tr \015\012 \040\040'
+
+# NLS nuisances.
+# Only set LANG and LC_ALL to C if already set.
+# These must not be set unconditionally because not all systems understand
+# e.g. LANG=C (notably SCO).
+# We save the old values to restore during execute mode.
+if test "${LC_ALL+set}" = set; then
+  save_LC_ALL="$LC_ALL"; LC_ALL=C; export LC_ALL
+fi
+if test "${LANG+set}" = set; then
+  save_LANG="$LANG"; LANG=C; export LANG
+fi
+
+if test "$LTCONFIG_VERSION" != "$VERSION"; then
+  echo "$modename: ltconfig version \`$LTCONFIG_VERSION' does not match $PROGRAM version \`$VERSION'" 1>&2
+  echo "Fatal configuration error.  See the $PACKAGE docs for more information." 1>&2
+  exit 1
+fi
+
+if test "$build_libtool_libs" != yes && test "$build_old_libs" != yes; then
+  echo "$modename: not configured to build any kind of library" 1>&2
+  echo "Fatal configuration error.  See the $PACKAGE docs for more information." 1>&2
+  exit 1
+fi
+
+# Global variables.
+mode=$default_mode
+nonopt=
+prev=
+prevopt=
+run=
+show="$echo"
+show_help=
+execute_dlfiles=
+lo2o="s/\\.lo\$/.${objext}/"
+o2lo="s/\\.${objext}\$/.lo/"
+
+# Parse our command line options once, thoroughly.
+while test $# -gt 0
+do
+  arg="$1"
+  shift
+
+  case "$arg" in
+  -*=*) optarg=`$echo "X$arg" | $Xsed -e 's/[-_a-zA-Z0-9]*=//'` ;;
+  *) optarg= ;;
+  esac
+
+  # If the previous option needs an argument, assign it.
+  if test -n "$prev"; then
+    case "$prev" in
+    execute_dlfiles)
+      eval "$prev=\"\$$prev \$arg\""
+      ;;
+    *)
+      eval "$prev=\$arg"
+      ;;
+    esac
+
+    prev=
+    prevopt=
+    continue
+  fi
+
+  # Have we seen a non-optional argument yet?
+  case "$arg" in
+  --help)
+    show_help=yes
+    ;;
+
+  --version)
+    echo "$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP"
+    exit 0
+    ;;
+
+  --config)
+    sed -e '1,/^### BEGIN LIBTOOL CONFIG/d' -e '/^### END LIBTOOL CONFIG/,$d' $0
+    exit 0
+    ;;
+
+  --debug)
+    echo "$progname: enabling shell trace mode"
+    set -x
+    ;;
+
+  --dry-run | -n)
+    run=:
+    ;;
+
+  --features)
+    echo "host: $host"
+    if test "$build_libtool_libs" = yes; then
+      echo "enable shared libraries"
+    else
+      echo "disable shared libraries"
+    fi
+    if test "$build_old_libs" = yes; then
+      echo "enable static libraries"
+    else
+      echo "disable static libraries"
+    fi
+    exit 0
+    ;;
+
+  --finish) mode="finish" ;;
+
+  --mode) prevopt="--mode" prev=mode ;;
+  --mode=*) mode="$optarg" ;;
+
+  --quiet | --silent)
+    show=:
+    ;;
+
+  -dlopen)
+    prevopt="-dlopen"
+    prev=execute_dlfiles
+    ;;
+
+  -*)
+    $echo "$modename: unrecognized option \`$arg'" 1>&2
+    $echo "$help" 1>&2
+    exit 1
+    ;;
+
+  *)
+    nonopt="$arg"
+    break
+    ;;
+  esac
+done
+
+if test -n "$prevopt"; then
+  $echo "$modename: option \`$prevopt' requires an argument" 1>&2
+  $echo "$help" 1>&2
+  exit 1
+fi
+
+if test -z "$show_help"; then
+
+  # Infer the operation mode.
+  if test -z "$mode"; then
+    case "$nonopt" in
+    *cc | *++ | gcc* | *-gcc*)
+      mode=link
+      for arg
+      do
+	case "$arg" in
+	-c)
+	   mode=compile
+	   break
+	   ;;
+	esac
+      done
+      ;;
+    *db | *dbx | *strace | *truss)
+      mode=execute
+      ;;
+    *install*|cp|mv)
+      mode=install
+      ;;
+    *rm)
+      mode=uninstall
+      ;;
+    *)
+      # If we have no mode, but dlfiles were specified, then do execute mode.
+      test -n "$execute_dlfiles" && mode=execute
+
+      # Just use the default operation mode.
+      if test -z "$mode"; then
+	if test -n "$nonopt"; then
+	  $echo "$modename: warning: cannot infer operation mode from \`$nonopt'" 1>&2
+	else
+	  $echo "$modename: warning: cannot infer operation mode without MODE-ARGS" 1>&2
+	fi
+      fi
+      ;;
+    esac
+  fi
+
+  # Only execute mode is allowed to have -dlopen flags.
+  if test -n "$execute_dlfiles" && test "$mode" != execute; then
+    $echo "$modename: unrecognized option \`-dlopen'" 1>&2
+    $echo "$help" 1>&2
+    exit 1
+  fi
+
+  # Change the help message to a mode-specific one.
+  generic_help="$help"
+  help="Try \`$modename --help --mode=$mode' for more information."
+
+  # These modes are in order of execution frequency so that they run quickly.
+  case "$mode" in
+  # libtool compile mode
+  compile)
+    modename="$modename: compile"
+    # Get the compilation command and the source file.
+    base_compile=
+    lastarg=
+    srcfile="$nonopt"
+    suppress_output=
+
+    user_target=no
+    for arg
+    do
+      # Accept any command-line options.
+      case "$arg" in
+      -o)
+	if test "$user_target" != "no"; then
+	  $echo "$modename: you cannot specify \`-o' more than once" 1>&2
+	  exit 1
+	fi
+	user_target=next
+	;;
+
+      -static)
+	build_old_libs=yes
+	continue
+	;;
+      esac
+
+      case "$user_target" in
+      next)
+	# The next one is the -o target name
+	user_target=yes
+	continue
+	;;
+      yes)
+	# We got the output file
+	user_target=set
+	libobj="$arg"
+	continue
+	;;
+      esac
+
+      # Accept the current argument as the source file.
+      lastarg="$srcfile"
+      srcfile="$arg"
+
+      # Aesthetically quote the previous argument.
+
+      # Backslashify any backslashes, double quotes, and dollar signs.
+      # These are the only characters that are still specially
+      # interpreted inside of double-quoted scrings.
+      lastarg=`$echo "X$lastarg" | $Xsed -e "$sed_quote_subst"`
+
+      # Double-quote args containing other shell metacharacters.
+      # Many Bourne shells cannot handle close brackets correctly in scan
+      # sets, so we specify it separately.
+      case "$lastarg" in
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+	lastarg="\"$lastarg\""
+	;;
+      esac
+
+      # Add the previous argument to base_compile.
+      if test -z "$base_compile"; then
+	base_compile="$lastarg"
+      else
+	base_compile="$base_compile $lastarg"
+      fi
+    done
+
+    case "$user_target" in
+    set)
+      ;;
+    no)
+      # Get the name of the library object.
+      libobj=`$echo "X$srcfile" | $Xsed -e 's%^.*/%%'`
+      ;;
+    *)
+      $echo "$modename: you must specify a target with \`-o'" 1>&2
+      exit 1
+      ;;
+    esac
+
+    # Recognize several different file suffixes.
+    # If the user specifies -o file.o, it is replaced with file.lo
+    xform='[cCFSfmso]'
+    case "$libobj" in
+    *.ada) xform=ada ;;
+    *.adb) xform=adb ;;
+    *.ads) xform=ads ;;
+    *.asm) xform=asm ;;
+    *.c++) xform=c++ ;;
+    *.cc) xform=cc ;;
+    *.cpp) xform=cpp ;;
+    *.cxx) xform=cxx ;;
+    *.f90) xform=f90 ;;
+    *.for) xform=for ;;
+    esac
+
+    libobj=`$echo "X$libobj" | $Xsed -e "s/\.$xform$/.lo/"`
+
+    case "$libobj" in
+    *.lo) obj=`$echo "X$libobj" | $Xsed -e "$lo2o"` ;;
+    *)
+      $echo "$modename: cannot determine name of library object from \`$libobj'" 1>&2
+      exit 1
+      ;;
+    esac
+
+    if test -z "$base_compile"; then
+      $echo "$modename: you must specify a compilation command" 1>&2
+      $echo "$help" 1>&2
+      exit 1
+    fi
+
+    # Delete any leftover library objects.
+    if test "$build_old_libs" = yes; then
+      removelist="$obj $libobj"
+    else
+      removelist="$libobj"
+    fi
+
+    $run $rm $removelist
+    trap "$run $rm $removelist; exit 1" 1 2 15
+
+    # Calculate the filename of the output object if compiler does
+    # not support -o with -c
+    if test "$compiler_c_o" = no; then
+      output_obj=`$echo "X$srcfile" | $Xsed -e 's%^.*/%%' -e 's%\..*$%%'`.${objext}
+      lockfile="$output_obj.lock"
+      removelist="$removelist $output_obj $lockfile"
+      trap "$run $rm $removelist; exit 1" 1 2 15
+    else
+      need_locks=no
+      lockfile=
+    fi
+
+    # Lock this critical section if it is needed
+    # We use this script file to make the link, it avoids creating a new file
+    if test "$need_locks" = yes; then
+      until ln "$0" "$lockfile" 2>/dev/null; do
+	$show "Waiting for $lockfile to be removed"
+	sleep 2
+      done
+    elif test "$need_locks" = warn; then
+      if test -f "$lockfile"; then
+	echo "\
+*** ERROR, $lockfile exists and contains:
+`cat $lockfile 2>/dev/null`
+
+This indicates that another process is trying to use the same
+temporary object file, and libtool could not work around it because
+your compiler does not support \`-c' and \`-o' together.  If you
+repeat this compilation, it may succeed, by chance, but you had better
+avoid parallel builds (make -j) in this platform, or get a better
+compiler."
+
+	$run $rm $removelist
+	exit 1
+      fi
+      echo $srcfile > "$lockfile"
+    fi
+
+    if test -n "$fix_srcfile_path"; then
+      eval srcfile=\"$fix_srcfile_path\"
+    fi
+
+    # Only build a PIC object if we are building libtool libraries.
+    if test "$build_libtool_libs" = yes; then
+      # Without this assignment, base_compile gets emptied.
+      fbsd_hideous_sh_bug=$base_compile
+
+      # All platforms use -DPIC, to notify preprocessed assembler code.
+      command="$base_compile $srcfile $pic_flag -DPIC"
+      if test "$build_old_libs" = yes; then
+	lo_libobj="$libobj"
+	dir=`$echo "X$libobj" | $Xsed -e 's%/[^/]*$%%'`
+	if test "X$dir" = "X$libobj"; then
+	  dir="$objdir"
+	else
+	  dir="$dir/$objdir"
+	fi
+	libobj="$dir/"`$echo "X$libobj" | $Xsed -e 's%^.*/%%'`
+
+	if test -d "$dir"; then
+	  $show "$rm $libobj"
+	  $run $rm $libobj
+	else
+	  $show "$mkdir $dir"
+	  $run $mkdir $dir
+	  status=$?
+	  if test $status -ne 0 && test ! -d $dir; then
+	    exit $status
+	  fi
+	fi
+      fi
+      if test "$compiler_o_lo" = yes; then
+	output_obj="$libobj"
+	command="$command -o $output_obj"
+      elif test "$compiler_c_o" = yes; then
+	output_obj="$obj"
+	command="$command -o $output_obj"
+      fi
+
+      $run $rm "$output_obj"
+      $show "$command"
+      if $run eval "$command"; then :
+      else
+	test -n "$output_obj" && $run $rm $removelist
+	exit 1
+      fi
+
+      if test "$need_locks" = warn &&
+	 test x"`cat $lockfile 2>/dev/null`" != x"$srcfile"; then
+	echo "\
+*** ERROR, $lockfile contains:
+`cat $lockfile 2>/dev/null`
+
+but it should contain:
+$srcfile
+
+This indicates that another process is trying to use the same
+temporary object file, and libtool could not work around it because
+your compiler does not support \`-c' and \`-o' together.  If you
+repeat this compilation, it may succeed, by chance, but you had better
+avoid parallel builds (make -j) in this platform, or get a better
+compiler."
+
+	$run $rm $removelist
+	exit 1
+      fi
+
+      # Just move the object if needed, then go on to compile the next one
+      if test x"$output_obj" != x"$libobj"; then
+	$show "$mv $output_obj $libobj"
+	if $run $mv $output_obj $libobj; then :
+	else
+	  error=$?
+	  $run $rm $removelist
+	  exit $error
+	fi
+      fi
+
+      # If we have no pic_flag, then copy the object into place and finish.
+      if test -z "$pic_flag" && test "$build_old_libs" = yes; then
+	# Rename the .lo from within objdir to obj
+	if test -f $obj; then
+	  $show $rm $obj
+	  $run $rm $obj
+	fi
+
+	$show "$mv $libobj $obj"
+	if $run $mv $libobj $obj; then :
+	else
+	  error=$?
+	  $run $rm $removelist
+	  exit $error
+	fi
+
+	xdir=`$echo "X$obj" | $Xsed -e 's%/[^/]*$%%'`
+	if test "X$xdir" = "X$obj"; then
+	  xdir="."
+	else
+	  xdir="$xdir"
+	fi
+	baseobj=`$echo "X$obj" | $Xsed -e "s%.*/%%"`
+	libobj=`$echo "X$baseobj" | $Xsed -e "$o2lo"`
+	# Now arrange that obj and lo_libobj become the same file
+	$show "(cd $xdir && $LN_S $baseobj $libobj)"
+	if $run eval '(cd $xdir && $LN_S $baseobj $libobj)'; then
+	  exit 0
+	else
+	  error=$?
+	  $run $rm $removelist
+	  exit $error
+	fi
+      fi
+
+      # Allow error messages only from the first compilation.
+      suppress_output=' >/dev/null 2>&1'
+    fi
+
+    # Only build a position-dependent object if we build old libraries.
+    if test "$build_old_libs" = yes; then
+      command="$base_compile $srcfile"
+      if test "$compiler_c_o" = yes; then
+	command="$command -o $obj"
+	output_obj="$obj"
+      fi
+
+      # Suppress compiler output if we already did a PIC compilation.
+      command="$command$suppress_output"
+      $run $rm "$output_obj"
+      $show "$command"
+      if $run eval "$command"; then :
+      else
+	$run $rm $removelist
+	exit 1
+      fi
+
+      if test "$need_locks" = warn &&
+	 test x"`cat $lockfile 2>/dev/null`" != x"$srcfile"; then
+	echo "\
+*** ERROR, $lockfile contains:
+`cat $lockfile 2>/dev/null`
+
+but it should contain:
+$srcfile
+
+This indicates that another process is trying to use the same
+temporary object file, and libtool could not work around it because
+your compiler does not support \`-c' and \`-o' together.  If you
+repeat this compilation, it may succeed, by chance, but you had better
+avoid parallel builds (make -j) in this platform, or get a better
+compiler."
+
+	$run $rm $removelist
+	exit 1
+      fi
+
+      # Just move the object if needed
+      if test x"$output_obj" != x"$obj"; then
+	$show "$mv $output_obj $obj"
+	if $run $mv $output_obj $obj; then :
+	else
+	  error=$?
+	  $run $rm $removelist
+	  exit $error
+	fi
+      fi
+
+      # Create an invalid libtool object if no PIC, so that we do not
+      # accidentally link it into a program.
+      if test "$build_libtool_libs" != yes; then
+	$show "echo timestamp > $libobj"
+	$run eval "echo timestamp > \$libobj" || exit $?
+      else
+	# Move the .lo from within objdir
+	$show "$mv $libobj $lo_libobj"
+	if $run $mv $libobj $lo_libobj; then :
+	else
+	  error=$?
+	  $run $rm $removelist
+	  exit $error
+	fi
+      fi
+    fi
+
+    # Unlock the critical section if it was locked
+    if test "$need_locks" != no; then
+      $rm "$lockfile"
+    fi
+
+    exit 0
+    ;;
+
+  # libtool link mode
+  link)
+    modename="$modename: link"
+    case "$host" in
+    *-*-cygwin* | *-*-mingw* | *-*-os2*)
+      # It is impossible to link a dll without this setting, and
+      # we shouldn't force the makefile maintainer to figure out
+      # which system we are compiling for in order to pass an extra
+      # flag for every libtool invokation.
+      # allow_undefined=no
+
+      # FIXME: Unfortunately, there are problems with the above when trying
+      # to make a dll which has undefined symbols, in which case not
+      # even a static library is built.  For now, we need to specify
+      # -no-undefined on the libtool link line when we can be certain
+      # that all symbols are satisfied, otherwise we get a static library.
+      allow_undefined=yes
+
+      # This is a source program that is used to create dlls on Windows
+      # Don't remove nor modify the starting and closing comments
+# /* ltdll.c starts here */
+# #define WIN32_LEAN_AND_MEAN
+# #include <windows.h>
+# #undef WIN32_LEAN_AND_MEAN
+# #include <stdio.h>
+#
+# #ifndef __CYGWIN__
+# #  ifdef __CYGWIN32__
+# #    define __CYGWIN__ __CYGWIN32__
+# #  endif
+# #endif
+#
+# #ifdef __cplusplus
+# extern "C" {
+# #endif
+# BOOL APIENTRY DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved);
+# #ifdef __cplusplus
+# }
+# #endif
+#
+# #ifdef __CYGWIN__
+# #include <cygwin/cygwin_dll.h>
+# DECLARE_CYGWIN_DLL( DllMain );
+# #endif
+# HINSTANCE __hDllInstance_base;
+#
+# BOOL APIENTRY
+# DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved)
+# {
+#   __hDllInstance_base = hInst;
+#   return TRUE;
+# }
+# /* ltdll.c ends here */
+      # This is a source program that is used to create import libraries
+      # on Windows for dlls which lack them. Don't remove nor modify the
+      # starting and closing comments
+# /* impgen.c starts here */
+# /*   Copyright (C) 1999 Free Software Foundation, Inc.
+# 
+#  This file is part of GNU libtool.
+# 
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+# 
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+# 
+#  You should have received a copy of the GNU General Public License
+#  along with this program; if not, write to the Free Software
+#  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#  */
+# 
+#  #include <stdio.h>		/* for printf() */
+#  #include <unistd.h>		/* for open(), lseek(), read() */
+#  #include <fcntl.h>		/* for O_RDONLY, O_BINARY */
+#  #include <string.h>		/* for strdup() */
+# 
+#  static unsigned int
+#  pe_get16 (fd, offset)
+#       int fd;
+#       int offset;
+#  {
+#    unsigned char b[2];
+#    lseek (fd, offset, SEEK_SET);
+#    read (fd, b, 2);
+#    return b[0] + (b[1]<<8);
+#  }
+# 
+#  static unsigned int
+#  pe_get32 (fd, offset)
+#      int fd;
+#      int offset;
+#  {
+#    unsigned char b[4];
+#    lseek (fd, offset, SEEK_SET);
+#    read (fd, b, 4);
+#    return b[0] + (b[1]<<8) + (b[2]<<16) + (b[3]<<24);
+#  }
+# 
+#  static unsigned int
+#  pe_as32 (ptr)
+#       void *ptr;
+#  {
+#    unsigned char *b = ptr;
+#    return b[0] + (b[1]<<8) + (b[2]<<16) + (b[3]<<24);
+#  }
+# 
+#  int
+#  main (argc, argv)
+#      int argc;
+#      char *argv[];
+#  {
+#      int dll;
+#      unsigned long pe_header_offset, opthdr_ofs, num_entries, i;
+#      unsigned long export_rva, export_size, nsections, secptr, expptr;
+#      unsigned long name_rvas, nexp;
+#      unsigned char *expdata, *erva;
+#      char *filename, *dll_name;
+# 
+#      filename = argv[1];
+# 
+#      dll = open(filename, O_RDONLY|O_BINARY);
+#      if (!dll)
+#  	return 1;
+# 
+#      dll_name = filename;
+#    
+#      for (i=0; filename[i]; i++)
+#  	if (filename[i] == '/' || filename[i] == '\\'  || filename[i] == ':')
+#  	    dll_name = filename + i +1;
+# 
+#      pe_header_offset = pe_get32 (dll, 0x3c);
+#      opthdr_ofs = pe_header_offset + 4 + 20;
+#      num_entries = pe_get32 (dll, opthdr_ofs + 92);
+# 
+#      if (num_entries < 1) /* no exports */
+#  	return 1;
+# 
+#      export_rva = pe_get32 (dll, opthdr_ofs + 96);
+#      export_size = pe_get32 (dll, opthdr_ofs + 100);
+#      nsections = pe_get16 (dll, pe_header_offset + 4 +2);
+#      secptr = (pe_header_offset + 4 + 20 +
+#  	      pe_get16 (dll, pe_header_offset + 4 + 16));
+# 
+#      expptr = 0;
+#      for (i = 0; i < nsections; i++)
+#      {
+#  	char sname[8];
+#  	unsigned long secptr1 = secptr + 40 * i;
+#  	unsigned long vaddr = pe_get32 (dll, secptr1 + 12);
+#  	unsigned long vsize = pe_get32 (dll, secptr1 + 16);
+#  	unsigned long fptr = pe_get32 (dll, secptr1 + 20);
+#  	lseek(dll, secptr1, SEEK_SET);
+#  	read(dll, sname, 8);
+#  	if (vaddr <= export_rva && vaddr+vsize > export_rva)
+#  	{
+#  	    expptr = fptr + (export_rva - vaddr);
+#  	    if (export_rva + export_size > vaddr + vsize)
+#  		export_size = vsize - (export_rva - vaddr);
+#  	    break;
+#  	}
+#      }
+# 
+#      expdata = (unsigned char*)malloc(export_size);
+#      lseek (dll, expptr, SEEK_SET);
+#      read (dll, expdata, export_size);
+#      erva = expdata - export_rva;
+# 
+#      nexp = pe_as32 (expdata+24);
+#      name_rvas = pe_as32 (expdata+32);
+# 
+#      printf ("EXPORTS\n");
+#      for (i = 0; i<nexp; i++)
+#      {
+#  	unsigned long name_rva = pe_as32 (erva+name_rvas+i*4);
+#  	printf ("\t%s @ %ld ;\n", erva+name_rva, 1+ i);
+#      }
+# 
+#      return 0;
+#  }
+# /* impgen.c ends here */
+      ;;
+    *)
+      allow_undefined=yes
+      ;;
+    esac
+    compile_command="$nonopt"
+    finalize_command="$nonopt"
+
+    compile_rpath=
+    finalize_rpath=
+    compile_shlibpath=
+    finalize_shlibpath=
+    convenience=
+    old_convenience=
+    deplibs=
+    linkopts=
+
+    if test -n "$shlibpath_var"; then
+      # get the directories listed in $shlibpath_var
+      eval lib_search_path=\`\$echo \"X \${$shlibpath_var}\" \| \$Xsed -e \'s/:/ /g\'\`
+    else
+      lib_search_path=
+    fi
+    # now prepend the system-specific ones
+    eval lib_search_path=\"$sys_lib_search_path_spec\$lib_search_path\"
+    eval sys_lib_dlsearch_path=\"$sys_lib_dlsearch_path_spec\"
+    
+    avoid_version=no
+    dlfiles=
+    dlprefiles=
+    dlself=no
+    export_dynamic=no
+    export_symbols=
+    export_symbols_regex=
+    generated=
+    libobjs=
+    link_against_libtool_libs=
+    ltlibs=
+    module=no
+    objs=
+    prefer_static_libs=no
+    preload=no
+    prev=
+    prevarg=
+    release=
+    rpath=
+    xrpath=
+    perm_rpath=
+    temp_rpath=
+    thread_safe=no
+    vinfo=
+
+    # We need to know -static, to get the right output filenames.
+    for arg
+    do
+      case "$arg" in
+      -all-static | -static)
+	if test "X$arg" = "X-all-static"; then
+	  if test "$build_libtool_libs" = yes && test -z "$link_static_flag"; then
+	    $echo "$modename: warning: complete static linking is impossible in this configuration" 1>&2
+	  fi
+	  if test -n "$link_static_flag"; then
+	    dlopen_self=$dlopen_self_static
+	  fi
+	else
+	  if test -z "$pic_flag" && test -n "$link_static_flag"; then
+	    dlopen_self=$dlopen_self_static
+	  fi
+	fi
+	build_libtool_libs=no
+	build_old_libs=yes
+	prefer_static_libs=yes
+	break
+	;;
+      esac
+    done
+
+    # See if our shared archives depend on static archives.
+    test -n "$old_archive_from_new_cmds" && build_old_libs=yes
+
+    # Go through the arguments, transforming them on the way.
+    while test $# -gt 0; do
+      arg="$1"
+      shift
+
+      # If the previous option needs an argument, assign it.
+      if test -n "$prev"; then
+	case "$prev" in
+	output)
+	  compile_command="$compile_command @OUTPUT@"
+	  finalize_command="$finalize_command @OUTPUT@"
+	  ;;
+	esac
+
+	case "$prev" in
+	dlfiles|dlprefiles)
+	  if test "$preload" = no; then
+	    # Add the symbol object into the linking commands.
+	    compile_command="$compile_command @SYMFILE@"
+	    finalize_command="$finalize_command @SYMFILE@"
+	    preload=yes
+	  fi
+	  case "$arg" in
+	  *.la | *.lo) ;;  # We handle these cases below.
+	  force)
+	    if test "$dlself" = no; then
+	      dlself=needless
+	      export_dynamic=yes
+	    fi
+	    prev=
+	    continue
+	    ;;
+	  self)
+	    if test "$prev" = dlprefiles; then
+	      dlself=yes
+	    elif test "$prev" = dlfiles && test "$dlopen_self" != yes; then
+	      dlself=yes
+	    else
+	      dlself=needless
+	      export_dynamic=yes
+	    fi
+	    prev=
+	    continue
+	    ;;
+	  *)
+	    if test "$prev" = dlfiles; then
+	      dlfiles="$dlfiles $arg"
+	    else
+	      dlprefiles="$dlprefiles $arg"
+	    fi
+	    prev=
+	    ;;
+	  esac
+	  ;;
+	expsyms)
+	  export_symbols="$arg"
+	  if test ! -f "$arg"; then
+	    $echo "$modename: symbol file \`$arg' does not exist"
+	    exit 1
+	  fi
+	  prev=
+	  continue
+	  ;;
+	expsyms_regex)
+	  export_symbols_regex="$arg"
+	  prev=
+	  continue
+	  ;;
+	release)
+	  release="-$arg"
+	  prev=
+	  continue
+	  ;;
+	rpath | xrpath)
+	  # We need an absolute path.
+	  case "$arg" in
+	  [\\/]* | [A-Za-z]:[\\/]*) ;;
+	  *)
+	    $echo "$modename: only absolute run-paths are allowed" 1>&2
+	    exit 1
+	    ;;
+	  esac
+	  if test "$prev" = rpath; then
+	    case "$rpath " in
+	    *" $arg "*) ;;
+	    *) rpath="$rpath $arg" ;;
+	    esac
+	  else
+	    case "$xrpath " in
+	    *" $arg "*) ;;
+	    *) xrpath="$xrpath $arg" ;;
+	    esac
+	  fi
+	  prev=
+	  continue
+	  ;;
+	*)
+	  eval "$prev=\"\$arg\""
+	  prev=
+	  continue
+	  ;;
+	esac
+      fi
+
+      prevarg="$arg"
+
+      case "$arg" in
+      -all-static)
+	if test -n "$link_static_flag"; then
+	  compile_command="$compile_command $link_static_flag"
+	  finalize_command="$finalize_command $link_static_flag"
+	fi
+	continue
+	;;
+
+      -allow-undefined)
+	# FIXME: remove this flag sometime in the future.
+	$echo "$modename: \`-allow-undefined' is deprecated because it is the default" 1>&2
+	continue
+	;;
+
+      -avoid-version)
+	avoid_version=yes
+	continue
+	;;
+
+      -dlopen)
+	prev=dlfiles
+	continue
+	;;
+
+      -dlpreopen)
+	prev=dlprefiles
+	continue
+	;;
+
+      -export-dynamic)
+	export_dynamic=yes
+	continue
+	;;
+
+      -export-symbols | -export-symbols-regex)
+	if test -n "$export_symbols" || test -n "$export_symbols_regex"; then
+	  $echo "$modename: not more than one -exported-symbols argument allowed"
+	  exit 1
+	fi
+	if test "X$arg" = "X-export-symbols"; then
+	  prev=expsyms
+	else
+	  prev=expsyms_regex
+	fi
+	continue
+	;;
+
+      -L*)
+	dir=`$echo "X$arg" | $Xsed -e 's/^-L//'`
+	# We need an absolute path.
+	case "$dir" in
+	[\\/]* | [A-Za-z]:[\\/]*) ;;
+	*)
+	  absdir=`cd "$dir" && pwd`
+	  if test -z "$absdir"; then
+	    $echo "$modename: warning: cannot determine absolute directory name of \`$dir'" 1>&2
+	    $echo "$modename: passing it literally to the linker, although it might fail" 1>&2
+	    absdir="$dir"
+	  fi
+	  dir="$absdir"
+	  ;;
+	esac
+	case " $deplibs " in
+	*" $arg "*) ;;
+	*) deplibs="$deplibs $arg";;
+	esac
+	case " $lib_search_path " in
+	*" $dir "*) ;;
+	*) lib_search_path="$lib_search_path $dir";;
+	esac
+	case "$host" in
+	*-*-cygwin* | *-*-mingw* | *-*-os2*)
+	  dllsearchdir=`cd "$dir" && pwd || echo "$dir"`
+	  case ":$dllsearchpath:" in
+	  ::) dllsearchpath="$dllsearchdir";;
+	  *":$dllsearchdir:"*) ;;
+	  *) dllsearchpath="$dllsearchpath:$dllsearchdir";;
+	  esac
+	  ;;
+	esac
+	;;
+
+      -l*)
+	if test "$arg" = "-lc"; then
+	  case "$host" in
+	  *-*-cygwin* | *-*-mingw* | *-*-os2* | *-*-beos*)
+	    # These systems don't actually have c library (as such)
+	    continue
+	    ;;
+	  esac
+	elif test "$arg" = "-lm"; then
+	  case "$host" in
+	  *-*-cygwin* | *-*-beos*)
+	    # These systems don't actually have math library (as such)
+	    continue
+	    ;;
+	  esac
+	fi
+	deplibs="$deplibs $arg"
+	;;
+
+      -module)
+	module=yes
+	continue
+	;;
+
+      -no-undefined)
+	allow_undefined=no
+	continue
+	;;
+
+      -o) prev=output ;;
+
+      -release)
+	prev=release
+	continue
+	;;
+
+      -rpath)
+	prev=rpath
+	continue
+	;;
+
+      -R)
+	prev=xrpath
+	continue
+	;;
+
+      -R*)
+	dir=`$echo "X$arg" | $Xsed -e 's/^-R//'`
+	# We need an absolute path.
+	case "$dir" in
+	[\\/]* | [A-Za-z]:[\\/]*) ;;
+	*)
+	  $echo "$modename: only absolute run-paths are allowed" 1>&2
+	  exit 1
+	  ;;
+	esac
+	case "$xrpath " in
+	*" $dir "*) ;;
+	*) xrpath="$xrpath $dir" ;;
+	esac
+	continue
+	;;
+
+      -static)
+	# If we have no pic_flag, then this is the same as -all-static.
+	if test -z "$pic_flag" && test -n "$link_static_flag"; then
+	  compile_command="$compile_command $link_static_flag"
+	  finalize_command="$finalize_command $link_static_flag"
+	fi
+	continue
+	;;
+
+      -thread-safe)
+	thread_safe=yes
+	continue
+	;;
+
+      -version-info)
+	prev=vinfo
+	continue
+	;;
+
+      # Some other compiler flag.
+      -* | +*)
+	# Unknown arguments in both finalize_command and compile_command need
+	# to be aesthetically quoted because they are evaled later.
+	arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
+	case "$arg" in
+	*[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+	  arg="\"$arg\""
+	  ;;
+	esac
+	;;
+
+      *.o | *.obj | *.a | *.lib)
+	# A standard object.
+	objs="$objs $arg"
+	;;
+
+      *.lo)
+	# A library object.
+	if test "$prev" = dlfiles; then
+	  dlfiles="$dlfiles $arg"
+	  if test "$build_libtool_libs" = yes && test "$dlopen" = yes; then
+	    prev=
+	    continue
+	  else
+	    # If libtool objects are unsupported, then we need to preload.
+	    prev=dlprefiles
+	  fi
+	fi
+
+	if test "$prev" = dlprefiles; then
+	  # Preload the old-style object.
+	  dlprefiles="$dlprefiles "`$echo "X$arg" | $Xsed -e "$lo2o"`
+	  prev=
+	fi
+	libobjs="$libobjs $arg"
+	;;
+
+      *.la)
+	# A libtool-controlled library.
+
+	dlname=
+	libdir=
+	library_names=
+	old_library=
+
+	# Check to see that this really is a libtool archive.
+	if (sed -e '2q' $arg | egrep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then :
+	else
+	  $echo "$modename: \`$arg' is not a valid libtool archive" 1>&2
+	  exit 1
+	fi
+
+	# If the library was installed with an old release of libtool,
+	# it will not redefine variable installed.
+	installed=yes
+
+	# Read the .la file
+	# If there is no directory component, then add one.
+	case "$arg" in
+	*/* | *\\*) . $arg ;;
+	*) . ./$arg ;;
+	esac
+
+	# Get the name of the library we link against.
+	linklib=
+	for l in $old_library $library_names; do
+	  linklib="$l"
+	done
+
+	if test -z "$linklib"; then
+	  $echo "$modename: cannot find name of link library for \`$arg'" 1>&2
+	  exit 1
+	fi
+
+	# Find the relevant object directory and library name.
+	name=`$echo "X$arg" | $Xsed -e 's%^.*/%%' -e 's/\.la$//' -e 's/^lib//'`
+
+	if test "X$installed" = Xyes; then
+	  dir="$libdir"
+	else
+	  dir=`$echo "X$arg" | $Xsed -e 's%/[^/]*$%%'`
+	  if test "X$dir" = "X$arg"; then
+	    dir="$objdir"
+	  else
+	    dir="$dir/$objdir"
+	  fi
+	fi
+
+	if test -n "$dependency_libs"; then
+	  # Extract -R and -L from dependency_libs
+	  temp_deplibs=
+	  for deplib in $dependency_libs; do
+	    case "$deplib" in
+	    -R*) temp_xrpath=`$echo "X$deplib" | $Xsed -e 's/^-R//'`
+		 case " $rpath $xrpath " in
+		 *" $temp_xrpath "*) ;;
+		 *) xrpath="$xrpath $temp_xrpath";;
+		 esac;;
+	    -L*) case "$compile_command $temp_deplibs " in
+		 *" $deplib "*) ;;
+		 *) temp_deplibs="$temp_deplibs $deplib";;
+		 esac
+		 temp_dir=`$echo "X$deplib" | $Xsed -e 's/^-L//'`
+		 case " $lib_search_path " in
+		 *" $temp_dir "*) ;;
+		 *) lib_search_path="$lib_search_path $temp_dir";;
+		 esac
+		 ;;
+	    *) temp_deplibs="$temp_deplibs $deplib";;
+	    esac
+	  done
+	  dependency_libs="$temp_deplibs"
+	fi
+
+	if test -z "$libdir"; then
+	  # It is a libtool convenience library, so add in its objects.
+	  convenience="$convenience $dir/$old_library"
+	  old_convenience="$old_convenience $dir/$old_library"
+	  deplibs="$deplibs$dependency_libs"
+	  compile_command="$compile_command $dir/$old_library$dependency_libs"
+	  finalize_command="$finalize_command $dir/$old_library$dependency_libs"
+	  continue
+	fi
+
+	# This library was specified with -dlopen.
+	if test "$prev" = dlfiles; then
+	  dlfiles="$dlfiles $arg"
+	  if test -z "$dlname" || test "$dlopen" != yes || test "$build_libtool_libs" = no; then
+	    # If there is no dlname, no dlopen support or we're linking statically,
+	    # we need to preload.
+	    prev=dlprefiles
+	  else
+	    # We should not create a dependency on this library, but we
+	    # may need any libraries it requires.
+	    compile_command="$compile_command$dependency_libs"
+	    finalize_command="$finalize_command$dependency_libs"
+	    prev=
+	    continue
+	  fi
+	fi
+
+	# The library was specified with -dlpreopen.
+	if test "$prev" = dlprefiles; then
+	  # Prefer using a static library (so that no silly _DYNAMIC symbols
+	  # are required to link).
+	  if test -n "$old_library"; then
+	    dlprefiles="$dlprefiles $dir/$old_library"
+	  else
+	    dlprefiles="$dlprefiles $dir/$linklib"
+	  fi
+	  prev=
+	fi
+
+	if test -n "$library_names" &&
+	   { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
+	  link_against_libtool_libs="$link_against_libtool_libs $arg"
+	  if test -n "$shlibpath_var"; then
+	    # Make sure the rpath contains only unique directories.
+	    case "$temp_rpath " in
+	    *" $dir "*) ;;
+	    *) temp_rpath="$temp_rpath $dir" ;;
+	    esac
+	  fi
+
+	  # We need an absolute path.
+	  case "$dir" in
+	  [\\/] | [A-Za-z]:[\\/]*) absdir="$dir" ;;
+	  *)
+	    absdir=`cd "$dir" && pwd`
+	    if test -z "$absdir"; then
+	      $echo "$modename: warning: cannot determine absolute directory name of \`$dir'" 1>&2
+	      $echo "$modename: passing it literally to the linker, although it might fail" 1>&2
+	      absdir="$dir"
+	    fi
+	    ;;
+	  esac
+	  
+	  # This is the magic to use -rpath.
+	  # Skip directories that are in the system default run-time
+	  # search path, unless they have been requested with -R.
+	  case " $sys_lib_dlsearch_path " in
+	  *" $absdir "*) ;;
+	  *)
+	    case "$compile_rpath " in
+	    *" $absdir "*) ;;
+	    *) compile_rpath="$compile_rpath $absdir" 
+	    esac
+	    ;;
+	  esac
+
+	  case " $sys_lib_dlsearch_path " in
+	  *" $libdir "*) ;;
+	  *)
+	    case "$finalize_rpath " in
+	    *" $libdir "*) ;;
+	    *) finalize_rpath="$finalize_rpath $libdir"
+	    esac
+	    ;;
+	  esac
+
+	  lib_linked=yes
+	  case "$hardcode_action" in
+	  immediate | unsupported)
+	    if test "$hardcode_direct" = no; then
+	      compile_command="$compile_command $dir/$linklib"
+	      deplibs="$deplibs $dir/$linklib"
+	      case "$host" in
+	      *-*-cygwin* | *-*-mingw* | *-*-os2*)
+		dllsearchdir=`cd "$dir" && pwd || echo "$dir"`
+		if test -n "$dllsearchpath"; then
+		  dllsearchpath="$dllsearchpath:$dllsearchdir"
+		else
+		  dllsearchpath="$dllsearchdir"
+		fi
+		;;
+	      esac
+	    elif test "$hardcode_minus_L" = no; then
+	      case "$host" in
+	      *-*-sunos*)
+		compile_shlibpath="$compile_shlibpath$dir:"
+		;;
+	      esac
+	      case "$compile_command " in
+	      *" -L$dir "*) ;;
+	      *) compile_command="$compile_command -L$dir";;
+	      esac
+	      compile_command="$compile_command -l$name"
+	      deplibs="$deplibs -L$dir -l$name"
+	    elif test "$hardcode_shlibpath_var" = no; then
+	      case ":$compile_shlibpath:" in
+	      *":$dir:"*) ;;
+	      *) compile_shlibpath="$compile_shlibpath$dir:";;
+	      esac
+	      compile_command="$compile_command -l$name"
+	      deplibs="$deplibs -l$name"
+	    else
+	      lib_linked=no
+	    fi
+	    ;;
+
+	  relink)
+	    if test "$hardcode_direct" = yes; then
+	      compile_command="$compile_command $absdir/$linklib"
+	      deplibs="$deplibs $absdir/$linklib"
+	    elif test "$hardcode_minus_L" = yes; then
+	      case "$compile_command " in
+	      *" -L$absdir "*) ;;
+	      *) compile_command="$compile_command -L$absdir";;
+	      esac
+	      compile_command="$compile_command -l$name"
+	      deplibs="$deplibs -L$absdir -l$name"
+	    elif test "$hardcode_shlibpath_var" = yes; then
+	      case ":$compile_shlibpath:" in
+	      *":$absdir:"*) ;;
+	      *) compile_shlibpath="$compile_shlibpath$absdir:";;
+	      esac
+	      compile_command="$compile_command -l$name"
+	      deplibs="$deplibs -l$name"
+	    else
+	      lib_linked=no
+	    fi
+	    ;;
+
+	  *)
+	    lib_linked=no
+	    ;;
+	  esac
+
+	  if test "$lib_linked" != yes; then
+	    $echo "$modename: configuration error: unsupported hardcode properties"
+	    exit 1
+	  fi
+
+	  # Finalize command for both is simple: just hardcode it.
+	  if test "$hardcode_direct" = yes; then
+	    finalize_command="$finalize_command $libdir/$linklib"
+	  elif test "$hardcode_minus_L" = yes; then
+	    case "$finalize_command " in
+	    *" -L$libdir "*) ;;
+	    *) finalize_command="$finalize_command -L$libdir";;
+	    esac
+	    finalize_command="$finalize_command -l$name"
+	  elif test "$hardcode_shlibpath_var" = yes; then
+	    case ":$finalize_shlibpath:" in
+	    *":$libdir:"*) ;;
+	    *) finalize_shlibpath="$finalize_shlibpath$libdir:";;
+	    esac
+	    finalize_command="$finalize_command -l$name"
+	  else
+	    # We cannot seem to hardcode it, guess we'll fake it.
+	    case "$finalize_command " in
+	    *" -L$dir "*) ;;
+	    *) finalize_command="$finalize_command -L$libdir";;
+	    esac
+	    finalize_command="$finalize_command -l$name"
+	  fi
+	else
+	  # Transform directly to old archives if we don't build new libraries.
+	  if test -n "$pic_flag" && test -z "$old_library"; then
+	    $echo "$modename: cannot find static library for \`$arg'" 1>&2
+	    exit 1
+	  fi
+
+	  # Here we assume that one of hardcode_direct or hardcode_minus_L
+	  # is not unsupported.  This is valid on all known static and
+	  # shared platforms.
+	  if test "$hardcode_direct" != unsupported; then
+	    test -n "$old_library" && linklib="$old_library"
+	    compile_command="$compile_command $dir/$linklib"
+	    finalize_command="$finalize_command $dir/$linklib"
+	  else
+	    case "$compile_command " in
+	    *" -L$dir "*) ;;
+	    *) compile_command="$compile_command -L$dir";;
+	    esac
+	    compile_command="$compile_command -l$name"
+	    case "$finalize_command " in
+	    *" -L$dir "*) ;;
+	    *) finalize_command="$finalize_command -L$dir";;
+	    esac
+	    finalize_command="$finalize_command -l$name"
+	  fi
+	fi
+
+	# Add in any libraries that this one depends upon.
+	compile_command="$compile_command$dependency_libs"
+	finalize_command="$finalize_command$dependency_libs"
+	continue
+	;;
+
+      # Some other compiler argument.
+      *)
+	# Unknown arguments in both finalize_command and compile_command need
+	# to be aesthetically quoted because they are evaled later.
+	arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
+	case "$arg" in
+	*[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+	  arg="\"$arg\""
+	  ;;
+	esac
+	;;
+      esac
+
+      # Now actually substitute the argument into the commands.
+      if test -n "$arg"; then
+	compile_command="$compile_command $arg"
+	finalize_command="$finalize_command $arg"
+      fi
+    done
+
+    if test -n "$prev"; then
+      $echo "$modename: the \`$prevarg' option requires an argument" 1>&2
+      $echo "$help" 1>&2
+      exit 1
+    fi
+
+    if test "$export_dynamic" = yes && test -n "$export_dynamic_flag_spec"; then
+      eval arg=\"$export_dynamic_flag_spec\"
+      compile_command="$compile_command $arg"
+      finalize_command="$finalize_command $arg"
+    fi
+
+    oldlibs=
+    # calculate the name of the file, without its directory
+    outputname=`$echo "X$output" | $Xsed -e 's%^.*/%%'`
+    libobjs_save="$libobjs"
+
+    case "$output" in
+    "")
+      $echo "$modename: you must specify an output file" 1>&2
+      $echo "$help" 1>&2
+      exit 1
+      ;;
+
+    *.a | *.lib)
+      if test -n "$link_against_libtool_libs"; then
+	$echo "$modename: error: cannot link libtool libraries into archives" 1>&2
+	exit 1
+      fi
+
+      if test -n "$deplibs"; then
+	$echo "$modename: warning: \`-l' and \`-L' are ignored for archives" 1>&2
+      fi
+
+      if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
+	$echo "$modename: warning: \`-dlopen' is ignored for archives" 1>&2
+      fi
+
+      if test -n "$rpath"; then
+	$echo "$modename: warning: \`-rpath' is ignored for archives" 1>&2
+      fi
+
+      if test -n "$xrpath"; then
+	$echo "$modename: warning: \`-R' is ignored for archives" 1>&2
+      fi
+
+      if test -n "$vinfo"; then
+	$echo "$modename: warning: \`-version-info' is ignored for archives" 1>&2
+      fi
+
+      if test -n "$release"; then
+	$echo "$modename: warning: \`-release' is ignored for archives" 1>&2
+      fi
+
+      if test -n "$export_symbols" || test -n "$export_symbols_regex"; then
+	$echo "$modename: warning: \`-export-symbols' is ignored for archives" 1>&2
+      fi
+
+      # Now set the variables for building old libraries.
+      build_libtool_libs=no
+      oldlibs="$output"
+      ;;
+
+    *.la)
+      # Make sure we only generate libraries of the form `libNAME.la'.
+      case "$outputname" in
+      lib*)
+	name=`$echo "X$outputname" | $Xsed -e 's/\.la$//' -e 's/^lib//'`
+	eval libname=\"$libname_spec\"
+	;;
+      *)
+	if test "$module" = no; then
+	  $echo "$modename: libtool library \`$output' must begin with \`lib'" 1>&2
+	  $echo "$help" 1>&2
+	  exit 1
+	fi
+	if test "$need_lib_prefix" != no; then
+	  # Add the "lib" prefix for modules if required
+	  name=`$echo "X$outputname" | $Xsed -e 's/\.la$//'`
+	  eval libname=\"$libname_spec\"
+	else
+	  libname=`$echo "X$outputname" | $Xsed -e 's/\.la$//'`
+	fi
+	;;
+      esac
+
+      output_objdir=`$echo "X$output" | $Xsed -e 's%/[^/]*$%%'`
+      if test "X$output_objdir" = "X$output"; then
+	output_objdir="$objdir"
+      else
+	output_objdir="$output_objdir/$objdir"
+      fi
+
+      if test -n "$objs"; then
+	$echo "$modename: cannot build libtool library \`$output' from non-libtool objects:$objs" 2>&1
+	exit 1
+      fi
+
+      # How the heck are we supposed to write a wrapper for a shared library?
+      if test -n "$link_against_libtool_libs"; then
+	 $echo "$modename: error: cannot link shared libraries into libtool libraries" 1>&2
+	 exit 1
+      fi
+
+      if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
+	$echo "$modename: warning: \`-dlopen' is ignored for libtool libraries" 1>&2
+      fi
+
+      set dummy $rpath
+      if test $# -gt 2; then
+	$echo "$modename: warning: ignoring multiple \`-rpath's for a libtool library" 1>&2
+      fi
+      install_libdir="$2"
+
+      oldlibs=
+      if test -z "$rpath"; then
+	if test "$build_libtool_libs" = yes; then
+	  # Building a libtool convenience library.
+	  libext=al
+	  oldlibs="$output_objdir/$libname.$libext $oldlibs"
+	  build_libtool_libs=convenience
+	  build_old_libs=yes
+	fi
+	dependency_libs="$deplibs"
+
+	if test -n "$vinfo"; then
+	  $echo "$modename: warning: \`-version-info' is ignored for convenience libraries" 1>&2
+	fi
+
+	if test -n "$release"; then
+	  $echo "$modename: warning: \`-release' is ignored for convenience libraries" 1>&2
+	fi
+      else
+
+	# Parse the version information argument.
+	IFS="${IFS= 	}"; save_ifs="$IFS"; IFS=':'
+	set dummy $vinfo 0 0 0
+	IFS="$save_ifs"
+
+	if test -n "$8"; then
+	  $echo "$modename: too many parameters to \`-version-info'" 1>&2
+	  $echo "$help" 1>&2
+	  exit 1
+	fi
+
+	current="$2"
+	revision="$3"
+	age="$4"
+
+	# Check that each of the things are valid numbers.
+	case "$current" in
+	0 | [1-9] | [1-9][0-9]*) ;;
+	*)
+	  $echo "$modename: CURRENT \`$current' is not a nonnegative integer" 1>&2
+	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
+	  exit 1
+	  ;;
+	esac
+
+	case "$revision" in
+	0 | [1-9] | [1-9][0-9]*) ;;
+	*)
+	  $echo "$modename: REVISION \`$revision' is not a nonnegative integer" 1>&2
+	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
+	  exit 1
+	  ;;
+	esac
+
+	case "$age" in
+	0 | [1-9] | [1-9][0-9]*) ;;
+	*)
+	  $echo "$modename: AGE \`$age' is not a nonnegative integer" 1>&2
+	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
+	  exit 1
+	  ;;
+	esac
+
+	if test $age -gt $current; then
+	  $echo "$modename: AGE \`$age' is greater than the current interface number \`$current'" 1>&2
+	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
+	  exit 1
+	fi
+
+	# Calculate the version variables.
+	major=
+	versuffix=
+	verstring=
+	case "$version_type" in
+	none) ;;
+
+	irix)
+	  major=`expr $current - $age + 1`
+	  versuffix="$major.$revision"
+	  verstring="sgi$major.$revision"
+
+	  # Add in all the interfaces that we are compatible with.
+	  loop=$revision
+	  while test $loop != 0; do
+	    iface=`expr $revision - $loop`
+	    loop=`expr $loop - 1`
+	    verstring="sgi$major.$iface:$verstring"
+	  done
+	  ;;
+
+	linux)
+	  major=.`expr $current - $age`
+	  versuffix="$major.$age.$revision"
+	  ;;
+
+	osf)
+	  major=`expr $current - $age`
+	  versuffix=".$current.$age.$revision"
+	  verstring="$current.$age.$revision"
+
+	  # Add in all the interfaces that we are compatible with.
+	  loop=$age
+	  while test $loop != 0; do
+	    iface=`expr $current - $loop`
+	    loop=`expr $loop - 1`
+	    verstring="$verstring:${iface}.0"
+	  done
+
+	  # Make executables depend on our current version.
+	  verstring="$verstring:${current}.0"
+	  ;;
+
+	sunos)
+	  major=".$current"
+	  versuffix=".$current.$revision"
+	  ;;
+
+	freebsd-aout)
+	  major=".$current"
+	  versuffix=".$current.$revision";
+	  ;;
+
+	freebsd-elf)
+	  major=".$current"
+	  versuffix=".$current";
+	  ;;
+
+	windows)
+	  # Like Linux, but with '-' rather than '.', since we only
+	  # want one extension on Windows 95.
+	  major=`expr $current - $age`
+	  versuffix="-$major-$age-$revision"
+	  ;;
+
+	*)
+	  $echo "$modename: unknown library version type \`$version_type'" 1>&2
+	  echo "Fatal configuration error.  See the $PACKAGE docs for more information." 1>&2
+	  exit 1
+	  ;;
+	esac
+
+	# Clear the version info if we defaulted, and they specified a release.
+	if test -z "$vinfo" && test -n "$release"; then
+	  major=
+	  verstring="0.0"
+	  if test "$need_version" = no; then
+	    versuffix=
+	  else
+	    versuffix=".0.0"
+	  fi
+	fi
+
+	# Remove version info from name if versioning should be avoided
+	if test "$avoid_version" = yes && test "$need_version" = no; then
+	  major=
+	  versuffix=
+	  verstring=""
+	fi
+	
+	# Check to see if the archive will have undefined symbols.
+	if test "$allow_undefined" = yes; then
+	  if test "$allow_undefined_flag" = unsupported; then
+	    $echo "$modename: warning: undefined symbols not allowed in $host shared libraries" 1>&2
+	    build_libtool_libs=no
+	    build_old_libs=yes
+	  fi
+	else
+	  # Don't allow undefined symbols.
+	  allow_undefined_flag="$no_undefined_flag"
+	fi
+
+	dependency_libs="$deplibs"
+	case "$host" in
+	*-*-cygwin* | *-*-mingw* | *-*-os2* | *-*-beos*)
+	  # these systems don't actually have a c library (as such)!
+	  ;;
+        *-*-rhapsody*)
+	  # rhapsody is a little odd...
+	  deplibs="$deplibs -framework System"
+	  ;;
+	*)
+	  # Add libc to deplibs on all other systems.
+	  deplibs="$deplibs -lc"
+	  ;;
+	esac
+      fi
+
+      # Create the output directory, or remove our outputs if we need to.
+      if test -d $output_objdir; then
+	$show "${rm}r $output_objdir/$outputname $output_objdir/$libname.* $output_objdir/${libname}${release}.*"
+	$run ${rm}r $output_objdir/$outputname $output_objdir/$libname.* $output_objdir/${libname}${release}.*
+      else
+	$show "$mkdir $output_objdir"
+	$run $mkdir $output_objdir
+	status=$?
+	if test $status -ne 0 && test ! -d $output_objdir; then
+	  exit $status
+	fi
+      fi
+
+      # Now set the variables for building old libraries.
+      if test "$build_old_libs" = yes && test "$build_libtool_libs" != convenience ; then
+	oldlibs="$oldlibs $output_objdir/$libname.$libext"
+
+	# Transform .lo files to .o files.
+	oldobjs="$objs "`$echo "X$libobjs" | $SP2NL | $Xsed -e '/\.'${libext}'$/d' -e "$lo2o" | $NL2SP`
+      fi
+
+      if test "$build_libtool_libs" = yes; then
+	# Transform deplibs into only deplibs that can be linked in shared.
+	name_save=$name
+	libname_save=$libname
+	release_save=$release
+	versuffix_save=$versuffix
+	major_save=$major
+	# I'm not sure if I'm treating the release correctly.  I think
+	# release should show up in the -l (ie -lgmp5) so we don't want to
+	# add it in twice.  Is that correct?
+	release=""
+	versuffix=""
+	major=""
+	newdeplibs=
+	droppeddeps=no
+	case "$deplibs_check_method" in
+	pass_all)
+	  # Don't check for shared/static.  Everything works.
+	  # This might be a little naive.  We might want to check
+	  # whether the library exists or not.  But this is on
+	  # osf3 & osf4 and I'm not really sure... Just
+	  # implementing what was already the behaviour.
+	  newdeplibs=$deplibs
+	  ;;
+	test_compile)
+	  # This code stresses the "libraries are programs" paradigm to its
+	  # limits. Maybe even breaks it.  We compile a program, linking it
+	  # against the deplibs as a proxy for the library.  Then we can check
+	  # whether they linked in statically or dynamically with ldd.
+	  $rm conftest.c
+	  cat > conftest.c <<EOF
+	  int main() { return 0; }
+EOF
+	  $rm conftest
+	  $CC -o conftest conftest.c $deplibs
+	  if test $? -eq 0 ; then
+	    ldd_output=`ldd conftest`
+	    for i in $deplibs; do
+	      name="`expr $i : '-l\(.*\)'`"
+	      # If $name is empty we are operating on a -L argument.
+	      if test "$name" != "" ; then
+		libname=`eval \\$echo \"$libname_spec\"`
+		deplib_matches=`eval \\$echo \"$library_names_spec\"`
+		set dummy $deplib_matches
+		deplib_match=$2
+		if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
+		  newdeplibs="$newdeplibs $i"
+		else
+		  droppeddeps=yes
+		  echo
+		  echo "*** Warning: This library needs some functionality provided by $i."
+		  echo "*** I have the capability to make that library automatically link in when"
+		  echo "*** you link to this library.  But I can only do this if you have a"
+		  echo "*** shared version of the library, which you do not appear to have."
+		fi
+	      else
+		newdeplibs="$newdeplibs $i"
+	      fi
+	    done
+	  else
+	    # Error occured in the first compile.  Let's try to salvage the situation:
+	    # Compile a seperate program for each library.
+	    for i in $deplibs; do
+	      name="`expr $i : '-l\(.*\)'`"
+	     # If $name is empty we are operating on a -L argument.
+	      if test "$name" != "" ; then
+		$rm conftest
+		$CC -o conftest conftest.c $i
+		# Did it work?
+		if test $? -eq 0 ; then
+		  ldd_output=`ldd conftest`
+		  libname=`eval \\$echo \"$libname_spec\"`
+		  deplib_matches=`eval \\$echo \"$library_names_spec\"`
+		  set dummy $deplib_matches
+		  deplib_match=$2
+		  if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
+		    newdeplibs="$newdeplibs $i"
+		  else
+		    droppeddeps=yes
+		    echo
+		    echo "*** Warning: This library needs some functionality provided by $i."
+		    echo "*** I have the capability to make that library automatically link in when"
+		    echo "*** you link to this library.  But I can only do this if you have a"
+		    echo "*** shared version of the library, which you do not appear to have."
+		  fi
+		else
+		  droppeddeps=yes
+		  echo
+		  echo "*** Warning!  Library $i is needed by this library but I was not able to"
+		  echo "***  make it link in!  You will probably need to install it or some"
+		  echo "*** library that it depends on before this library will be fully"
+		  echo "*** functional.  Installing it before continuing would be even better."
+		fi
+	      else
+		newdeplibs="$newdeplibs $i"
+	      fi
+	    done
+	  fi
+	  ;;
+	file_magic*)
+	  set dummy $deplibs_check_method
+	  file_magic_regex="`expr \"$deplibs_check_method\" : \"$2 \(.*\)\"`"
+	  for a_deplib in $deplibs; do
+	    name="`expr $a_deplib : '-l\(.*\)'`"
+	    # If $name is empty we are operating on a -L argument.
+	    if test "$name" != "" ; then
+	      libname=`eval \\$echo \"$libname_spec\"`
+	      for i in $lib_search_path; do
+		    potential_libs=`ls $i/$libname[.-]* 2>/dev/null`
+		    for potent_lib in $potential_libs; do
+		      # Follow soft links.
+		      if ls -lLd "$potent_lib" 2>/dev/null \
+			 | grep " -> " >/dev/null; then
+			continue 
+		      fi
+		      # The statement above tries to avoid entering an
+		      # endless loop below, in case of cyclic links.
+		      # We might still enter an endless loop, since a link
+		      # loop can be closed while we follow links,
+		      # but so what?
+		      potlib="$potent_lib"
+		      while test -h "$potlib" 2>/dev/null; do
+			potliblink=`ls -ld $potlib | sed 's/.* -> //'`
+			case "$potliblink" in
+			[\\/]* | [A-Za-z]:[\\/]*) potlib="$potliblink";;
+			*) potlib=`$echo "X$potlib" | $Xsed -e 's,[^/]*$,,'`"$potliblink";;
+			esac
+		      done
+		      if eval $file_magic_cmd \"\$potlib\" 2>/dev/null \
+			 | sed 10q \
+			 | egrep "$file_magic_regex" > /dev/null; then
+			newdeplibs="$newdeplibs $a_deplib"
+			a_deplib=""
+			break 2
+		      fi
+		    done
+	      done
+	      if test -n "$a_deplib" ; then
+		droppeddeps=yes
+		echo
+		echo "*** Warning: This library needs some functionality provided by $a_deplib."
+		echo "*** I have the capability to make that library automatically link in when"
+		echo "*** you link to this library.  But I can only do this if you have a"
+		echo "*** shared version of the library, which you do not appear to have."
+	      fi
+	    else
+	      # Add a -L argument.
+	      newdeplibs="$newdeplibs $a_deplib"
+	    fi
+	  done # Gone through all deplibs.
+	  ;;
+	none | unknown | *)
+	  newdeplibs=""
+	  if $echo "X $deplibs" | $Xsed -e 's/ -lc$//' \
+	       -e 's/ -[LR][^ ]*//g' -e 's/[ 	]//g' |
+	     grep . >/dev/null; then
+	    echo
+	    if test "X$deplibs_check_method" = "Xnone"; then
+	      echo "*** Warning: inter-library dependencies are not supported in this platform."
+	    else
+	      echo "*** Warning: inter-library dependencies are not known to be supported."
+	    fi
+	    echo "*** All declared inter-library dependencies are being dropped."
+	    droppeddeps=yes
+	  fi
+	  ;;
+	esac
+	versuffix=$versuffix_save
+	major=$major_save
+	release=$release_save
+	libname=$libname_save
+	name=$name_save
+
+	if test "$droppeddeps" = yes; then
+	  if test "$module" = yes; then
+	    echo
+	    echo "*** Warning: libtool could not satisfy all declared inter-library"
+	    echo "*** dependencies of module $libname.  Therefore, libtool will create"
+	    echo "*** a static module, that should work as long as the dlopening"
+	    echo "*** application is linked with the -dlopen flag."
+	    if test -z "$global_symbol_pipe"; then
+	      echo
+	      echo "*** However, this would only work if libtool was able to extract symbol"
+	      echo "*** lists from a program, using \`nm' or equivalent, but libtool could"
+	      echo "*** not find such a program.  So, this module is probably useless."
+	      echo "*** \`nm' from GNU binutils and a full rebuild may help."
+	    fi
+	    if test "$build_old_libs" = no; then
+	      oldlibs="$output_objdir/$libname.$libext"
+	      build_libtool_libs=module
+	      build_old_libs=yes
+	    else
+	      build_libtool_libs=no
+	    fi
+	  else
+	    echo "*** The inter-library dependencies that have been dropped here will be"
+	    echo "*** automatically added whenever a program is linked with this library"
+	    echo "*** or is declared to -dlopen it."
+	  fi
+	fi
+	# Done checking deplibs!
+	deplibs=$newdeplibs
+      fi
+
+      # All the library-specific variables (install_libdir is set above).
+      library_names=
+      old_library=
+      dlname=
+      
+      # Test again, we may have decided not to build it any more
+      if test "$build_libtool_libs" = yes; then
+	# Get the real and link names of the library.
+	eval library_names=\"$library_names_spec\"
+	set dummy $library_names
+	realname="$2"
+	shift; shift
+
+	if test -n "$soname_spec"; then
+	  eval soname=\"$soname_spec\"
+	else
+	  soname="$realname"
+	fi
+
+	lib="$output_objdir/$realname"
+	for link
+	do
+	  linknames="$linknames $link"
+	done
+
+	# Ensure that we have .o objects for linkers which dislike .lo
+	# (e.g. aix) in case we are running --disable-static
+	for obj in $libobjs; do
+	  xdir=`$echo "X$obj" | $Xsed -e 's%/[^/]*$%%'`
+	  if test "X$xdir" = "X$obj"; then
+	    xdir="."
+	  else
+	    xdir="$xdir"
+	  fi
+	  baseobj=`$echo "X$obj" | $Xsed -e 's%^.*/%%'`
+	  oldobj=`$echo "X$baseobj" | $Xsed -e "$lo2o"`
+	  if test ! -f $xdir/$oldobj; then
+	    $show "(cd $xdir && ${LN_S} $baseobj $oldobj)"
+	    $run eval '(cd $xdir && ${LN_S} $baseobj $oldobj)' || exit $?
+	  fi
+	done
+
+	# Use standard objects if they are pic
+	test -z "$pic_flag" && libobjs=`$echo "X$libobjs" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
+
+	# Prepare the list of exported symbols
+	if test -z "$export_symbols"; then
+	  if test "$always_export_symbols" = yes || test -n "$export_symbols_regex"; then
+	    $show "generating symbol list for \`$libname.la'"
+	    export_symbols="$output_objdir/$libname.exp"
+	    $run $rm $export_symbols
+	    eval cmds=\"$export_symbols_cmds\"
+	    IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+	    for cmd in $cmds; do
+	      IFS="$save_ifs"
+	      $show "$cmd"
+	      $run eval "$cmd" || exit $?
+	    done
+	    IFS="$save_ifs"
+	    if test -n "$export_symbols_regex"; then
+	      $show "egrep -e \"$export_symbols_regex\" \"$export_symbols\" > \"${export_symbols}T\""
+	      $run eval 'egrep -e "$export_symbols_regex" "$export_symbols" > "${export_symbols}T"'
+	      $show "$mv \"${export_symbols}T\" \"$export_symbols\""
+	      $run eval '$mv "${export_symbols}T" "$export_symbols"'
+	    fi
+	  fi
+	fi
+
+	if test -n "$export_symbols" && test -n "$include_expsyms"; then
+	  $run eval '$echo "X$include_expsyms" | $SP2NL >> "$export_symbols"'
+	fi
+
+	if test -n "$convenience"; then
+	  if test -n "$whole_archive_flag_spec"; then
+	    eval libobjs=\"\$libobjs $whole_archive_flag_spec\"
+	  else
+	    gentop="$output_objdir/${outputname}x"
+	    $show "${rm}r $gentop"
+	    $run ${rm}r "$gentop"
+	    $show "mkdir $gentop"
+	    $run mkdir "$gentop"
+	    status=$?
+	    if test $status -ne 0 && test ! -d "$gentop"; then
+	      exit $status
+	    fi
+	    generated="$generated $gentop"
+
+	    for xlib in $convenience; do
+	      # Extract the objects.
+	      case "$xlib" in
+	      [\\/]* | [A-Za-z]:[\\/]*) xabs="$xlib" ;;
+	      *) xabs=`pwd`"/$xlib" ;;
+	      esac
+	      xlib=`$echo "X$xlib" | $Xsed -e 's%^.*/%%'`
+	      xdir="$gentop/$xlib"
+
+	      $show "${rm}r $xdir"
+	      $run ${rm}r "$xdir"
+	      $show "mkdir $xdir"
+	      $run mkdir "$xdir"
+	      status=$?
+	      if test $status -ne 0 && test ! -d "$xdir"; then
+		exit $status
+	      fi
+	      $show "(cd $xdir && $AR x $xabs)"
+	      $run eval "(cd \$xdir && $AR x \$xabs)" || exit $?
+
+	      libobjs="$libobjs "`find $xdir -name \*.o -print -o -name \*.lo -print | $NL2SP`
+	    done
+	  fi
+	fi
+
+	if test "$thread_safe" = yes && test -n "$thread_safe_flag_spec"; then
+	  eval flag=\"$thread_safe_flag_spec\"
+	  linkopts="$linkopts $flag"
+	fi
+
+	# Do each of the archive commands.
+	if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then
+	  eval cmds=\"$archive_expsym_cmds\"
+	else
+	  eval cmds=\"$archive_cmds\"
+	fi
+	IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+	for cmd in $cmds; do
+	  IFS="$save_ifs"
+	  $show "$cmd"
+	  $run eval "$cmd" || exit $?
+	done
+	IFS="$save_ifs"
+
+	# Create links to the real library.
+	for linkname in $linknames; do
+	  if test "$realname" != "$linkname"; then
+	    $show "(cd $output_objdir && $rm $linkname && $LN_S $realname $linkname)"
+	    $run eval '(cd $output_objdir && $rm $linkname && $LN_S $realname $linkname)' || exit $?
+	  fi
+	done
+
+	# If -module or -export-dynamic was specified, set the dlname.
+	if test "$module" = yes || test "$export_dynamic" = yes; then
+	  # On all known operating systems, these are identical.
+	  dlname="$soname"
+	fi
+      fi
+      ;;
+
+    *.lo | *.o | *.obj)
+      if test -n "$link_against_libtool_libs"; then
+	$echo "$modename: error: cannot link libtool libraries into objects" 1>&2
+	exit 1
+      fi
+
+      if test -n "$deplibs"; then
+	$echo "$modename: warning: \`-l' and \`-L' are ignored for objects" 1>&2
+      fi
+
+      if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
+	$echo "$modename: warning: \`-dlopen' is ignored for objects" 1>&2
+      fi
+
+      if test -n "$rpath"; then
+	$echo "$modename: warning: \`-rpath' is ignored for objects" 1>&2
+      fi
+
+      if test -n "$xrpath"; then
+	$echo "$modename: warning: \`-R' is ignored for objects" 1>&2
+      fi
+
+      if test -n "$vinfo"; then
+	$echo "$modename: warning: \`-version-info' is ignored for objects" 1>&2
+      fi
+
+      if test -n "$release"; then
+	$echo "$modename: warning: \`-release' is ignored for objects" 1>&2
+      fi
+
+      case "$output" in
+      *.lo)
+	if test -n "$objs"; then
+	  $echo "$modename: cannot build library object \`$output' from non-libtool objects" 1>&2
+	  exit 1
+	fi
+	libobj="$output"
+	obj=`$echo "X$output" | $Xsed -e "$lo2o"`
+	;;
+      *)
+	libobj=
+	obj="$output"
+	;;
+      esac
+
+      # Delete the old objects.
+      $run $rm $obj $libobj
+
+      # Objects from convenience libraries.  This assumes
+      # single-version convenience libraries.  Whenever we create
+      # different ones for PIC/non-PIC, this we'll have to duplicate
+      # the extraction.
+      reload_conv_objs=
+      gentop=
+      # reload_cmds runs $LD directly, so let us get rid of
+      # -Wl from whole_archive_flag_spec
+      wl= 
+
+      if test -n "$convenience"; then
+	if test -n "$whole_archive_flag_spec"; then
+	  eval reload_conv_objs=\"\$reload_objs $whole_archive_flag_spec\"
+	else
+	  gentop="$output_objdir/${obj}x"
+	  $show "${rm}r $gentop"
+	  $run ${rm}r "$gentop"
+	  $show "mkdir $gentop"
+	  $run mkdir "$gentop"
+	  status=$?
+	  if test $status -ne 0 && test ! -d "$gentop"; then
+	    exit $status
+	  fi
+	  generated="$generated $gentop"
+
+	  for xlib in $convenience; do
+	    # Extract the objects.
+	    case "$xlib" in
+	    [\\/]* | [A-Za-z]:[\\/]*) xabs="$xlib" ;;
+	    *) xabs=`pwd`"/$xlib" ;;
+	    esac
+	    xlib=`$echo "X$xlib" | $Xsed -e 's%^.*/%%'`
+	    xdir="$gentop/$xlib"
+
+	    $show "${rm}r $xdir"
+	    $run ${rm}r "$xdir"
+	    $show "mkdir $xdir"
+	    $run mkdir "$xdir"
+	    status=$?
+	    if test $status -ne 0 && test ! -d "$xdir"; then
+	      exit $status
+	    fi
+	    $show "(cd $xdir && $AR x $xabs)"
+	    $run eval "(cd \$xdir && $AR x \$xabs)" || exit $?
+
+	    reload_conv_objs="$reload_objs "`find $xdir -name \*.o -print -o -name \*.lo -print | $NL2SP`
+	  done
+	fi
+      fi
+
+      # Create the old-style object.
+      reload_objs="$objs "`$echo "X$libobjs" | $SP2NL | $Xsed -e '/\.'${libext}$'/d' -e '/\.lib$/d' -e "$lo2o" | $NL2SP`" $reload_conv_objs"
+
+      output="$obj"
+      eval cmds=\"$reload_cmds\"
+      IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+      for cmd in $cmds; do
+	IFS="$save_ifs"
+	$show "$cmd"
+	$run eval "$cmd" || exit $?
+      done
+      IFS="$save_ifs"
+
+      # Exit if we aren't doing a library object file.
+      if test -z "$libobj"; then
+	if test -n "$gentop"; then
+	  $show "${rm}r $gentop"
+	  $run ${rm}r $gentop
+	fi
+
+	exit 0
+      fi
+
+      if test "$build_libtool_libs" != yes; then
+	if test -n "$gentop"; then
+	  $show "${rm}r $gentop"
+	  $run ${rm}r $gentop
+	fi
+
+	# Create an invalid libtool object if no PIC, so that we don't
+	# accidentally link it into a program.
+	$show "echo timestamp > $libobj"
+	$run eval "echo timestamp > $libobj" || exit $?
+	exit 0
+      fi
+
+      if test -n "$pic_flag"; then
+	# Only do commands if we really have different PIC objects.
+	reload_objs="$libobjs $reload_conv_objs"
+	output="$libobj"
+	eval cmds=\"$reload_cmds\"
+	IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+	for cmd in $cmds; do
+	  IFS="$save_ifs"
+	  $show "$cmd"
+	  $run eval "$cmd" || exit $?
+	done
+	IFS="$save_ifs"
+      else
+	# Just create a symlink.
+	$show $rm $libobj
+	$run $rm $libobj
+	xdir=`$echo "X$libobj" | $Xsed -e 's%/[^/]*$%%'`
+	if test "X$xdir" = "X$libobj"; then
+	  xdir="."
+	else
+	  xdir="$xdir"
+	fi
+	baseobj=`$echo "X$libobj" | $Xsed -e 's%^.*/%%'`
+	oldobj=`$echo "X$baseobj" | $Xsed -e "$lo2o"`
+	$show "(cd $xdir && $LN_S $oldobj $baseobj)"
+	$run eval '(cd $xdir && $LN_S $oldobj $baseobj)' || exit $?
+      fi
+
+      if test -n "$gentop"; then
+	$show "${rm}r $gentop"
+	$run ${rm}r $gentop
+      fi
+
+      exit 0
+      ;;
+
+    # Anything else should be a program.
+    *)
+      if test -n "$vinfo"; then
+	$echo "$modename: warning: \`-version-info' is ignored for programs" 1>&2
+      fi
+
+      if test -n "$release"; then
+	$echo "$modename: warning: \`-release' is ignored for programs" 1>&2
+      fi
+
+      if test "$preload" = yes; then
+	if test "$dlopen" = unknown && test "$dlopen_self" = unknown &&
+	   test "$dlopen_self_static" = unknown; then
+	  $echo "$modename: warning: \`AC_LIBTOOL_DLOPEN' not used. Assuming no dlopen support."
+	fi 
+      fi
+    
+      if test -n "$rpath$xrpath"; then
+	# If the user specified any rpath flags, then add them.
+	for libdir in $rpath $xrpath; do
+	  # This is the magic to use -rpath.
+	  case "$compile_rpath " in
+	  *" $libdir "*) ;;
+	  *) compile_rpath="$compile_rpath $libdir" ;;
+	  esac
+	  case "$finalize_rpath " in
+	  *" $libdir "*) ;;
+	  *) finalize_rpath="$finalize_rpath $libdir" ;;
+	  esac
+	done
+      fi
+
+      # Now hardcode the library paths
+      rpath=
+      hardcode_libdirs=
+      for libdir in $compile_rpath $finalize_rpath; do
+	if test -n "$hardcode_libdir_flag_spec"; then
+	  if test -n "$hardcode_libdir_separator"; then
+	    if test -z "$hardcode_libdirs"; then
+	      hardcode_libdirs="$libdir"
+	    else
+	      # Just accumulate the unique libdirs.
+	      case "$hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_separator" in
+	      *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*)
+		;;
+	      *)
+		hardcode_libdirs="$hardcode_libdirs$hardcode_libdir_separator$libdir"
+		;;
+	      esac
+	    fi
+	  else
+	    eval flag=\"$hardcode_libdir_flag_spec\"
+	    rpath="$rpath $flag"
+	  fi
+	elif test -n "$runpath_var"; then
+	  case "$perm_rpath " in
+	  *" $libdir "*) ;;
+	  *) perm_rpath="$perm_rpath $libdir" ;;
+	  esac
+	fi
+      done
+      # Substitute the hardcoded libdirs into the rpath.
+      if test -n "$hardcode_libdir_separator" &&
+	 test -n "$hardcode_libdirs"; then
+	libdir="$hardcode_libdirs"
+	eval rpath=\" $hardcode_libdir_flag_spec\"
+      fi
+      compile_rpath="$rpath"
+
+      rpath=
+      hardcode_libdirs=
+      for libdir in $finalize_rpath; do
+	if test -n "$hardcode_libdir_flag_spec"; then
+	  if test -n "$hardcode_libdir_separator"; then
+	    if test -z "$hardcode_libdirs"; then
+	      hardcode_libdirs="$libdir"
+	    else
+	      # Just accumulate the unique libdirs.
+	      case "$hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_separator" in
+	      *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*)
+		;;
+	      *)
+		hardcode_libdirs="$hardcode_libdirs$hardcode_libdir_separator$libdir"
+		;;
+	      esac
+	    fi
+	  else
+	    eval flag=\"$hardcode_libdir_flag_spec\"
+	    rpath="$rpath $flag"
+	  fi
+	elif test -n "$runpath_var"; then
+	  case "$finalize_perm_rpath " in
+	  *" $libdir "*) ;;
+	  *) finalize_perm_rpath="$finalize_perm_rpath $libdir" ;;
+	  esac
+	fi
+      done
+      # Substitute the hardcoded libdirs into the rpath.
+      if test -n "$hardcode_libdir_separator" &&
+	 test -n "$hardcode_libdirs"; then
+	libdir="$hardcode_libdirs"
+	eval rpath=\" $hardcode_libdir_flag_spec\"
+      fi
+      finalize_rpath="$rpath"
+
+      output_objdir=`$echo "X$output" | $Xsed -e 's%/[^/]*$%%'`
+      if test "X$output_objdir" = "X$output"; then
+	output_objdir="$objdir"
+      else
+	output_objdir="$output_objdir/$objdir"
+      fi
+
+      # Create the binary in the object directory, then wrap it.
+      if test ! -d $output_objdir; then
+	$show "$mkdir $output_objdir"
+	$run $mkdir $output_objdir
+	status=$?
+	if test $status -ne 0 && test ! -d $output_objdir; then
+	  exit $status
+	fi
+      fi
+
+      if test -n "$libobjs" && test "$build_old_libs" = yes; then
+	# Transform all the library objects into standard objects.
+	compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
+	finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
+      fi
+
+      dlsyms=
+      if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
+	if test -n "$NM" && test -n "$global_symbol_pipe"; then
+	  dlsyms="${outputname}S.c"
+	else
+	  $echo "$modename: not configured to extract global symbols from dlpreopened files" 1>&2
+	fi
+      fi
+
+      if test -n "$dlsyms"; then
+	case "$dlsyms" in
+	"") ;;
+	*.c)
+	  # Discover the nlist of each of the dlfiles.
+	  nlist="$output_objdir/${outputname}.nm"
+
+	  $show "$rm $nlist ${nlist}S ${nlist}T"
+	  $run $rm "$nlist" "${nlist}S" "${nlist}T"
+
+	  # Parse the name list into a source file.
+	  $show "creating $output_objdir/$dlsyms"
+
+	  test -z "$run" && $echo > "$output_objdir/$dlsyms" "\
+/* $dlsyms - symbol resolution table for \`$outputname' dlsym emulation. */
+/* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */
+
+#ifdef __cplusplus
+extern \"C\" {
+#endif
+
+/* Prevent the only kind of declaration conflicts we can make. */
+#define lt_preloaded_symbols some_other_symbol
+
+/* External symbol declarations for the compiler. */\
+"
+
+	  if test "$dlself" = yes; then
+	    $show "generating symbol list for \`$output'"
+
+	    test -z "$run" && $echo ': @PROGRAM@ ' > "$nlist"
+
+	    # Add our own program objects to the symbol list.
+	    progfiles=`$echo "X$objs" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
+	    for arg in $progfiles; do
+	      $show "extracting global C symbols from \`$arg'"
+	      $run eval "$NM $arg | $global_symbol_pipe >> '$nlist'"
+	    done
+
+	    if test -n "$exclude_expsyms"; then
+	      $run eval 'egrep -v " ($exclude_expsyms)$" "$nlist" > "$nlist"T'
+	      $run eval '$mv "$nlist"T "$nlist"'
+	    fi
+	    
+	    if test -n "$export_symbols_regex"; then
+	      $run eval 'egrep -e "$export_symbols_regex" "$nlist" > "$nlist"T'
+	      $run eval '$mv "$nlist"T "$nlist"'
+	    fi
+
+	    # Prepare the list of exported symbols
+	    if test -z "$export_symbols"; then
+	      export_symbols="$output_objdir/$output.exp"
+	      $run $rm $export_symbols
+	      $run eval "sed -n -e '/^: @PROGRAM@$/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
+	    else
+	      $run eval "sed -e 's/\([][.*^$]\)/\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$output.exp"'
+	      $run eval 'grep -f "$output_objdir/$output.exp" < "$nlist" > "$nlist"T'
+	      $run eval 'mv "$nlist"T "$nlist"'
+	    fi
+	  fi
+
+	  for arg in $dlprefiles; do
+	    $show "extracting global C symbols from \`$arg'"
+	    name=`echo "$arg" | sed -e 's%^.*/%%'`
+	    $run eval 'echo ": $name " >> "$nlist"'
+	    $run eval "$NM $arg | $global_symbol_pipe >> '$nlist'"
+	  done
+
+	  if test -z "$run"; then
+	    # Make sure we have at least an empty file.
+	    test -f "$nlist" || : > "$nlist"
+
+	    if test -n "$exclude_expsyms"; then
+	      egrep -v " ($exclude_expsyms)$" "$nlist" > "$nlist"T
+	      $mv "$nlist"T "$nlist"
+	    fi
+
+	    # Try sorting and uniquifying the output.
+	    if grep -v "^: " < "$nlist" | sort +2 | uniq > "$nlist"S; then
+	      :
+	    else
+	      grep -v "^: " < "$nlist" > "$nlist"S
+	    fi
+
+	    if test -f "$nlist"S; then
+	      eval "$global_symbol_to_cdecl"' < "$nlist"S >> "$output_objdir/$dlsyms"'
+	    else
+	      echo '/* NONE */' >> "$output_objdir/$dlsyms"
+	    fi
+
+	    $echo >> "$output_objdir/$dlsyms" "\
+
+#undef lt_preloaded_symbols
+
+#if defined (__STDC__) && __STDC__
+# define lt_ptr_t void *
+#else
+# define lt_ptr_t char *
+# define const
+#endif
+
+/* The mapping between symbol names and symbols. */
+const struct {
+  const char *name;
+  lt_ptr_t address;
+}
+lt_preloaded_symbols[] =
+{\
+"
+
+	    sed -n -e 's/^: \([^ ]*\) $/  {\"\1\", (lt_ptr_t) 0},/p' \
+		-e 's/^. \([^ ]*\) \([^ ]*\)$/  {"\2", (lt_ptr_t) \&\2},/p' \
+		  < "$nlist" >> "$output_objdir/$dlsyms"
+
+	    $echo >> "$output_objdir/$dlsyms" "\
+  {0, (lt_ptr_t) 0}
+};
+
+/* This works around a problem in FreeBSD linker */
+#ifdef FREEBSD_WORKAROUND
+static const void *lt_preloaded_setup() {
+  return lt_preloaded_symbols;
+}
+#endif
+
+#ifdef __cplusplus
+}
+#endif\
+"
+	  fi
+
+	  pic_flag_for_symtable=
+	  case "$host" in
+	  # compiling the symbol table file with pic_flag works around
+	  # a FreeBSD bug that causes programs to crash when -lm is
+	  # linked before any other PIC object.  But we must not use
+	  # pic_flag when linking with -static.  The problem exists in
+	  # FreeBSD 2.2.6 and is fixed in FreeBSD 3.1.
+	  *-*-freebsd2*|*-*-freebsd3.0*|*-*-freebsdelf3.0*)
+	    case "$compile_command " in
+	    *" -static "*) ;;
+	    *) pic_flag_for_symtable=" $pic_flag -DPIC -DFREEBSD_WORKAROUND";;
+	    esac;;
+	  *-*-hpux*)
+	    case "$compile_command " in
+	    *" -static "*) ;;
+	    *) pic_flag_for_symtable=" $pic_flag -DPIC";;
+	    esac
+	  esac
+
+	  # Now compile the dynamic symbol file.
+	  $show "(cd $output_objdir && $CC -c$no_builtin_flag$pic_flag_for_symtable \"$dlsyms\")"
+	  $run eval '(cd $output_objdir && $CC -c$no_builtin_flag$pic_flag_for_symtable "$dlsyms")' || exit $?
+
+	  # Clean up the generated files.
+	  $show "$rm $output_objdir/$dlsyms $nlist ${nlist}S ${nlist}T"
+	  $run $rm "$output_objdir/$dlsyms" "$nlist" "${nlist}S" "${nlist}T"
+
+	  # Transform the symbol file into the correct name.
+	  compile_command=`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+	  finalize_command=`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+	  ;;
+	*)
+	  $echo "$modename: unknown suffix for \`$dlsyms'" 1>&2
+	  exit 1
+	  ;;
+	esac
+      else
+	# We keep going just in case the user didn't refer to
+	# lt_preloaded_symbols.  The linker will fail if global_symbol_pipe
+	# really was required.
+
+	# Nullify the symbol file.
+	compile_command=`$echo "X$compile_command" | $Xsed -e "s% @SYMFILE@%%"`
+	finalize_command=`$echo "X$finalize_command" | $Xsed -e "s% @SYMFILE@%%"`
+      fi
+
+      if test -z "$link_against_libtool_libs" || test "$build_libtool_libs" != yes; then
+	# Replace the output file specification.
+	compile_command=`$echo "X$compile_command" | $Xsed -e 's%@OUTPUT@%'"$output"'%g'`
+	link_command="$compile_command$compile_rpath"
+
+	# We have no uninstalled library dependencies, so finalize right now.
+	$show "$link_command"
+	$run eval "$link_command"
+	status=$?
+	
+	# Delete the generated files.
+	if test -n "$dlsyms"; then
+	  $show "$rm $output_objdir/${outputname}S.${objext}"
+	  $run $rm "$output_objdir/${outputname}S.${objext}"
+	fi
+
+	exit $status
+      fi
+
+      if test -n "$shlibpath_var"; then
+	# We should set the shlibpath_var
+	rpath=
+	for dir in $temp_rpath; do
+	  case "$dir" in
+	  [\\/]* | [A-Za-z]:[\\/]*)
+	    # Absolute path.
+	    rpath="$rpath$dir:"
+	    ;;
+	  *)
+	    # Relative path: add a thisdir entry.
+	    rpath="$rpath\$thisdir/$dir:"
+	    ;;
+	  esac
+	done
+	temp_rpath="$rpath"
+      fi
+
+      if test -n "$compile_shlibpath$finalize_shlibpath"; then
+	compile_command="$shlibpath_var=\"$compile_shlibpath$finalize_shlibpath\$$shlibpath_var\" $compile_command"
+      fi
+      if test -n "$finalize_shlibpath"; then
+	finalize_command="$shlibpath_var=\"$finalize_shlibpath\$$shlibpath_var\" $finalize_command"
+      fi
+
+      compile_var=
+      finalize_var=
+      if test -n "$runpath_var"; then
+	if test -n "$perm_rpath"; then
+	  # We should set the runpath_var.
+	  rpath=
+	  for dir in $perm_rpath; do
+	    rpath="$rpath$dir:"
+	  done
+	  compile_var="$runpath_var=\"$rpath\$$runpath_var\" "
+	fi
+	if test -n "$finalize_perm_rpath"; then
+	  # We should set the runpath_var.
+	  rpath=
+	  for dir in $finalize_perm_rpath; do
+	    rpath="$rpath$dir:"
+	  done
+	  finalize_var="$runpath_var=\"$rpath\$$runpath_var\" "
+	fi
+      fi
+
+      if test "$hardcode_action" = relink; then
+	# Fast installation is not supported
+	link_command="$compile_var$compile_command$compile_rpath"
+	relink_command="$finalize_var$finalize_command$finalize_rpath"
+	
+	$echo "$modename: warning: this platform does not like uninstalled shared libraries" 1>&2
+	$echo "$modename: \`$output' will be relinked during installation" 1>&2
+      else
+	if test "$fast_install" != no; then
+	  link_command="$finalize_var$compile_command$finalize_rpath"
+	  if test "$fast_install" = yes; then
+	    relink_command=`$echo "X$compile_var$compile_command$compile_rpath" | $Xsed -e 's%@OUTPUT@%\$progdir/\$file%g'`
+	  else
+	    # fast_install is set to needless
+	    relink_command=
+	  fi
+	else
+	  link_command="$compile_var$compile_command$compile_rpath"
+	  relink_command="$finalize_var$finalize_command$finalize_rpath"
+	fi
+      fi
+
+      # Replace the output file specification.
+      link_command=`$echo "X$link_command" | $Xsed -e 's%@OUTPUT@%'"$output_objdir/$outputname"'%g'`
+      
+      # Delete the old output files.
+      $run $rm $output $output_objdir/$outputname $output_objdir/lt-$outputname
+
+      $show "$link_command"
+      $run eval "$link_command" || exit $?
+
+      # Now create the wrapper script.
+      $show "creating $output"
+
+      # Quote the relink command for shipping.
+      if test -n "$relink_command"; then
+	relink_command=`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"`
+      fi
+
+      # Quote $echo for shipping.
+      if test "X$echo" = "X$SHELL $0 --fallback-echo"; then
+	case "$0" in
+	[\\/]* | [A-Za-z]:[\\/]*) qecho="$SHELL $0 --fallback-echo";;
+	*) qecho="$SHELL `pwd`/$0 --fallback-echo";;
+	esac
+	qecho=`$echo "X$qecho" | $Xsed -e "$sed_quote_subst"`
+      else
+	qecho=`$echo "X$echo" | $Xsed -e "$sed_quote_subst"`
+      fi
+
+      # Only actually do things if our run command is non-null.
+      if test -z "$run"; then
+	# win32 will think the script is a binary if it has
+	# a .exe suffix, so we strip it off here.
+	case $output in
+	  *.exe) output=`echo $output|sed 's,.exe$,,'` ;;
+	esac
+	$rm $output
+	trap "$rm $output; exit 1" 1 2 15
+
+	$echo > $output "\
+#! $SHELL
+
+# $output - temporary wrapper script for $objdir/$outputname
+# Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+#
+# The $output program cannot be directly executed until all the libtool
+# libraries that it depends on are installed.
+#
+# This wrapper script should never be moved out of the build directory.
+# If it is, it will not operate correctly.
+
+# Sed substitution that helps us do robust quoting.  It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='sed -e 1s/^X//'
+sed_quote_subst='$sed_quote_subst'
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+if test \"\${CDPATH+set}\" = set; then CDPATH=:; export CDPATH; fi
+
+relink_command=\"$relink_command\"
+
+# This environment variable determines our operation mode.
+if test \"\$libtool_install_magic\" = \"$magic\"; then
+  # install mode needs the following variable:
+  link_against_libtool_libs='$link_against_libtool_libs'
+else
+  # When we are sourced in execute mode, \$file and \$echo are already set.
+  if test \"\$libtool_execute_magic\" != \"$magic\"; then
+    echo=\"$qecho\"
+    file=\"\$0\"
+    # Make sure echo works.
+    if test \"X\$1\" = X--no-reexec; then
+      # Discard the --no-reexec flag, and continue.
+      shift
+    elif test \"X\`(\$echo '\t') 2>/dev/null\`\" = 'X\t'; then
+      # Yippee, \$echo works!
+      :
+    else
+      # Restart under the correct shell, and then maybe \$echo will work.
+      exec $SHELL \"\$0\" --no-reexec \${1+\"\$@\"}
+    fi
+  fi\
+"
+	$echo >> $output "\
+
+  # Find the directory that this script lives in.
+  thisdir=\`\$echo \"X\$file\" | \$Xsed -e 's%/[^/]*$%%'\`
+  test \"x\$thisdir\" = \"x\$file\" && thisdir=.
+
+  # Follow symbolic links until we get to the real thisdir.
+  file=\`ls -ld \"\$file\" | sed -n 's/.*-> //p'\`
+  while test -n \"\$file\"; do
+    destdir=\`\$echo \"X\$file\" | \$Xsed -e 's%/[^/]*\$%%'\`
+
+    # If there was a directory component, then change thisdir.
+    if test \"x\$destdir\" != \"x\$file\"; then
+      case \"\$destdir\" in
+      [\\/]* | [A-Za-z]:[\\/]*) thisdir=\"\$destdir\" ;;
+      *) thisdir=\"\$thisdir/\$destdir\" ;;
+      esac
+    fi
+
+    file=\`\$echo \"X\$file\" | \$Xsed -e 's%^.*/%%'\`
+    file=\`ls -ld \"\$thisdir/\$file\" | sed -n 's/.*-> //p'\`
+  done
+
+  # Try to get the absolute directory name.
+  absdir=\`cd \"\$thisdir\" && pwd\`
+  test -n \"\$absdir\" && thisdir=\"\$absdir\"
+"
+
+	if test "$fast_install" = yes; then
+	  echo >> $output "\
+  program=lt-'$outputname'
+  progdir=\"\$thisdir/$objdir\"
+  
+  if test ! -f \"\$progdir/\$program\" || \\
+     { file=\`ls -1dt \"\$progdir/\$program\" \"\$progdir/../\$program\" 2>/dev/null | sed 1q\`; \\
+       test \"X\$file\" != \"X\$progdir/\$program\"; }; then
+
+    file=\"\$\$-\$program\"
+
+    if test ! -d \"\$progdir\"; then
+      $mkdir \"\$progdir\"
+    else
+      $rm \"\$progdir/\$file\"
+    fi"
+
+	  echo >> $output "\
+
+    # relink executable if necessary
+    if test -n \"\$relink_command\"; then
+      if (cd \"\$thisdir\" && eval \$relink_command); then :
+      else
+	$rm \"\$progdir/\$file\"
+	exit 1
+      fi
+    fi
+
+    $mv \"\$progdir/\$file\" \"\$progdir/\$program\" 2>/dev/null ||
+    { $rm \"\$progdir/\$program\";
+      $mv \"\$progdir/\$file\" \"\$progdir/\$program\"; }
+    $rm \"\$progdir/\$file\"
+  fi"
+	else
+	  echo >> $output "\
+  program='$outputname'
+  progdir=\"\$thisdir/$objdir\"
+"
+	fi
+
+	echo >> $output "\
+
+  if test -f \"\$progdir/\$program\"; then"
+
+	# Export our shlibpath_var if we have one.
+	if test "$shlibpath_overrides_runpath" = yes && test -n "$shlibpath_var" && test -n "$temp_rpath"; then
+	  $echo >> $output "\
+    # Add our own library path to $shlibpath_var
+    $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"
+
+    # Some systems cannot cope with colon-terminated $shlibpath_var
+    # The second colon is a workaround for a bug in BeOS R4 sed
+    $shlibpath_var=\`\$echo \"X\$$shlibpath_var\" | \$Xsed -e 's/::*\$//'\`
+
+    export $shlibpath_var
+"
+	fi
+
+	# fixup the dll searchpath if we need to.
+	if test -n "$dllsearchpath"; then
+	  $echo >> $output "\
+    # Add the dll search path components to the executable PATH
+    PATH=$dllsearchpath:\$PATH
+"
+	fi
+
+	$echo >> $output "\
+    if test \"\$libtool_execute_magic\" != \"$magic\"; then
+      # Run the actual program with our arguments.
+"
+	case $host in
+	  # win32 systems need to use the prog path for dll
+	  # lookup to work
+	*-*-cygwin*)
+	  $echo >> $output "\
+      exec \$progdir/\$program \${1+\"\$@\"}
+"
+	  ;;
+
+	# Backslashes separate directories on plain windows
+	*-*-mingw | *-*-os2*)
+	  $echo >> $output "\
+      exec \$progdir\\\\\$program \${1+\"\$@\"}
+"
+	  ;;
+
+	*)
+	  $echo >> $output "\
+      # Export the path to the program.
+      PATH=\"\$progdir:\$PATH\"
+      export PATH
+
+      exec \$program \${1+\"\$@\"}
+"
+	  ;;
+	esac
+	$echo >> $output "\
+      \$echo \"\$0: cannot exec \$program \${1+\"\$@\"}\"
+      exit 1
+    fi
+  else
+    # The program doesn't exist.
+    \$echo \"\$0: error: \$progdir/\$program does not exist\" 1>&2
+    \$echo \"This script is just a wrapper for \$program.\" 1>&2
+    echo \"See the $PACKAGE documentation for more information.\" 1>&2
+    exit 1
+  fi
+fi\
+"
+	chmod +x $output
+      fi
+      exit 0
+      ;;
+    esac
+
+    # See if we need to build an old-fashioned archive.
+    for oldlib in $oldlibs; do
+
+      if test "$build_libtool_libs" = convenience; then
+	oldobjs="$libobjs_save"
+	addlibs="$convenience"
+	build_libtool_libs=no
+      else
+	if test "$build_libtool_libs" = module; then
+	  oldobjs="$libobjs_save"
+	  build_libtool_libs=no
+	else
+	  oldobjs="$objs "`$echo "X$libobjs_save" | $SP2NL | $Xsed -e '/\.'${libext}'$/d' -e '/\.lib$/d' -e "$lo2o" | $NL2SP`
+	fi
+	addlibs="$old_convenience"
+      fi
+
+      if test -n "$addlibs"; then
+	gentop="$output_objdir/${outputname}x"
+	$show "${rm}r $gentop"
+	$run ${rm}r "$gentop"
+	$show "mkdir $gentop"
+	$run mkdir "$gentop"
+	status=$?
+	if test $status -ne 0 && test ! -d "$gentop"; then
+	  exit $status
+	fi
+	generated="$generated $gentop"
+	  
+	# Add in members from convenience archives.
+	for xlib in $addlibs; do
+	  # Extract the objects.
+	  case "$xlib" in
+	  [\\/]* | [A-Za-z]:[\\/]*) xabs="$xlib" ;;
+	  *) xabs=`pwd`"/$xlib" ;;
+	  esac
+	  xlib=`$echo "X$xlib" | $Xsed -e 's%^.*/%%'`
+	  xdir="$gentop/$xlib"
+
+	  $show "${rm}r $xdir"
+	  $run ${rm}r "$xdir"
+	  $show "mkdir $xdir"
+	  $run mkdir "$xdir"
+	  status=$?
+	  if test $status -ne 0 && test ! -d "$xdir"; then
+	    exit $status
+	  fi
+	  $show "(cd $xdir && $AR x $xabs)"
+	  $run eval "(cd \$xdir && $AR x \$xabs)" || exit $?
+
+	  oldobjs="$oldobjs "`find $xdir -name \*.${objext} -print -o -name \*.lo -print | $NL2SP`
+	done
+      fi
+
+      # Do each command in the archive commands.
+      if test -n "$old_archive_from_new_cmds" && test "$build_libtool_libs" = yes; then
+	eval cmds=\"$old_archive_from_new_cmds\"
+      else
+	# Ensure that we have .o objects in place in case we decided
+	# not to build a shared library, and have fallen back to building
+	# static libs even though --disable-static was passed!
+	for oldobj in $oldobjs; do
+	  if test ! -f $oldobj; then
+	    xdir=`$echo "X$oldobj" | $Xsed -e 's%/[^/]*$%%'`
+	    if test "X$xdir" = "X$oldobj"; then
+	      xdir="."
+	    else
+	      xdir="$xdir"
+	    fi
+	    baseobj=`$echo "X$oldobj" | $Xsed -e 's%^.*/%%'`
+	    obj=`$echo "X$baseobj" | $Xsed -e "$o2lo"`
+	    $show "(cd $xdir && ${LN_S} $obj $baseobj)"
+	    $run eval '(cd $xdir && ${LN_S} $obj $baseobj)' || exit $?
+	  fi
+	done
+
+	eval cmds=\"$old_archive_cmds\"
+      fi
+      IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+      for cmd in $cmds; do
+	IFS="$save_ifs"
+	$show "$cmd"
+	$run eval "$cmd" || exit $?
+      done
+      IFS="$save_ifs"
+    done
+
+    if test -n "$generated"; then
+      $show "${rm}r$generated"
+      $run ${rm}r$generated
+    fi
+
+    # Now create the libtool archive.
+    case "$output" in
+    *.la)
+      old_library=
+      test "$build_old_libs" = yes && old_library="$libname.$libext"
+      $show "creating $output"
+
+      if test -n "$xrpath"; then
+	temp_xrpath=
+	for libdir in $xrpath; do
+	  temp_xrpath="$temp_xrpath -R$libdir"
+	done
+	dependency_libs="$temp_xrpath $dependency_libs"
+      fi
+
+      # Only create the output if not a dry run.
+      if test -z "$run"; then
+	for installed in no yes; do
+	  if test "$installed" = yes; then
+	    if test -z "$install_libdir"; then
+	      break
+	    fi
+	    output="$output_objdir/$outputname"i
+	  fi
+	  $rm $output
+	  $echo > $output "\
+# $outputname - a libtool library file
+# Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+#
+# Please DO NOT delete this file!
+# It is necessary for linking the library.
+
+# The name that we can dlopen(3).
+dlname='$dlname'
+
+# Names of this library.
+library_names='$library_names'
+
+# The name of the static archive.
+old_library='$old_library'
+
+# Libraries that this one depends upon.
+dependency_libs='$dependency_libs'
+
+# Version information for $libname.
+current=$current
+age=$age
+revision=$revision
+
+# Is this an already installed library?
+installed=$installed
+
+# Directory that this library needs to be installed in:
+libdir='$install_libdir'\
+"
+	done
+      fi
+
+      # Do a symbolic link so that the libtool archive can be found in
+      # LD_LIBRARY_PATH before the program is installed.
+      $show "(cd $output_objdir && $rm $outputname && $LN_S ../$outputname $outputname)"
+      $run eval "(cd $output_objdir && $rm $outputname && $LN_S ../$outputname $outputname)" || exit $?
+      ;;
+    esac
+    exit 0
+    ;;
+
+  # libtool install mode
+  install)
+    modename="$modename: install"
+
+    # There may be an optional sh(1) argument at the beginning of
+    # install_prog (especially on Windows NT).
+    if test "$nonopt" = "$SHELL" || test "$nonopt" = /bin/sh; then
+      # Aesthetically quote it.
+      arg=`$echo "X$nonopt" | $Xsed -e "$sed_quote_subst"`
+      case "$arg" in
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+	arg="\"$arg\""
+	;;
+      esac
+      install_prog="$arg "
+      arg="$1"
+      shift
+    else
+      install_prog=
+      arg="$nonopt"
+    fi
+
+    # The real first argument should be the name of the installation program.
+    # Aesthetically quote it.
+    arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
+    case "$arg" in
+    *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+      arg="\"$arg\""
+      ;;
+    esac
+    install_prog="$install_prog$arg"
+
+    # We need to accept at least all the BSD install flags.
+    dest=
+    files=
+    opts=
+    prev=
+    install_type=
+    isdir=no
+    stripme=
+    for arg
+    do
+      if test -n "$dest"; then
+	files="$files $dest"
+	dest="$arg"
+	continue
+      fi
+
+      case "$arg" in
+      -d) isdir=yes ;;
+      -f) prev="-f" ;;
+      -g) prev="-g" ;;
+      -m) prev="-m" ;;
+      -o) prev="-o" ;;
+      -s)
+	stripme=" -s"
+	continue
+	;;
+      -*) ;;
+
+      *)
+	# If the previous option needed an argument, then skip it.
+	if test -n "$prev"; then
+	  prev=
+	else
+	  dest="$arg"
+	  continue
+	fi
+	;;
+      esac
+
+      # Aesthetically quote the argument.
+      arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
+      case "$arg" in
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+	arg="\"$arg\""
+	;;
+      esac
+      install_prog="$install_prog $arg"
+    done
+
+    if test -z "$install_prog"; then
+      $echo "$modename: you must specify an install program" 1>&2
+      $echo "$help" 1>&2
+      exit 1
+    fi
+
+    if test -n "$prev"; then
+      $echo "$modename: the \`$prev' option requires an argument" 1>&2
+      $echo "$help" 1>&2
+      exit 1
+    fi
+
+    if test -z "$files"; then
+      if test -z "$dest"; then
+	$echo "$modename: no file or destination specified" 1>&2
+      else
+	$echo "$modename: you must specify a destination" 1>&2
+      fi
+      $echo "$help" 1>&2
+      exit 1
+    fi
+
+    # Strip any trailing slash from the destination.
+    dest=`$echo "X$dest" | $Xsed -e 's%/$%%'`
+
+    # Check to see that the destination is a directory.
+    test -d "$dest" && isdir=yes
+    if test "$isdir" = yes; then
+      destdir="$dest"
+      destname=
+    else
+      destdir=`$echo "X$dest" | $Xsed -e 's%/[^/]*$%%'`
+      test "X$destdir" = "X$dest" && destdir=.
+      destname=`$echo "X$dest" | $Xsed -e 's%^.*/%%'`
+
+      # Not a directory, so check to see that there is only one file specified.
+      set dummy $files
+      if test $# -gt 2; then
+	$echo "$modename: \`$dest' is not a directory" 1>&2
+	$echo "$help" 1>&2
+	exit 1
+      fi
+    fi
+    case "$destdir" in
+    [\\/]* | [A-Za-z]:[\\/]*) ;;
+    *)
+      for file in $files; do
+	case "$file" in
+	*.lo) ;;
+	*)
+	  $echo "$modename: \`$destdir' must be an absolute directory name" 1>&2
+	  $echo "$help" 1>&2
+	  exit 1
+	  ;;
+	esac
+      done
+      ;;
+    esac
+
+    # This variable tells wrapper scripts just to set variables rather
+    # than running their programs.
+    libtool_install_magic="$magic"
+
+    staticlibs=
+    future_libdirs=
+    current_libdirs=
+    for file in $files; do
+
+      # Do each installation.
+      case "$file" in
+      *.a | *.lib)
+	# Do the static libraries later.
+	staticlibs="$staticlibs $file"
+	;;
+
+      *.la)
+	# Check to see that this really is a libtool archive.
+	if (sed -e '2q' $file | egrep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then :
+	else
+	  $echo "$modename: \`$file' is not a valid libtool archive" 1>&2
+	  $echo "$help" 1>&2
+	  exit 1
+	fi
+
+	library_names=
+	old_library=
+	# If there is no directory component, then add one.
+	case "$file" in
+	*/* | *\\*) . $file ;;
+	*) . ./$file ;;
+	esac
+
+	# Add the libdir to current_libdirs if it is the destination.
+	if test "X$destdir" = "X$libdir"; then
+	  case "$current_libdirs " in
+	  *" $libdir "*) ;;
+	  *) current_libdirs="$current_libdirs $libdir" ;;
+	  esac
+	else
+	  # Note the libdir as a future libdir.
+	  case "$future_libdirs " in
+	  *" $libdir "*) ;;
+	  *) future_libdirs="$future_libdirs $libdir" ;;
+	  esac
+	fi
+
+	dir="`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'`/"
+	test "X$dir" = "X$file/" && dir=
+	dir="$dir$objdir"
+
+	# See the names of the shared library.
+	set dummy $library_names
+	if test -n "$2"; then
+	  realname="$2"
+	  shift
+	  shift
+
+	  # Install the shared library and build the symlinks.
+	  $show "$install_prog $dir/$realname $destdir/$realname"
+	  $run eval "$install_prog $dir/$realname $destdir/$realname" || exit $?
+
+	  if test $# -gt 0; then
+	    # Delete the old symlinks, and create new ones.
+	    for linkname
+	    do
+	      if test "$linkname" != "$realname"; then
+		$show "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
+		$run eval "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
+	      fi
+	    done
+	  fi
+
+	  # Do each command in the postinstall commands.
+	  lib="$destdir/$realname"
+	  eval cmds=\"$postinstall_cmds\"
+	  IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+	  for cmd in $cmds; do
+	    IFS="$save_ifs"
+	    $show "$cmd"
+	    $run eval "$cmd" || exit $?
+	  done
+	  IFS="$save_ifs"
+	fi
+
+	# Install the pseudo-library for information purposes.
+	name=`$echo "X$file" | $Xsed -e 's%^.*/%%'`
+	instname="$dir/$name"i
+	$show "$install_prog $instname $destdir/$name"
+	$run eval "$install_prog $instname $destdir/$name" || exit $?
+
+	# Maybe install the static library, too.
+	test -n "$old_library" && staticlibs="$staticlibs $dir/$old_library"
+	;;
+
+      *.lo)
+	# Install (i.e. copy) a libtool object.
+
+	# Figure out destination file name, if it wasn't already specified.
+	if test -n "$destname"; then
+	  destfile="$destdir/$destname"
+	else
+	  destfile=`$echo "X$file" | $Xsed -e 's%^.*/%%'`
+	  destfile="$destdir/$destfile"
+	fi
+
+	# Deduce the name of the destination old-style object file.
+	case "$destfile" in
+	*.lo)
+	  staticdest=`$echo "X$destfile" | $Xsed -e "$lo2o"`
+	  ;;
+	*.o | *.obj)
+	  staticdest="$destfile"
+	  destfile=
+	  ;;
+	*)
+	  $echo "$modename: cannot copy a libtool object to \`$destfile'" 1>&2
+	  $echo "$help" 1>&2
+	  exit 1
+	  ;;
+	esac
+
+	# Install the libtool object if requested.
+	if test -n "$destfile"; then
+	  $show "$install_prog $file $destfile"
+	  $run eval "$install_prog $file $destfile" || exit $?
+	fi
+
+	# Install the old object if enabled.
+	if test "$build_old_libs" = yes; then
+	  # Deduce the name of the old-style object file.
+	  staticobj=`$echo "X$file" | $Xsed -e "$lo2o"`
+
+	  $show "$install_prog $staticobj $staticdest"
+	  $run eval "$install_prog \$staticobj \$staticdest" || exit $?
+	fi
+	exit 0
+	;;
+
+      *)
+	# Figure out destination file name, if it wasn't already specified.
+	if test -n "$destname"; then
+	  destfile="$destdir/$destname"
+	else
+	  destfile=`$echo "X$file" | $Xsed -e 's%^.*/%%'`
+	  destfile="$destdir/$destfile"
+	fi
+
+	# Do a test to see if this is really a libtool program.
+	if (sed -e '4q' $file | egrep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
+	  link_against_libtool_libs=
+	  relink_command=
+
+	  # If there is no directory component, then add one.
+	  case "$file" in
+	  */* | *\\*) . $file ;;
+	  *) . ./$file ;;
+	  esac
+
+	  # Check the variables that should have been set.
+	  if test -z "$link_against_libtool_libs"; then
+	    $echo "$modename: invalid libtool wrapper script \`$file'" 1>&2
+	    exit 1
+	  fi
+
+	  finalize=yes
+	  for lib in $link_against_libtool_libs; do
+	    # Check to see that each library is installed.
+	    libdir=
+	    if test -f "$lib"; then
+	      # If there is no directory component, then add one.
+	      case "$lib" in
+	      */* | *\\*) . $lib ;;
+	      *) . ./$lib ;;
+	      esac
+	    fi
+	    libfile="$libdir/`$echo "X$lib" | $Xsed -e 's%^.*/%%g'`"
+	    if test -n "$libdir" && test ! -f "$libfile"; then
+	      $echo "$modename: warning: \`$lib' has not been installed in \`$libdir'" 1>&2
+	      finalize=no
+	    fi
+	  done
+
+	  outputname=
+	  if test "$fast_install" = no && test -n "$relink_command"; then
+	    if test "$finalize" = yes && test -z "$run"; then
+	      tmpdir="/tmp"
+	      test -n "$TMPDIR" && tmpdir="$TMPDIR"
+	      tmpdir="$tmpdir/libtool-$$"
+	      if $mkdir -p "$tmpdir" && chmod 700 "$tmpdir"; then :
+	      else
+		$echo "$modename: error: cannot create temporary directory \`$tmpdir'" 1>&2
+		continue
+	      fi
+	      outputname="$tmpdir/$file"
+	      # Replace the output file specification.
+	      relink_command=`$echo "X$relink_command" | $Xsed -e 's%@OUTPUT@%'"$outputname"'%g'`
+
+	      $show "$relink_command"
+	      if $run eval "$relink_command"; then :
+	      else
+		$echo "$modename: error: relink \`$file' with the above command before installing it" 1>&2
+		${rm}r "$tmpdir"
+		continue
+	      fi
+	      file="$outputname"
+	    else
+	      $echo "$modename: warning: cannot relink \`$file'" 1>&2
+	    fi
+	  else
+	    # Install the binary that we compiled earlier.
+	    file=`$echo "X$file" | $Xsed -e "s%\([^/]*\)$%$objdir/\1%"`
+	  fi
+	fi
+
+	$show "$install_prog$stripme $file $destfile"
+	$run eval "$install_prog\$stripme \$file \$destfile" || exit $?
+	test -n "$outputname" && ${rm}r "$tmpdir"
+	;;
+      esac
+    done
+
+    for file in $staticlibs; do
+      name=`$echo "X$file" | $Xsed -e 's%^.*/%%'`
+
+      # Set up the ranlib parameters.
+      oldlib="$destdir/$name"
+
+      $show "$install_prog $file $oldlib"
+      $run eval "$install_prog \$file \$oldlib" || exit $?
+
+      # Do each command in the postinstall commands.
+      eval cmds=\"$old_postinstall_cmds\"
+      IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+      for cmd in $cmds; do
+	IFS="$save_ifs"
+	$show "$cmd"
+	$run eval "$cmd" || exit $?
+      done
+      IFS="$save_ifs"
+    done
+
+    if test -n "$future_libdirs"; then
+      $echo "$modename: warning: remember to run \`$progname --finish$future_libdirs'" 1>&2
+    fi
+
+    if test -n "$current_libdirs"; then
+      # Maybe just do a dry run.
+      test -n "$run" && current_libdirs=" -n$current_libdirs"
+      exec $SHELL $0 --finish$current_libdirs
+      exit 1
+    fi
+
+    exit 0
+    ;;
+
+  # libtool finish mode
+  finish)
+    modename="$modename: finish"
+    libdirs="$nonopt"
+    admincmds=
+
+    if test -n "$finish_cmds$finish_eval" && test -n "$libdirs"; then
+      for dir
+      do
+	libdirs="$libdirs $dir"
+      done
+
+      for libdir in $libdirs; do
+	if test -n "$finish_cmds"; then
+	  # Do each command in the finish commands.
+	  eval cmds=\"$finish_cmds\"
+	  IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+	  for cmd in $cmds; do
+	    IFS="$save_ifs"
+	    $show "$cmd"
+	    $run eval "$cmd" || admincmds="$admincmds
+       $cmd"
+	  done
+	  IFS="$save_ifs"
+	fi
+	if test -n "$finish_eval"; then
+	  # Do the single finish_eval.
+	  eval cmds=\"$finish_eval\"
+	  $run eval "$cmds" || admincmds="$admincmds
+       $cmds"
+	fi
+      done
+    fi
+
+    # Exit here if they wanted silent mode.
+    test "$show" = : && exit 0
+
+    echo "----------------------------------------------------------------------"
+    echo "Libraries have been installed in:"
+    for libdir in $libdirs; do
+      echo "   $libdir"
+    done
+    echo
+    echo "If you ever happen to want to link against installed libraries"
+    echo "in a given directory, LIBDIR, you must either use libtool, and"
+    echo "specify the full pathname of the library, or use \`-LLIBDIR'"
+    echo "flag during linking and do at least one of the following:"
+    if test -n "$shlibpath_var"; then
+      echo "   - add LIBDIR to the \`$shlibpath_var' environment variable"
+      echo "     during execution"
+    fi
+    if test -n "$runpath_var"; then
+      echo "   - add LIBDIR to the \`$runpath_var' environment variable"
+      echo "     during linking"
+    fi
+    if test -n "$hardcode_libdir_flag_spec"; then
+      libdir=LIBDIR
+      eval flag=\"$hardcode_libdir_flag_spec\"
+
+      echo "   - use the \`$flag' linker flag"
+    fi
+    if test -n "$admincmds"; then
+      echo "   - have your system administrator run these commands:$admincmds"
+    fi
+    if test -f /etc/ld.so.conf; then
+      echo "   - have your system administrator add LIBDIR to \`/etc/ld.so.conf'"
+    fi
+    echo
+    echo "See any operating system documentation about shared libraries for"
+    echo "more information, such as the ld(1) and ld.so(8) manual pages."
+    echo "----------------------------------------------------------------------"
+    exit 0
+    ;;
+
+  # libtool execute mode
+  execute)
+    modename="$modename: execute"
+
+    # The first argument is the command name.
+    cmd="$nonopt"
+    if test -z "$cmd"; then
+      $echo "$modename: you must specify a COMMAND" 1>&2
+      $echo "$help"
+      exit 1
+    fi
+
+    # Handle -dlopen flags immediately.
+    for file in $execute_dlfiles; do
+      if test ! -f "$file"; then
+	$echo "$modename: \`$file' is not a file" 1>&2
+	$echo "$help" 1>&2
+	exit 1
+      fi
+
+      dir=
+      case "$file" in
+      *.la)
+	# Check to see that this really is a libtool archive.
+	if (sed -e '2q' $file | egrep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then :
+	else
+	  $echo "$modename: \`$lib' is not a valid libtool archive" 1>&2
+	  $echo "$help" 1>&2
+	  exit 1
+	fi
+
+	# Read the libtool library.
+	dlname=
+	library_names=
+
+	# If there is no directory component, then add one.
+	case "$file" in
+	*/* | *\\*) . $file ;;
+	*) . ./$file ;;
+	esac
+
+	# Skip this library if it cannot be dlopened.
+	if test -z "$dlname"; then
+	  # Warn if it was a shared library.
+	  test -n "$library_names" && $echo "$modename: warning: \`$file' was not linked with \`-export-dynamic'"
+	  continue
+	fi
+
+	dir=`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'`
+	test "X$dir" = "X$file" && dir=.
+
+	if test -f "$dir/$objdir/$dlname"; then
+	  dir="$dir/$objdir"
+	else
+	  $echo "$modename: cannot find \`$dlname' in \`$dir' or \`$dir/$objdir'" 1>&2
+	  exit 1
+	fi
+	;;
+
+      *.lo)
+	# Just add the directory containing the .lo file.
+	dir=`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'`
+	test "X$dir" = "X$file" && dir=.
+	;;
+
+      *)
+	$echo "$modename: warning \`-dlopen' is ignored for non-libtool libraries and objects" 1>&2
+	continue
+	;;
+      esac
+
+      # Get the absolute pathname.
+      absdir=`cd "$dir" && pwd`
+      test -n "$absdir" && dir="$absdir"
+
+      # Now add the directory to shlibpath_var.
+      if eval "test -z \"\$$shlibpath_var\""; then
+	eval "$shlibpath_var=\"\$dir\""
+      else
+	eval "$shlibpath_var=\"\$dir:\$$shlibpath_var\""
+      fi
+    done
+
+    # This variable tells wrapper scripts just to set shlibpath_var
+    # rather than running their programs.
+    libtool_execute_magic="$magic"
+
+    # Check if any of the arguments is a wrapper script.
+    args=
+    for file
+    do
+      case "$file" in
+      -*) ;;
+      *)
+	# Do a test to see if this is really a libtool program.
+	if (sed -e '4q' $file | egrep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
+	  # If there is no directory component, then add one.
+	  case "$file" in
+	  */* | *\\*) . $file ;;
+	  *) . ./$file ;;
+	  esac
+
+	  # Transform arg to wrapped name.
+	  file="$progdir/$program"
+	fi
+	;;
+      esac
+      # Quote arguments (to preserve shell metacharacters).
+      file=`$echo "X$file" | $Xsed -e "$sed_quote_subst"`
+      args="$args \"$file\""
+    done
+
+    if test -z "$run"; then
+      if test -n "$shlibpath_var"; then
+        # Export the shlibpath_var.
+        eval "export $shlibpath_var"
+      fi
+
+      # Restore saved enviroment variables
+      if test "${save_LC_ALL+set}" = set; then
+	LC_ALL="$save_LC_ALL"; export LC_ALL
+      fi
+      if test "${save_LANG+set}" = set; then
+	LANG="$save_LANG"; export LANG
+      fi
+
+      # Now actually exec the command.
+      eval "exec \$cmd$args"
+
+      $echo "$modename: cannot exec \$cmd$args"
+      exit 1
+    else
+      # Display what would be done.
+      if test -n "$shlibpath_var"; then
+        eval "\$echo \"\$shlibpath_var=\$$shlibpath_var\""
+        $echo "export $shlibpath_var"
+      fi
+      $echo "$cmd$args"
+      exit 0
+    fi
+    ;;
+
+  # libtool uninstall mode
+  uninstall)
+    modename="$modename: uninstall"
+    rm="$nonopt"
+    files=
+
+    for arg
+    do
+      case "$arg" in
+      -*) rm="$rm $arg" ;;
+      *) files="$files $arg" ;;
+      esac
+    done
+
+    if test -z "$rm"; then
+      $echo "$modename: you must specify an RM program" 1>&2
+      $echo "$help" 1>&2
+      exit 1
+    fi
+
+    for file in $files; do
+      dir=`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'`
+      test "X$dir" = "X$file" && dir=.
+      name=`$echo "X$file" | $Xsed -e 's%^.*/%%'`
+
+      rmfiles="$file"
+
+      case "$name" in
+      *.la)
+	# Possibly a libtool archive, so verify it.
+	if (sed -e '2q' $file | egrep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then
+	  . $dir/$name
+
+	  # Delete the libtool libraries and symlinks.
+	  for n in $library_names; do
+	    rmfiles="$rmfiles $dir/$n"
+	  done
+	  test -n "$old_library" && rmfiles="$rmfiles $dir/$old_library"
+
+	  $show "$rm $rmfiles"
+	  $run $rm $rmfiles
+
+	  if test -n "$library_names"; then
+	    # Do each command in the postuninstall commands.
+	    eval cmds=\"$postuninstall_cmds\"
+	    IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+	    for cmd in $cmds; do
+	      IFS="$save_ifs"
+	      $show "$cmd"
+	      $run eval "$cmd"
+	    done
+	    IFS="$save_ifs"
+	  fi
+
+	  if test -n "$old_library"; then
+	    # Do each command in the old_postuninstall commands.
+	    eval cmds=\"$old_postuninstall_cmds\"
+	    IFS="${IFS= 	}"; save_ifs="$IFS"; IFS='~'
+	    for cmd in $cmds; do
+	      IFS="$save_ifs"
+	      $show "$cmd"
+	      $run eval "$cmd"
+	    done
+	    IFS="$save_ifs"
+	  fi
+
+	  # FIXME: should reinstall the best remaining shared library.
+	fi
+	;;
+
+      *.lo)
+	if test "$build_old_libs" = yes; then
+	  oldobj=`$echo "X$name" | $Xsed -e "$lo2o"`
+	  rmfiles="$rmfiles $dir/$oldobj"
+	fi
+	$show "$rm $rmfiles"
+	$run $rm $rmfiles
+	;;
+
+      *)
+	$show "$rm $rmfiles"
+	$run $rm $rmfiles
+	;;
+      esac
+    done
+    exit 0
+    ;;
+
+  "")
+    $echo "$modename: you must specify a MODE" 1>&2
+    $echo "$generic_help" 1>&2
+    exit 1
+    ;;
+  esac
+
+  $echo "$modename: invalid operation mode \`$mode'" 1>&2
+  $echo "$generic_help" 1>&2
+  exit 1
+fi # test -z "$show_help"
+
+# We need to display help for each of the modes.
+case "$mode" in
+"") $echo \
+"Usage: $modename [OPTION]... [MODE-ARG]...
+
+Provide generalized library-building support services.
+
+    --config          show all configuration variables
+    --debug           enable verbose shell tracing
+-n, --dry-run         display commands without modifying any files
+    --features        display basic configuration information and exit
+    --finish          same as \`--mode=finish'
+    --help            display this help message and exit
+    --mode=MODE       use operation mode MODE [default=inferred from MODE-ARGS]
+    --quiet           same as \`--silent'
+    --silent          don't print informational messages
+    --version         print version information
+
+MODE must be one of the following:
+
+      compile         compile a source file into a libtool object
+      execute         automatically set library path, then run a program
+      finish          complete the installation of libtool libraries
+      install         install libraries or executables
+      link            create a library or an executable
+      uninstall       remove libraries from an installed directory
+
+MODE-ARGS vary depending on the MODE.  Try \`$modename --help --mode=MODE' for
+a more detailed description of MODE."
+  exit 0
+  ;;
+
+compile)
+  $echo \
+"Usage: $modename [OPTION]... --mode=compile COMPILE-COMMAND... SOURCEFILE
+
+Compile a source file into a libtool library object.
+
+This mode accepts the following additional options:
+
+  -o OUTPUT-FILE    set the output file name to OUTPUT-FILE
+  -static           always build a \`.o' file suitable for static linking
+
+COMPILE-COMMAND is a command to be used in creating a \`standard' object file
+from the given SOURCEFILE.
+
+The output file name is determined by removing the directory component from
+SOURCEFILE, then substituting the C source code suffix \`.c' with the
+library object suffix, \`.lo'."
+  ;;
+
+execute)
+  $echo \
+"Usage: $modename [OPTION]... --mode=execute COMMAND [ARGS]...
+
+Automatically set library path, then run a program.
+
+This mode accepts the following additional options:
+
+  -dlopen FILE      add the directory containing FILE to the library path
+
+This mode sets the library path environment variable according to \`-dlopen'
+flags.
+
+If any of the ARGS are libtool executable wrappers, then they are translated
+into their corresponding uninstalled binary, and any of their required library
+directories are added to the library path.
+
+Then, COMMAND is executed, with ARGS as arguments."
+  ;;
+
+finish)
+  $echo \
+"Usage: $modename [OPTION]... --mode=finish [LIBDIR]...
+
+Complete the installation of libtool libraries.
+
+Each LIBDIR is a directory that contains libtool libraries.
+
+The commands that this mode executes may require superuser privileges.  Use
+the \`--dry-run' option if you just want to see what would be executed."
+  ;;
+
+install)
+  $echo \
+"Usage: $modename [OPTION]... --mode=install INSTALL-COMMAND...
+
+Install executables or libraries.
+
+INSTALL-COMMAND is the installation command.  The first component should be
+either the \`install' or \`cp' program.
+
+The rest of the components are interpreted as arguments to that command (only
+BSD-compatible install options are recognized)."
+  ;;
+
+link)
+  $echo \
+"Usage: $modename [OPTION]... --mode=link LINK-COMMAND...
+
+Link object files or libraries together to form another library, or to
+create an executable program.
+
+LINK-COMMAND is a command using the C compiler that you would use to create
+a program from several object files.
+
+The following components of LINK-COMMAND are treated specially:
+
+  -all-static       do not do any dynamic linking at all
+  -avoid-version    do not add a version suffix if possible
+  -dlopen FILE      \`-dlpreopen' FILE if it cannot be dlopened at runtime
+  -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
+  -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
+  -export-symbols SYMFILE
+		    try to export only the symbols listed in SYMFILE
+  -export-symbols-regex REGEX
+		    try to export only the symbols matching REGEX
+  -LLIBDIR          search LIBDIR for required installed libraries
+  -lNAME            OUTPUT-FILE requires the installed library libNAME
+  -module           build a library that can dlopened
+  -no-undefined     declare that a library does not refer to external symbols
+  -o OUTPUT-FILE    create OUTPUT-FILE from the specified objects
+  -release RELEASE  specify package release information
+  -rpath LIBDIR     the created library will eventually be installed in LIBDIR
+  -R[ ]LIBDIR       add LIBDIR to the runtime path of programs and libraries
+  -static           do not do any dynamic linking of libtool libraries
+  -version-info CURRENT[:REVISION[:AGE]]
+		    specify library version info [each variable defaults to 0]
+
+All other options (arguments beginning with \`-') are ignored.
+
+Every other argument is treated as a filename.  Files ending in \`.la' are
+treated as uninstalled libtool libraries, other files are standard or library
+object files.
+
+If the OUTPUT-FILE ends in \`.la', then a libtool library is created,
+only library objects (\`.lo' files) may be specified, and \`-rpath' is
+required, except when creating a convenience library.
+
+If OUTPUT-FILE ends in \`.a' or \`.lib', then a standard library is created
+using \`ar' and \`ranlib', or on Windows using \`lib'.
+
+If OUTPUT-FILE ends in \`.lo' or \`.${objext}', then a reloadable object file
+is created, otherwise an executable program is created."
+  ;;
+
+uninstall)
+  $echo \
+"Usage: $modename [OPTION]... --mode=uninstall RM [RM-OPTION]... FILE...
+
+Remove libraries from an installation directory.
+
+RM is the name of the program to use to delete files associated with each FILE
+(typically \`/bin/rm').  RM-OPTIONS are options (such as \`-f') to be passed
+to RM.
+
+If FILE is a libtool library, all the files associated with it are deleted.
+Otherwise, only FILE itself is deleted using RM."
+  ;;
+
+*)
+  $echo "$modename: invalid operation mode \`$mode'" 1>&2
+  $echo "$help" 1>&2
+  exit 1
+  ;;
+esac
+
+echo
+$echo "Try \`$modename --help' for more information about other modes."
+
+exit 0
+
+# Local Variables:
+# mode:shell-script
+# sh-indentation:2
+# End:
diff --git a/missing b/missing
new file mode 100755
index 0000000..7789652
--- /dev/null
+++ b/missing
@@ -0,0 +1,190 @@
+#! /bin/sh
+# Common stub for a few missing GNU programs while installing.
+# Copyright (C) 1996, 1997 Free Software Foundation, Inc.
+# Franc,ois Pinard <pinard@iro.umontreal.ca>, 1996.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+# 02111-1307, USA.
+
+if test $# -eq 0; then
+  echo 1>&2 "Try \`$0 --help' for more information"
+  exit 1
+fi
+
+case "$1" in
+
+  -h|--h|--he|--hel|--help)
+    echo "\
+$0 [OPTION]... PROGRAM [ARGUMENT]...
+
+Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an
+error status if there is no known handling for PROGRAM.
+
+Options:
+  -h, --help      display this help and exit
+  -v, --version   output version information and exit
+
+Supported PROGRAM values:
+  aclocal      touch file \`aclocal.m4'
+  autoconf     touch file \`configure'
+  autoheader   touch file \`config.h.in'
+  automake     touch all \`Makefile.in' files
+  bison        create \`y.tab.[ch]', if possible, from existing .[ch]
+  flex         create \`lex.yy.c', if possible, from existing .c
+  lex          create \`lex.yy.c', if possible, from existing .c
+  makeinfo     touch the output file
+  yacc         create \`y.tab.[ch]', if possible, from existing .[ch]"
+    ;;
+
+  -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
+    echo "missing - GNU libit 0.0"
+    ;;
+
+  -*)
+    echo 1>&2 "$0: Unknown \`$1' option"
+    echo 1>&2 "Try \`$0 --help' for more information"
+    exit 1
+    ;;
+
+  aclocal)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`acinclude.m4' or \`configure.in'.  You might want
+         to install the \`Automake' and \`Perl' packages.  Grab them from
+         any GNU archive site."
+    touch aclocal.m4
+    ;;
+
+  autoconf)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`configure.in'.  You might want to install the
+         \`Autoconf' and \`GNU m4' packages.  Grab them from any GNU
+         archive site."
+    touch configure
+    ;;
+
+  autoheader)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`acconfig.h' or \`configure.in'.  You might want
+         to install the \`Autoconf' and \`GNU m4' packages.  Grab them
+         from any GNU archive site."
+    files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' configure.in`
+    test -z "$files" && files="config.h"
+    touch_files=
+    for f in $files; do
+      case "$f" in
+      *:*) touch_files="$touch_files "`echo "$f" |
+				       sed -e 's/^[^:]*://' -e 's/:.*//'`;;
+      *) touch_files="$touch_files $f.in";;
+      esac
+    done
+    touch $touch_files
+    ;;
+
+  automake)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`Makefile.am', \`acinclude.m4' or \`configure.in'.
+         You might want to install the \`Automake' and \`Perl' packages.
+         Grab them from any GNU archive site."
+    find . -type f -name Makefile.am -print |
+	   sed 's/\.am$/.in/' |
+	   while read f; do touch "$f"; done
+    ;;
+
+  bison|yacc)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.y' file.  You may need the \`Bison' package
+         in order for those modifications to take effect.  You can get
+         \`Bison' from any GNU archive site."
+    rm -f y.tab.c y.tab.h
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.y)
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.c
+	    fi
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.h
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f y.tab.h ]; then
+	echo >y.tab.h
+    fi
+    if [ ! -f y.tab.c ]; then
+	echo 'main() { return 0; }' >y.tab.c
+    fi
+    ;;
+
+  lex|flex)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.l' file.  You may need the \`Flex' package
+         in order for those modifications to take effect.  You can get
+         \`Flex' from any GNU archive site."
+    rm -f lex.yy.c
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.l)
+	    SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" lex.yy.c
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f lex.yy.c ]; then
+	echo 'main() { return 0; }' >lex.yy.c
+    fi
+    ;;
+
+  makeinfo)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.texi' or \`.texinfo' file, or any other file
+         indirectly affecting the aspect of the manual.  The spurious
+         call might also be the consequence of using a buggy \`make' (AIX,
+         DU, IRIX).  You might want to install the \`Texinfo' package or
+         the \`GNU make' package.  Grab either from any GNU archive site."
+    file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
+    if test -z "$file"; then
+      file=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
+      file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $file`
+    fi
+    touch $file
+    ;;
+
+  *)
+    echo 1>&2 "\
+WARNING: \`$1' is needed, and you do not seem to have it handy on your
+         system.  You might have modified some files without having the
+         proper tools for further handling them.  Check the \`README' file,
+         it often tells you about the needed prerequirements for installing
+         this package.  You may also peek at any GNU archive site, in case
+         some other package would contain this missing \`$1' program."
+    exit 1
+    ;;
+esac
+
+exit 0
diff --git a/mkinstalldirs b/mkinstalldirs
new file mode 100755
index 0000000..6fbb2db
--- /dev/null
+++ b/mkinstalldirs
@@ -0,0 +1,40 @@
+#! /bin/sh
+# mkinstalldirs --- make directory hierarchy
+# Author: Noah Friedman <friedman@prep.ai.mit.edu>
+# Created: 1993-05-16
+# Public domain
+
+# $Id: mkinstalldirs,v 1.1 2001-09-20 23:27:02 Pixel Exp $
+
+errstatus=0
+
+for file
+do
+   set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
+   shift
+
+   pathcomp=
+   for d
+   do
+     pathcomp="$pathcomp$d"
+     case "$pathcomp" in
+       -* ) pathcomp=./$pathcomp ;;
+     esac
+
+     if test ! -d "$pathcomp"; then
+        echo "mkdir $pathcomp"
+
+        mkdir "$pathcomp" || lasterr=$?
+
+        if test ! -d "$pathcomp"; then
+  	  errstatus=$lasterr
+        fi
+     fi
+
+     pathcomp="$pathcomp/"
+   done
+done
+
+exit $errstatus
+
+# mkinstalldirs ends here
diff --git a/po/ChangeLog b/po/ChangeLog
new file mode 100644
index 0000000..09de061
--- /dev/null
+++ b/po/ChangeLog
@@ -0,0 +1 @@
+First release.
\ No newline at end of file
diff --git a/po/Makefile.in.in b/po/Makefile.in.in
new file mode 100644
index 0000000..111b40f
--- /dev/null
+++ b/po/Makefile.in.in
@@ -0,0 +1,248 @@
+# Makefile for program source directory in GNU NLS utilities package.
+# Copyright (C) 1995, 1996, 1997 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
+#
+# This file file be copied and used freely without restrictions.  It can
+# be used in projects which are not available under the GNU Public License
+# but which still want to provide support for the GNU gettext functionality.
+# Please note that the actual code is *not* freely available.
+
+PACKAGE = @PACKAGE@
+VERSION = @VERSION@
+
+SHELL = /bin/sh
+@SET_MAKE@
+
+srcdir = @srcdir@
+top_srcdir = @top_srcdir@
+VPATH = @srcdir@
+
+prefix = @prefix@
+exec_prefix = @exec_prefix@
+datadir = $(prefix)/@DATADIRNAME@
+localedir = $(datadir)/locale
+gnulocaledir = $(prefix)/share/locale
+gettextsrcdir = $(prefix)/share/gettext/po
+subdir = po
+
+INSTALL = @INSTALL@
+INSTALL_DATA = @INSTALL_DATA@
+MKINSTALLDIRS = $(top_srcdir)/@MKINSTALLDIRS@
+
+CC = @CC@
+GENCAT = @GENCAT@
+GMSGFMT = PATH=../src:$$PATH @GMSGFMT@
+MSGFMT = @MSGFMT@
+XGETTEXT = PATH=../src:$$PATH @XGETTEXT@
+MSGMERGE = PATH=../src:$$PATH msgmerge
+
+DEFS = @DEFS@
+CFLAGS = @CFLAGS@
+CPPFLAGS = @CPPFLAGS@
+
+INCLUDES = -I.. -I$(top_srcdir)/intl
+
+COMPILE = $(CC) -c $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(XCFLAGS)
+
+SOURCES = cat-id-tbl.c
+POFILES = @POFILES@
+GMOFILES = @GMOFILES@
+DISTFILES = ChangeLog Makefile.in.in POTFILES.in $(PACKAGE).pot \
+stamp-cat-id $(POFILES) $(GMOFILES) $(SOURCES)
+
+POTFILES = \
+
+CATALOGS = @CATALOGS@
+CATOBJEXT = @CATOBJEXT@
+INSTOBJEXT = @INSTOBJEXT@
+
+.SUFFIXES:
+.SUFFIXES: .c .o .po .pox .gmo .mo .msg .cat
+
+.c.o:
+	$(COMPILE) $<
+
+.po.pox:
+	$(MAKE) $(PACKAGE).pot
+	$(MSGMERGE) $< $(srcdir)/$(PACKAGE).pot -o $*.pox
+
+.po.mo:
+	$(MSGFMT) -o $@ $<
+
+.po.gmo:
+	file=$(srcdir)/`echo $* | sed 's,.*/,,'`.gmo \
+	  && rm -f $$file && $(GMSGFMT) -o $$file $<
+
+.po.cat:
+	sed -f ../intl/po2msg.sed < $< > $*.msg \
+	  && rm -f $@ && $(GENCAT) $@ $*.msg
+
+
+all: all-@USE_NLS@
+
+all-yes: cat-id-tbl.c $(CATALOGS)
+all-no:
+
+$(srcdir)/$(PACKAGE).pot: $(POTFILES)
+	$(XGETTEXT) --default-domain=$(PACKAGE) --directory=$(top_srcdir) \
+	  --add-comments --keyword=_ --keyword=N_ \
+	  --files-from=$(srcdir)/POTFILES.in \
+	&& test ! -f $(PACKAGE).po \
+	   || ( rm -f $(srcdir)/$(PACKAGE).pot \
+		&& mv $(PACKAGE).po $(srcdir)/$(PACKAGE).pot )
+
+$(srcdir)/cat-id-tbl.c: stamp-cat-id; @:
+$(srcdir)/stamp-cat-id: $(PACKAGE).pot
+	rm -f cat-id-tbl.tmp
+	sed -f ../intl/po2tbl.sed $(srcdir)/$(PACKAGE).pot \
+		| sed -e "s/@PACKAGE NAME@/$(PACKAGE)/" > cat-id-tbl.tmp
+	if cmp -s cat-id-tbl.tmp $(srcdir)/cat-id-tbl.c; then \
+	  rm cat-id-tbl.tmp; \
+	else \
+	  echo cat-id-tbl.c changed; \
+	  rm -f $(srcdir)/cat-id-tbl.c; \
+	  mv cat-id-tbl.tmp $(srcdir)/cat-id-tbl.c; \
+	fi
+	cd $(srcdir) && rm -f stamp-cat-id && echo timestamp > stamp-cat-id
+
+
+install: install-exec install-data
+install-exec:
+install-data: install-data-@USE_NLS@
+install-data-no: all
+install-data-yes: all
+	if test -r "$(MKINSTALLDIRS)"; then \
+	  $(MKINSTALLDIRS) $(datadir); \
+	else \
+	  $(SHELL) $(top_srcdir)/mkinstalldirs $(datadir); \
+	fi
+	@catalogs='$(CATALOGS)'; \
+	for cat in $$catalogs; do \
+	  cat=`basename $$cat`; \
+	  case "$$cat" in \
+	    *.gmo) destdir=$(gnulocaledir);; \
+	    *)     destdir=$(localedir);; \
+	  esac; \
+	  lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
+	  dir=$$destdir/$$lang/LC_MESSAGES; \
+	  if test -r "$(MKINSTALLDIRS)"; then \
+	    $(MKINSTALLDIRS) $$dir; \
+	  else \
+	    $(SHELL) $(top_srcdir)/mkinstalldirs $$dir; \
+	  fi; \
+	  if test -r $$cat; then \
+	    $(INSTALL_DATA) $$cat $$dir/$(PACKAGE)$(INSTOBJEXT); \
+	    echo "installing $$cat as $$dir/$(PACKAGE)$(INSTOBJEXT)"; \
+	  else \
+	    $(INSTALL_DATA) $(srcdir)/$$cat $$dir/$(PACKAGE)$(INSTOBJEXT); \
+	    echo "installing $(srcdir)/$$cat as" \
+		 "$$dir/$(PACKAGE)$(INSTOBJEXT)"; \
+	  fi; \
+	  if test -r $$cat.m; then \
+	    $(INSTALL_DATA) $$cat.m $$dir/$(PACKAGE)$(INSTOBJEXT).m; \
+	    echo "installing $$cat.m as $$dir/$(PACKAGE)$(INSTOBJEXT).m"; \
+	  else \
+	    if test -r $(srcdir)/$$cat.m ; then \
+	      $(INSTALL_DATA) $(srcdir)/$$cat.m \
+		$$dir/$(PACKAGE)$(INSTOBJEXT).m; \
+	      echo "installing $(srcdir)/$$cat as" \
+		   "$$dir/$(PACKAGE)$(INSTOBJEXT).m"; \
+	    else \
+	      true; \
+	    fi; \
+	  fi; \
+	done
+	if test "$(PACKAGE)" = "gettext"; then \
+	  if test -r "$(MKINSTALLDIRS)"; then \
+	    $(MKINSTALLDIRS) $(gettextsrcdir); \
+	  else \
+	    $(SHELL) $(top_srcdir)/mkinstalldirs $(gettextsrcdir); \
+	  fi; \
+	  $(INSTALL_DATA) $(srcdir)/Makefile.in.in \
+			  $(gettextsrcdir)/Makefile.in.in; \
+	else \
+	  : ; \
+	fi
+
+# Define this as empty until I found a useful application.
+installcheck:
+
+uninstall:
+	catalogs='$(CATALOGS)'; \
+	for cat in $$catalogs; do \
+	  cat=`basename $$cat`; \
+	  lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
+	  rm -f $(localedir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT); \
+	  rm -f $(localedir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT).m; \
+	  rm -f $(gnulocaledir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT); \
+	  rm -f $(gnulocaledir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT).m; \
+	done
+	rm -f $(gettextsrcdir)/po-Makefile.in.in
+
+check: all
+
+cat-id-tbl.o: ../intl/libgettext.h
+
+dvi info tags TAGS ID:
+
+mostlyclean:
+	rm -f core core.* *.pox $(PACKAGE).po *.old.po cat-id-tbl.tmp
+	rm -fr *.o
+
+clean: mostlyclean
+
+distclean: clean
+	rm -f Makefile Makefile.in POTFILES *.mo *.msg *.cat *.cat.m
+
+maintainer-clean: distclean
+	@echo "This command is intended for maintainers to use;"
+	@echo "it deletes files that may require special tools to rebuild."
+	rm -f $(GMOFILES)
+
+distdir = ../$(PACKAGE)-$(VERSION)/$(subdir)
+dist distdir: update-po $(DISTFILES)
+	dists="$(DISTFILES)"; \
+	for file in $$dists; do \
+	  ln $(srcdir)/$$file $(distdir) 2> /dev/null \
+	    || cp -p $(srcdir)/$$file $(distdir); \
+	done
+
+update-po: Makefile
+	$(MAKE) $(PACKAGE).pot
+	PATH=`pwd`/../src:$$PATH; \
+	cd $(srcdir); \
+	catalogs='$(CATALOGS)'; \
+	for cat in $$catalogs; do \
+	  cat=`basename $$cat`; \
+	  lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
+	  mv $$lang.po $$lang.old.po; \
+	  echo "$$lang:"; \
+	  if $(MSGMERGE) $$lang.old.po $(PACKAGE).pot -o $$lang.po; then \
+	    rm -f $$lang.old.po; \
+	  else \
+	    echo "msgmerge for $$cat failed!"; \
+	    rm -f $$lang.po; \
+	    mv $$lang.old.po $$lang.po; \
+	  fi; \
+	done
+
+POTFILES: POTFILES.in
+	( if test 'x$(srcdir)' != 'x.'; then \
+	    posrcprefix='$(top_srcdir)/'; \
+	  else \
+	    posrcprefix="../"; \
+	  fi; \
+	  rm -f $@-t $@ \
+	    && (sed -e '/^#/d' -e '/^[ 	]*$$/d' \
+		    -e "s@.*@	$$posrcprefix& \\\\@" < $(srcdir)/$@.in \
+		| sed -e '$$s/\\$$//') > $@-t \
+	    && chmod a-w $@-t \
+	    && mv $@-t $@ )
+
+Makefile: Makefile.in.in ../config.status POTFILES
+	cd .. \
+	  && CONFIG_FILES=$(subdir)/$@.in CONFIG_HEADERS= \
+	       $(SHELL) ./config.status
+
+# Tell versions [3.59,3.63) of GNU make not to export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
diff --git a/po/POTFILES.in b/po/POTFILES.in
new file mode 100644
index 0000000..5a73e08
--- /dev/null
+++ b/po/POTFILES.in
@@ -0,0 +1,30 @@
+include/Exceptions.h
+include/Handle.h
+include/Input.h
+include/Socket.h
+include/String.h
+include/template.h
+include/Menu.h
+include/Output.h
+include/HttpServ.h
+include/Action.h
+include/Variables.h
+include/Message.h
+include/Form.h
+include/Confirm.h
+include/Table.h
+lib/Exceptions.cc
+lib/Handle.cc
+lib/Input.cc
+lib/Socket.cc
+lib/String.cc
+lib/Output.cc
+lib/Action.cc
+lib/HttpServ.cc
+lib/Menu.cc
+lib/Variables.cc
+lib/Message.cc
+lib/Form.cc
+lib/Confirm.cc
+lib/Table.cc
+src/Main.cc
diff --git a/po/stamp-cat-id b/po/stamp-cat-id
new file mode 100644
index 0000000..9788f70
--- /dev/null
+++ b/po/stamp-cat-id
@@ -0,0 +1 @@
+timestamp
diff --git a/src/Main.cc b/src/Main.cc
new file mode 100644
index 0000000..f3bf0d7
--- /dev/null
+++ b/src/Main.cc
@@ -0,0 +1,80 @@
+#include <unistd.h>
+#include "Action.h"
+#include "Handle.h"
+#include "HttpServ.h"
+#include "Socket.h"
+#include "config.h"
+#include "Message.h"
+#include "Menu.h"
+#include "Exceptions.h"
+#include "Form.h"
+#include "Confirm.h"
+#include "Table.h"
+#include "admin.h"
+
+class InPipe : public Handle {
+  public:
+      InPipe(int in, int out) : Handle(in), m_out(out) { };
+      virtual ~InPipe() {}
+    int GetOut(void) { return m_out; }
+    virtual bool CanWrite(void) { return false; }
+    virtual bool CanRead(void) { return true; }
+    virtual String GetName(void) { return "Input pipe"; }
+  private:
+    int m_out;
+} * in;
+
+extern Action * MenuAdmin, * MenuGestionMatos, * MenuGestionChantier, * MenuGestionPieces, * MenuGestionFournisseurs, * MenuInterventions, * MenuGestionLocations;
+Action * ListeMenuPrincipal[] = {MenuAdmin, MenuGestionMatos, MenuGestionChantier, MenuGestionPieces, MenuGestionFournisseurs, MenuInterventions, MenuGestionLocations};
+String MenuPrincipalLabels[] = {"Administration", "Gestion du materiel", "Gestion des chantiers", "Gestion du stock de pièces", "Gestion des fournisseurs", "Interventions", "Locations"};
+
+Action * buildmenu(void) {
+    return new Menu("Menu Principal", "start", MenuPrincipalLabels, ListeMenuPrincipal, 7);
+}
+
+int main(int argc, char ** argv) {
+    int p[2], c;
+    String port = "1500";
+    
+    if (pipe(p)) {
+	cerr << "Error creating pipe.\n";
+	exit(-1);
+    }
+    
+    close(1);
+    dup(p[1]);
+    in = new InPipe(p[0], p[1]);
+    
+    String test = "poide\n", r;
+    cout << test;
+    cout.flush();
+    (*in) >> r;
+    if (r != "poide") {
+	cerr << "The stdout redirect has failed.\n";
+	exit(-1);
+    }
+    
+    while ((c = getopt(argc, argv, "p:")) != EOF) {
+	switch (c) {
+	case 'p':
+	    port = optarg;
+	    break;
+	default:
+	    cerr << "Usage: " << argv[0] << " [-p port]\n";
+	    exit(-1);
+	}
+    }
+    
+    try {
+	HttpServ h(port.to_int());
+
+	h.MainLoop(buildmenu());
+    }
+    catch (GeneralException e) {
+	cerr << e.GetMsg() << endl;
+	exit(-1);
+    }
+    
+    delete in;
+    exit(0);
+}
diff --git a/src/Makefile.am b/src/Makefile.am
new file mode 100644
index 0000000..b5ed47a
--- /dev/null
+++ b/src/Makefile.am
@@ -0,0 +1,14 @@
+localedir = $(datadir)/locale
+DEFS = -DLOCALEDIR=\"$(localedir)\" @DEFS@
+AM_CFLAGS = -O3 -Wall -Wstrict-prototypes $(CFLAGS)
+AM_CXXFLAGS = -O3 -Wall -Wstrict-prototypes $(CXXFLAGS)
+INCLUDES = -I. -I.. -I$(includedir) -I../include
+
+bin_PROGRAMS = Main
+
+Main_SOURCES = Main.cc
+
+clean:
+	rm -f admin?.o admin?.pc
+
+Main_LDADD = $(LDADD)
diff --git a/src/datas/grain.png b/src/datas/grain.png
new file mode 100644
index 0000000..632ff82
Binary files /dev/null and b/src/datas/grain.png differ
diff --git a/src/datas/style.css b/src/datas/style.css
new file mode 100644
index 0000000..d05d90a
--- /dev/null
+++ b/src/datas/style.css
@@ -0,0 +1,13 @@
+body {  font-family: Arial, Helvetica, sans-serif; font-size: 15pt; }
+th   {  font-family: Arial, Helvetica, sans-serif; font-size: 17pt; font-weight: bold; background-color: #D3DCE3;}
+td   {  font-family: Arial, Helvetica, sans-serif; font-size: 15pt;}
+form   {  font-family: Arial, Helvetica, sans-serif; font-size: 15pt}
+h1   {  font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 30pt; font-weight: bold}
+A:link    {  font-family: Arial, Helvetica, sans-serif; font-size: 15pt; text-decoration: none; color: blue}
+A:visited {  font-family: Arial, Helvetica, sans-serif; font-size: 15pt; text-decoration: none; color: #7F007F}
+A:hover   {  font-family: Arial, Helvetica, sans-serif; font-size: 15pt; text-decoration: underline; color: red}
+A:link.nav {  font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 15pt; color: #000000}
+A:visited.nav {  font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 15pt; color: #000000}
+A:hover.nav {  font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 15pt; color: red;}
+.nav {  font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 15pt; color: #000000}
+
diff --git a/src/misc.cc b/src/misc.cc
new file mode 100644
index 0000000..ea72572
--- /dev/null
+++ b/src/misc.cc
@@ -0,0 +1,66 @@
+#include <list>
+#include "Handle.h"
+#include "String.h"
+
+void GeneDeroul(Handle * h, String * & l1, String * & l2) {
+    int count;
+    list<String> result;
+    String r1, r2;
+    
+    count = 0;
+    
+    while (1) {
+	(*h) >> r1;
+	(*h) >> r2;
+	if ((r1 == "") && (r2 == "")) break;
+	result.push_back(r1);
+	result.push_back(r2);
+	count++;
+    }
+    
+    l1 = new String[count + 1];
+    l2 = new String[count + 1];
+    
+    for (int i = 0; i < count; i++) {
+	r1 = result.front();
+	result.pop_front();
+	r2 = result.front();
+	result.pop_front();
+	l1[i] = r1;
+	l2[i] = r2;
+    }
+    
+    l1[count] = "";
+    l2[count] = "";
+}
+
+int GeneList(Handle * h, int nbcol, String * & l) {
+    int nblig;
+    list<String> result;
+    String r;
+    bool is_null;
+    
+    nblig = 0;
+    while (1) {
+	is_null = true;
+	for (int i = 0; i < nbcol; i++) {
+    	    (*h) >> r;
+	    result.push_back(r);
+	    if (r != "") is_null = false;
+	}
+	if (is_null) break;
+	nblig++;
+    }
+    
+    l = new String[nbcol * nblig + 1];
+    
+    for (int i = 0; i < (nbcol * nblig); i++) {
+	r = result.front();
+	result.pop_front();
+	l[i] = r;
+    }
+    
+    l[nbcol * nblig] = "";
+    
+    return nblig;
+}
diff --git a/stamp-h.in b/stamp-h.in
new file mode 100644
index 0000000..9788f70
--- /dev/null
+++ b/stamp-h.in
@@ -0,0 +1 @@
+timestamp
-- 
cgit v1.2.3