couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d..@apache.org
Subject [16/49] Clean up imported .rst
Date Fri, 14 Sep 2012 10:16:59 GMT
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/1.1/other.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/1.1/other.rst b/share/sphinx-docs/1.1/other.rst
new file mode 100644
index 0000000..f5f1e81
--- /dev/null
+++ b/share/sphinx-docs/1.1/other.rst
@@ -0,0 +1,148 @@
+More granular ETag support for views
+====================================
+
+ETags have been assigned to a map/reduce group (the collection of views
+in a single design document). Any change to any of the indexes for those
+views would generate a new ETag for all view URL's in a single design
+doc, even if that specific view's results had not changed.
+
+In CouchDB 1.1 each ``_view`` URL has it's own ETag which only gets
+updated when changes are made to the database that effect that index. If
+the index for that specific view does not change, that view keeps the
+original ETag head (therefore sending back 304 Not Modified more often).
+
+Added built-in filters for ``_changes``: ``_doc_ids`` and ``_design``.
+======================================================================
+
+The ``_changes`` feed can now be used to watch changes to specific
+document ID's or the list of ``_design`` documents in a database. If the
+``filters`` parameter is set to ``_doc_ids`` a list of doc IDs can be
+passed in the "doc_ids" as a JSON array.
+
+Allow wildcards in vhosts definitions
+=====================================
+
+Similar to the rewrites section of a ``_design`` document, the new
+``vhosts`` system uses variables in the form of ``:varname`` or wildcards in
+the form of asterisks. The variable results can be output into the
+resulting path as they are in the rewriter.
+
+OS Daemons
+==========
+
+CouchDB now supports starting external processes. The support is simple
+and enables CouchDB to start each configured OS daemon. If the daemon
+stops at any point, CouchDB will restart it (with protection to ensure
+regularly failing daemons are not repeatedly restarted).
+
+The daemon starting process is one-to-one; for each each configured
+daemon in the configuration file, CouchDB will start exactly one
+instance. If you need to run multiple instances, then you must create
+separate individual configurations. Daemons are configured within the
+``[os_daemons]`` section of your configuration file (``local.ini``). The
+format of each configured daemon is:
+
+::
+
+    NAME = PATH ARGS
+        
+
+Where ``NAME`` is an arbitrary (and unique) name to identify the daemon;
+``PATH`` is the full path to the daemon to be executed; ``ARGS`` are any
+required arguments to the daemon.
+
+For example:
+
+.. code-block:: ini
+
+    [os_daemons]
+    basic_responder = /usr/local/bin/responsder.js
+
+There is no interactivity between CouchDB and the running process, but
+you can use the OS Daemons service to create new HTTP servers and
+responders and then use the new proxy service to redirect requests and
+output to the CouchDB managed service. For more information on proxying,
+see :ref:`proxying`. For further background on the OS Daemon service, see
+`CouchDB Externals API`_.
+
+Stale views and ``update_after``
+================================
+
+Currently a view request can include the ``stale=ok`` query argument,
+which allows the contents of a stale view index to be used to produce
+the view output. In order to trigger a build of the outdated view index,
+a second view request must be made.
+
+To simplify this process, the ``update_after`` value can be supplied to
+the ``stale`` query argument. This triggers a rebuild of the view index
+after the results of the view have been retrieved.
+
+Socket Options Configuration Setting
+====================================
+
+The socket options for the listening socket in CouchDB can now be set
+within the CouchDB configuration file. The setting should be added to
+the ``[httpd]`` section of the file using the option name
+``socket_options``. The specification is as a list of tuples. For
+example:
+
+::
+
+    [httpd]
+    socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}]
+
+The options supported are a subset of full options supported by the
+TCP/IP stack. A list of the supported options are provided in the
+`Erlang inet`_ documentation.
+
+Server Options Configuration Setting
+====================================
+
+Server options for the MochiWeb component of CouchDB can now be added to
+the configuration file. Settings should be added to the
+``server_options`` option of the ``[httpd]`` section of ``local.ini``.
+For example:
+
+.. code-block:: ini
+
+    [httpd]
+    server_options = [{backlog, 128}, {acceptor_pool_size, 16}]
+           
+
+Improved Error Messages
+=======================
+
+The errors reported when CouchDB is unable to read a required file have
+been updated so that explicit information about the files and problem
+can now be identified from the error message. The errors report file
+permission access either when reading or writing to configuration and
+database files.
+
+The error is raised both through the log file and the error message
+returned through the API call as a JSON error message. For example, when
+setting configuration values:
+
+.. code-block:: bash
+
+    shell> curl -X PUT http://couchdb:5984/_config/couchdb/delayed_commits \
+                -H 'X-Couch-Persist: true' -d '"false"'
+    {"error":"file_permission_error","reason":"/etc/couchdb/local.ini"}
+
+Errors will always be reported using the ``file_permission_error`` error
+type.
+
+During startup permissions errors on key files are also reported in the
+log with a descriptive error message and file location so that
+permissions can be fixed before restart.
+
+Multiple micro-optimizations when reading data.
+===============================================
+
+We found a number of places where CouchDB wouldn't do the absolute
+optimal thing when reading data and got rid of quite a few
+inefficiencies. The problem with small optimizations all over the place
+is that you may not notice them with every use-case, but we sure hope
+you can see an improvement overall.
+
+.. _CouchDB Externals API: http://davispj.com/2010/09/26/new-couchdb-externals-api.html
+.. _Erlang inet: http://www.erlang.org/doc/man/inet.html#setopts-2

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/1.1/proxy.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/1.1/proxy.rst b/share/sphinx-docs/1.1/proxy.rst
new file mode 100644
index 0000000..344a1d8
--- /dev/null
+++ b/share/sphinx-docs/1.1/proxy.rst
@@ -0,0 +1,80 @@
+HTTP Proxying
+=============
+
+The HTTP proxy feature makes it easy to map and redirect different
+content through your CouchDB URL. The proxy works by mapping a pathname
+and passing all content after that prefix through to the configured
+proxy address.
+
+Configuration of the proxy redirect is handled through the
+``[httpd_global_handlers]`` section of the CouchDB configuration file
+(typically ``local.ini``). The format is:
+
+.. code-block:: ini
+
+    [httpd_global_handlers]
+    PREFIX = {couch_httpd_proxy, handle_proxy_req, <<"DESTINATION">>}
+      
+
+Where:
+
+-  ``PREFIX``
+
+   Is the string that will be matched. The string can be any valid
+   qualifier, although to ensure that existing database names are not
+   overridden by a proxy configuration, you can use an underscore
+   prefix.
+
+-  ``DESTINATION``
+
+   The fully-qualified URL to which the request should be sent. The
+   destination must include the ``http`` prefix. The content is used
+   verbatim in the original request, so you can also forward to servers
+   on different ports and to specific paths on the target host.
+
+The proxy process then translates requests of the form:
+
+.. code-block:: text
+
+    http://couchdb:5984/PREFIX/path
+
+To:
+
+.. code-block:: text
+
+    DESTINATION/path
+
+.. note::
+   Everything after ``PREFIX`` including the required forward slash
+   will be appended to the ``DESTINATION``.
+
+The response is then communicated back to the original client.
+
+For example, the following configuration:
+
+.. code-block:: ini
+
+    _google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>}
+
+Would forward all requests for ``http://couchdb:5984/_google`` to the
+Google website.
+
+The service can also be used to forward to related CouchDB services,
+such as Lucene:
+
+.. code-block:: ini
+
+    [httpd_global_handlers]
+    _fti = {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:5985">>}
+
+.. note::
+   The proxy service is basic. If the request is not identified by the
+   ``DESTINATION``, or the remainder of the ``PATH`` specification is
+   incomplete, the original request URL is interpreted as if the
+   ``PREFIX`` component of that URL does not exist.
+
+   For example, requesting ``http://couchdb:5984/_intranet/media`` when
+   ``/media`` on the proxy destination does not exist, will cause the
+   request URL to be interpreted as ``http://couchdb:5984/media``. Care
+   should be taken to ensure that both requested URLs and destination
+   URLs are able to cope.

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/1.1/range.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/1.1/range.rst b/share/sphinx-docs/1.1/range.rst
new file mode 100644
index 0000000..cc67a6a
--- /dev/null
+++ b/share/sphinx-docs/1.1/range.rst
@@ -0,0 +1,60 @@
+HTTP Range Requests
+===================
+
+HTTP allows you to specify byte ranges for requests. This allows the
+implementation of resumable downloads and skippable audio and video
+streams alike. Now this is available for all attachments inside CouchDB.
+
+This is just a real quick run through how this looks under the hood.
+Usually, you will have larger binary files to serve from CouchDB, like
+MP3s and videos, but to make things a little more obvious, I use a text
+file here (Note that I use the ``application/octet-stream`` Content-Type
+instead of ``text/plain``).
+
+.. code-block:: bash
+
+    shell> cat file.txt
+    My hovercraft is full of eels!
+
+Now lets store this text file as an attachment in CouchDB. First, we
+create a database:
+
+.. code-block:: bash
+
+    shell> curl -X PUT http://127.0.0.1:5984/test
+    {"ok":true}
+
+Then we create a new document and the file attachment in one go:
+
+.. code-block:: bash
+
+    shell> curl -X PUT http://127.0.0.1:5984/test/doc/file.txt \
+                -H "Content-Type: application/octet-stream" -d@file.txt
+    {"ok":true,"id":"doc","rev":"1-287a28fa680ae0c7fb4729bf0c6e0cf2"}
+
+Now we can request the whole file easily:
+
+.. code-block:: bash
+
+    shell> curl -X GET http://127.0.0.1:5984/test/doc/file.txt
+    My hovercraft is full of eels!
+
+But say we only want the first 13 bytes:
+
+.. code-block:: bash
+
+    shell> curl -X GET http://127.0.0.1:5984/test/doc/file.txt \
+                -H "Range: bytes=0-12"
+    My hovercraft
+
+HTTP supports many ways to specify single and even multiple byte
+rangers. Read all about it in `RFC 2616`_.
+
+.. note::
+   Databases that have been created with CouchDB 1.0.2 or earlier will
+   support range requests in 1.1.0, but they are using a less-optimal
+   algorithm. If you plan to make heavy use of this feature, make sure
+   to compact your database with CouchDB 1.1.0 to take advantage of a
+   better algorithm to find byte ranges.
+
+.. _RFC 2616: http://tools.ietf.org/html/rfc2616#section-14.27

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/1.1/replicator.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/1.1/replicator.rst b/share/sphinx-docs/1.1/replicator.rst
new file mode 100644
index 0000000..5b9d0d4
--- /dev/null
+++ b/share/sphinx-docs/1.1/replicator.rst
@@ -0,0 +1,369 @@
+Replicator Database
+===================
+
+A database where you ``PUT``/``POST`` documents to trigger replications
+and you ``DELETE`` to cancel ongoing replications. These documents have
+exactly the same content as the JSON objects we used to ``POST`` to
+``_replicate`` (fields ``source``, ``target``, ``create_target``,
+``continuous``, ``doc_ids``, ``filter``, ``query_params``.
+
+Replication documents can have a user defined ``_id``. Design documents
+(and ``_local`` documents) added to the replicator database are ignored.
+
+The default name of this database is ``_replicator``. The name can be
+changed in the ``local.ini`` configuration, section ``[replicator]``,
+parameter ``db``.
+
+Basics
+------
+
+Let's say you PUT the following document into ``_replicator``:
+
+.. code-block:: javascript
+
+    {
+        "_id": "my_rep",
+        "source":  "http://myserver.com:5984/foo",
+        "target":  "bar",
+        "create_target":  true
+    }
+
+In the couch log you'll see 2 entries like these:
+
+.. code-block:: text
+
+    [Thu, 17 Feb 2011 19:43:59 GMT] [info] [<0.291.0>] Document `my_rep` triggered replication `c0ebe9256695ff083347cbf95f93e280+create_target`
+    [Thu, 17 Feb 2011 19:44:37 GMT] [info] [<0.124.0>] Replication `c0ebe9256695ff083347cbf95f93e280+create_target` finished (triggered by document `my_rep`)
+
+As soon as the replication is triggered, the document will be updated by
+CouchDB with 3 new fields:
+
+.. code-block:: javascript
+
+    {
+        "_id": "my_rep",
+        "source":  "http://myserver.com:5984/foo",
+        "target":  "bar",
+        "create_target":  true,
+        "_replication_id":  "c0ebe9256695ff083347cbf95f93e280",
+        "_replication_state":  "triggered",
+        "_replication_state_time":  1297974122
+    }
+
+Special fields set by the replicator start with the prefix
+``_replication_``.
+
+-  ``_replication_id``
+
+   The ID internally assigned to the replication. This is also the ID
+   exposed by ``/_active_tasks``.
+
+-  ``_replication_state``
+
+   The current state of the replication.
+
+-  ``_replication_state_time``
+
+   A Unix timestamp (number of seconds since 1 Jan 1970) that tells us
+   when the current replication state (marked in ``_replication_state``)
+   was set.
+
+When the replication finishes, it will update the ``_replication_state``
+field (and ``_replication_state_time``) with the value ``completed``, so
+the document will look like:
+
+.. code-block:: javascript
+
+    {
+        "_id": "my_rep",
+        "source":  "http://myserver.com:5984/foo",
+        "target":  "bar",
+        "create_target":  true,
+        "_replication_id":  "c0ebe9256695ff083347cbf95f93e280",
+        "_replication_state":  "completed",
+        "_replication_state_time":  1297974122
+    }
+
+When an error happens during replication, the ``_replication_state``
+field is set to ``error`` (and ``_replication_state`` gets updated of
+course).
+
+When you PUT/POST a document to the ``_replicator`` database, CouchDB
+will attempt to start the replication up to 10 times (configurable under
+``[replicator]``, parameter ``max_replication_retry_count``). If it
+fails on the first attempt, it waits 5 seconds before doing a second
+attempt. If the second attempt fails, it waits 10 seconds before doing a
+third attempt. If the third attempt fails, it waits 20 seconds before
+doing a fourth attempt (each attempt doubles the previous wait period).
+When an attempt fails, the Couch log will show you something like:
+
+.. code-block:: text
+
+    [error] [<0.149.0>] Error starting replication `67c1bb92010e7abe35d7d629635f18b6+create_target` (document `my_rep_2`): {db_not_found,<<"could not open http://myserver:5986/foo/">>
+
+.. note::
+   The ``_replication_state`` field is only set to ``error`` when all
+   the attempts were unsuccessful.
+
+There are only 3 possible values for the ``_replication_state`` field:
+``triggered``, ``completed`` and ``error``. Continuous replications
+never get their state set to ``completed``.
+
+Documents describing the same replication
+-----------------------------------------
+
+Lets suppose 2 documents are added to the ``_replicator`` database in
+the following order:
+
+.. code-block:: javascript
+
+    {
+        "_id": "doc_A",
+        "source":  "http://myserver.com:5984/foo",
+        "target":  "bar"
+    }
+
+and
+
+.. code-block:: javascript
+
+    {
+        "_id": "doc_B",
+        "source":  "http://myserver.com:5984/foo",
+        "target":  "bar"
+    }
+
+Both describe exactly the same replication (only their ``_ids`` differ).
+In this case document ``doc_A`` triggers the replication, getting
+updated by CouchDB with the fields ``_replication_state``,
+``_replication_state_time`` and ``_replication_id``, just like it was
+described before. Document ``doc_B`` however, is only updated with one
+field, the ``_replication_id`` so it will look like this:
+
+.. code-block:: javascript
+
+    {
+        "_id": "doc_B",
+        "source":  "http://myserver.com:5984/foo",
+        "target":  "bar",
+        "_replication_id":  "c0ebe9256695ff083347cbf95f93e280"
+    }
+
+While document ``doc_A`` will look like this:
+
+.. code-block:: javascript
+
+    {
+        "_id": "doc_A",
+        "source":  "http://myserver.com:5984/foo",
+        "target":  "bar",
+        "_replication_id":  "c0ebe9256695ff083347cbf95f93e280",
+        "_replication_state":  "triggered",
+        "_replication_state_time":  1297974122
+    }
+
+Note that both document get exactly the same value for the
+``_replication_id`` field. This way you can identify which documents
+refer to the same replication - you can for example define a view which
+maps replication IDs to document IDs.
+
+Canceling replications
+----------------------
+
+To cancel a replication simply ``DELETE`` the document which triggered
+the replication. The Couch log will show you an entry like the
+following:
+
+.. code-block:: text
+
+    [Thu, 17 Feb 2011 20:16:29 GMT] [info] [<0.125.0>] Stopped replication `c0ebe9256695ff083347cbf95f93e280+continuous+create_target` because replication document `doc_A` was deleted
+
+.. note::
+   You need to ``DELETE`` the document that triggered the replication.
+   ``DELETE``-ing another document that describes the same replication
+   but did not trigger it, will not cancel the replication.
+
+Server restart
+--------------
+
+When CouchDB is restarted, it checks its ``_replicator`` database and
+restarts any replication that is described by a document that either has
+its ``_replication_state`` field set to ``triggered`` or it doesn't have
+yet the ``_replication_state`` field set.
+
+.. note::
+   Continuous replications always have a ``_replication_state`` field
+   with the value ``triggered``, therefore they're always restarted
+   when CouchDB is restarted.
+
+Changing the Replicator Database
+--------------------------------
+
+Imagine your replicator database (default name is ``_replicator``) has the
+two following documents that represent pull replications from servers A
+and B:
+
+.. code-block:: javascript
+
+    {
+        "_id": "rep_from_A",
+        "source":  "http://aserver.com:5984/foo",
+        "target":  "foo_a",
+        "continuous":  true,
+        "_replication_id":  "c0ebe9256695ff083347cbf95f93e280",
+        "_replication_state":  "triggered",
+        "_replication_state_time":  1297971311
+    }
+
+.. code-block:: javascript
+
+    {
+        "_id": "rep_from_B",
+        "source":  "http://bserver.com:5984/foo",
+        "target":  "foo_b",
+        "continuous":  true,
+        "_replication_id":  "231bb3cf9d48314eaa8d48a9170570d1",
+        "_replication_state":  "triggered",
+        "_replication_state_time":  1297974122
+    }
+
+Now without stopping and restarting CouchDB, you change the name of the
+replicator database to ``another_replicator_db``:
+
+.. code-block:: bash
+
+    $ curl -X PUT http://localhost:5984/_config/replicator/db -d '"another_replicator_db"'
+    "_replicator"
+
+As soon as this is done, both pull replications defined before, are
+stopped. This is explicitly mentioned in CouchDB's log:
+
+.. code-block:: text
+
+    [Fri, 11 Mar 2011 07:44:20 GMT] [info] [<0.104.0>] Stopping all ongoing replications because the replicator database was deleted or changed
+    [Fri, 11 Mar 2011 07:44:20 GMT] [info] [<0.127.0>] 127.0.0.1 - - PUT /_config/replicator/db 200
+
+Imagine now you add a replication document to the new replicator
+database named ``another_replicator_db``:
+
+.. code-block:: javascript
+
+    {
+        "_id": "rep_from_X",
+        "source":  "http://xserver.com:5984/foo",
+        "target":  "foo_x",
+        "continuous":  true
+    }
+
+From now own you have a single replication going on in your system: a
+pull replication pulling from server X. Now you change back the
+replicator database to the original one ``_replicator``:
+
+::
+
+    $ curl -X PUT http://localhost:5984/_config/replicator/db -d '"_replicator"'
+    "another_replicator_db"
+
+Immediately after this operation, the replication pulling from server X
+will be stopped and the replications defined in the ``_replicator``
+database (pulling from servers A and B) will be resumed.
+
+Changing again the replicator database to ``another_replicator_db`` will
+stop the pull replications pulling from servers A and B, and resume the
+pull replication pulling from server X.
+
+Replicating the replicator database
+-----------------------------------
+
+Imagine you have in server C a replicator database with the two
+following pull replication documents in it:
+
+.. code-block:: javascript
+
+    {
+         "_id": "rep_from_A",
+         "source":  "http://aserver.com:5984/foo",
+         "target":  "foo_a",
+         "continuous":  true,
+         "_replication_id":  "c0ebe9256695ff083347cbf95f93e280",
+         "_replication_state":  "triggered",
+         "_replication_state_time":  1297971311
+    }
+
+.. code-block:: javascript
+
+    {
+         "_id": "rep_from_B",
+         "source":  "http://bserver.com:5984/foo",
+         "target":  "foo_b",
+         "continuous":  true,
+         "_replication_id":  "231bb3cf9d48314eaa8d48a9170570d1",
+         "_replication_state":  "triggered",
+         "_replication_state_time":  1297974122
+    }
+
+Now you would like to have the same pull replications going on in server
+D, that is, you would like to have server D pull replicating from
+servers A and B. You have two options:
+
+-  Explicitly add two documents to server's D replicator database
+
+-  Replicate server's C replicator database into server's D replicator
+   database
+
+Both alternatives accomplish exactly the same goal.
+
+Delegations
+-----------
+
+Replication documents can have a custom ``user_ctx`` property. This
+property defines the user context under which a replication runs. For
+the old way of triggering replications (POSTing to ``/_replicate/``),
+this property was not needed (it didn't exist in fact) - this is because
+at the moment of triggering the replication it has information about the
+authenticated user. With the replicator database, since it's a regular
+database, the information about the authenticated user is only present
+at the moment the replication document is written to the database - the
+replicator database implementation is like a ``_changes`` feed consumer
+(with ``?include_docs=true``) that reacts to what was written to the
+replicator database - in fact this feature could be implemented with an
+external script/program. This implementation detail implies that for non
+admin users, a ``user_ctx`` property, containing the user's name and a
+subset of his/her roles, must be defined in the replication document.
+This is ensured by the document update validation function present in
+the default design document of the replicator database. This validation
+function also ensure that a non admin user can set a user name property
+in the ``user_ctx`` property that doesn't match his/her own name (same
+principle applies for the roles).
+
+For admins, the ``user_ctx`` property is optional, and if it's missing
+it defaults to a user context with name null and an empty list of roles
+- this mean design documents will not be written to local targets. If
+writing design documents to local targets is desired, the a user context
+with the roles ``_admin`` must be set explicitly.
+
+Also, for admins the ``user_ctx`` property can be used to trigger a
+replication on behalf of another user. This is the user context that
+will be passed to local target database document validation functions.
+
+.. note::
+   The ``user_ctx`` property only has effect for local endpoints.
+
+Example delegated replication document:
+
+.. code-block:: javascript
+
+    {
+         "_id": "my_rep",
+         "source":  "http://bserver.com:5984/foo",
+         "target":  "bar",
+         "continuous":  true,
+         "user_ctx": {
+              "name": "joe",
+              "roles": ["erlanger", "researcher"]
+         }
+    }
+
+As stated before, for admins the ``user_ctx`` property is optional, while
+for regular (non admin) users it's mandatory. When the roles property of
+``user_ctx`` is missing, it defaults to the empty list ``[ ]``.

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/1.1/ssl.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/1.1/ssl.rst b/share/sphinx-docs/1.1/ssl.rst
new file mode 100644
index 0000000..801a29d
--- /dev/null
+++ b/share/sphinx-docs/1.1/ssl.rst
@@ -0,0 +1,97 @@
+Native SSL Support
+==================
+
+CouchDB 1.1 supports SSL natively. All your secure connection needs can
+now be served without the need set and maintain a separate proxy server
+that handles SSL.
+
+SSL setup can be tricky, but the configuration in CouchDB was designed
+to be as easy as possible. All you need is two files; a certificate and
+a private key. If you bought an official SSL certificate from a
+certificate authority, both should be in your possession already.
+
+If you just want to try this out and don't want to pay anything upfront,
+you can create a self-signed certificate. Everything will work the same,
+but clients will get a warning about an insecure certificate.
+
+You will need the OpenSSL command line tool installed. It probably
+already is.
+
+::
+
+    shell> mkdir cert && cd cert
+    shell> openssl genrsa > privkey.pem
+    shell> openssl req -new -x509 -key privkey.pem -out mycert.pem -days 1095
+    shell> ls
+    mycert.pem privkey.pem
+
+Now, you need to edit CouchDB's configuration, either by editing your
+``local.ini`` file or using the ``/_config`` API calls or the
+configuration screen in Futon. Here is what you need to do in
+``local.ini``, you can infer what needs doing in the other places.
+
+Be sure to make these edits. Under ``[daemons]`` you should see:
+
+::
+
+    ; enable SSL support by uncommenting the following line and supply the PEM's below.
+    ; the default ssl port CouchDB listens on is 6984
+    ;httpsd = {couch_httpd, start_link, [https]}
+
+Here uncomment the last line:
+
+::
+
+    httpsd = {couch_httpd, start_link, [https]}
+
+Next, under ``[ssl]`` you will see:
+
+::
+
+    ;cert_file = /full/path/to/server_cert.pem
+    ;key_file = /full/path/to/server_key.pem
+
+Uncomment and adjust the paths so it matches your system's paths:
+
+::
+
+    cert_file = /home/jan/cert/mycert.pem
+    key_file = /home/jan/cert/privkey.pem
+
+For more information please read
+`http://www.openssl.org/docs/HOWTO/certificates.txt`_.
+
+Now start (or restart) CouchDB. You should be able to connect to it
+using HTTPS on port 6984:
+
+::
+
+    shell> curl https://127.0.0.1:6984/
+    curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
+    error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
+    More details here: http://curl.haxx.se/docs/sslcerts.html
+
+    curl performs SSL certificate verification by default, using a "bundle"
+    of Certificate Authority (CA) public keys (CA certs). If the default
+    bundle file isn't adequate, you can specify an alternate file
+    using the --cacert option.
+    If this HTTPS server uses a certificate signed by a CA represented in
+    the bundle, the certificate verification probably failed due to a
+    problem with the certificate (it might be expired, or the name might
+    not match the domain name in the URL).
+    If you'd like to turn off curl's verification of the certificate, use
+    the -k (or --insecure) option.
+
+Oh no what happened?! — Remember, clients will notify their users that
+your certificate is self signed. ``curl`` is the client in this case and
+it notifies you. Luckily you trust yourself (don't you?) and you can
+specify the ``-k`` option as the message reads:
+
+::
+
+    shell> curl -k https://127.0.0.1:6984/
+    {"couchdb":"Welcome","version":"1.1.0"}
+
+All done.
+
+.. _`http://www.openssl.org/docs/HOWTO/certificates.txt`: http://www.openssl.org/docs/HOWTO/certificates.txt

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/Makefile
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/Makefile b/share/sphinx-docs/Makefile
new file mode 100644
index 0000000..e2a80c1
--- /dev/null
+++ b/share/sphinx-docs/Makefile
@@ -0,0 +1,153 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+BUILDDIR      = build
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
+
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  dirhtml    to make HTML files named index.html in directories"
+	@echo "  singlehtml to make a single large HTML file"
+	@echo "  pickle     to make pickle files"
+	@echo "  json       to make JSON files"
+	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  qthelp     to make HTML files and a qthelp project"
+	@echo "  devhelp    to make HTML files and a Devhelp project"
+	@echo "  epub       to make an epub"
+	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
+	@echo "  text       to make text files"
+	@echo "  man        to make manual pages"
+	@echo "  texinfo    to make Texinfo files"
+	@echo "  info       to make Texinfo files and run them through makeinfo"
+	@echo "  gettext    to make PO message catalogs"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  linkcheck  to check all external links for integrity"
+	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+	-rm -rf $(BUILDDIR)/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+singlehtml:
+	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/CouchDB.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/CouchDB.qhc"
+
+devhelp:
+	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+	@echo
+	@echo "Build finished."
+	@echo "To view the help file:"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/CouchDB"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/CouchDB"
+	@echo "# devhelp"
+
+epub:
+	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+
+latexpdf:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through pdflatex..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+text:
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+man:
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+texinfo:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+
+info:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+gettext:
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+	@echo
+	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/TODO.txt
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/TODO.txt b/share/sphinx-docs/TODO.txt
new file mode 100644
index 0000000..00fd3ba
--- /dev/null
+++ b/share/sphinx-docs/TODO.txt
@@ -0,0 +1,11 @@
+- Actually explain configuration options in configuring [reference]
+- Write some documentation on (writing) views [views]
+- Expand view documentation in reference (skipping and grouping) [api/design]
+- Write documentation on the changes feed [changes]
+- Share content from 1.1 in main docs somehow (ssl, proxying)
+- Fill out db maintenance reference (?) [api/dbmaint]
+- Fill out authentication reference [api/authn]
+- Document missing APIs [api/database]
+- Add table with list of APIs [api/design]
+- Update documentation for 1.2
+- Update documentation for master

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/api-basics.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/api-basics.rst b/share/sphinx-docs/api-basics.rst
new file mode 100644
index 0000000..17d609e
--- /dev/null
+++ b/share/sphinx-docs/api-basics.rst
@@ -0,0 +1,435 @@
+.. _api-basics:
+
+===========
+CouchDB API
+===========
+
+The CouchDB API is the primary method of interfacing to a CouchDB
+instance. Requests are made using HTTP and requests are used to request
+information from the database, store new data, and perform views and
+formatting of the information stored within the documents.
+
+Requests to the API can be categorised by the different areas of the
+CouchDB system that you are accessing, and the HTTP method used to send
+the request. Different methods imply different operations, for example
+retrieval of information from the database is typically handled by the
+``GET`` operation, while updates are handled by either a ``POST`` or
+``PUT`` request. There are some differences between the information that
+must be supplied for the different methods. For a guide to the basic
+HTTP methods and request structure, see :ref:`api-format`.
+
+For nearly all operations, the submitted data, and the returned data
+structure, is defined within a JavaScript Object Notation (JSON) object.
+Basic information on the content and data types for JSON are provided in
+:ref:`json`.
+
+Errors when accessing the CouchDB API are reported using standard HTTP
+Status Codes. A guide to the generic codes returned by CouchDB are
+provided in :ref:`errors`.
+
+When accessing specific areas of the CouchDB API, specific information
+and examples on the HTTP methods and request, JSON structures, and error
+codes are provided. For a guide to the different areas of the API, see
+:ref:`api-overview`.
+
+.. _api-format:
+
+Request Format and Responses
+============================
+
+CouchDB supports the following HTTP request methods:
+
+-  ``GET``
+
+   Request the specified item. As with normal HTTP requests, the format
+   of the URL defines what is returned. With CouchDB this can include
+   static items, database documents, and configuration and statistical
+   information. In most cases the information is returned in the form of
+   a JSON document.
+
+-  ``HEAD``
+
+   The ``HEAD`` method is used to get the HTTP header of a ``GET``
+   request without the body of the response.
+
+-  ``POST``
+
+   Upload data. Within CouchDB ``POST`` is used to set values, including
+   uploading documents, setting document values, and starting certain
+   administration commands.
+
+-  ``PUT``
+
+   Used to put a specified resource. In CouchDB ``PUT`` is used to
+   create new objects, including databases, documents, views and design
+   documents.
+
+-  ``DELETE``
+
+   Deletes the specified resource, including documents, views, and
+   design documents.
+
+-  ``COPY``
+
+   A special method that can be used to copy documents and objects.
+
+If you use the an unsupported HTTP request type with a URL that does not
+support the specified type, a 405 error will be returned, listing the
+supported HTTP methods. For example:
+
+.. code-block:: javascript
+
+    {
+        "error":"method_not_allowed",
+        "reason":"Only GET,HEAD allowed"
+    }
+          
+
+The CouchDB design document API and the functions when returning HTML
+(for example as part of a show or list) enables you to include custom
+HTTP headers through the ``headers`` block of the return object.
+
+HTTP Headers
+============
+
+Because CouchDB uses HTTP for all communication, you need to ensure that
+the correct HTTP headers are supplied (and processed on retrieval) so
+that you get the right format and encoding. Different environments and
+clients will be more or less strict on the effect of these HTTP headers
+(especially when not present). Where possible you should be as specific
+as possible.
+
+Request Headers
+---------------
+
+-  ``Content-type``
+
+   Specifies the content type of the information being supplied within
+   the request. The specification uses MIME type specifications. For the
+   majority of requests this will be JSON (``application/json``). For
+   some settings the MIME type will be plain text. When uploading
+   attachments it should be the corresponding MIME type for the
+   attachment or binary (``application/octet-stream``).
+
+   The use of the ``Content-type`` on a request is highly recommended.
+
+-  ``Accept``
+
+   Specifies the list of accepted data types to be returned by the
+   server (i.e. that are accepted/understandable by the client). The
+   format should be a list of one or more MIME types, separated by
+   colons.
+
+   For the majority of requests the definition should be for JSON data
+   (``application/json``). For attachments you can either specify the
+   MIME type explicitly, or use ``*/*`` to specify that all file types
+   are supported. If the ``Accept`` header is not supplied, then the
+   ``*/*`` MIME type is assumed (i.e. client accepts all formats).
+
+   The use of ``Accept`` in queries for CouchDB is not required, but is
+   highly recommended as it helps to ensure that the data returned can
+   be processed by the client.
+
+   If you specify a data type using the ``Accept`` header, CouchDB will
+   honor the specified type in the ``Content-type`` header field
+   returned. For example, if you explicitly request ``application/json``
+   in the ``Accept`` of a request, the returned HTTP headers will use
+   the value in the returned ``Content-type`` field.
+
+   For example, when sending a request without an explicit ``Accept``
+   header, or when specifying ``*/*``:
+
+   .. code-block:: http
+
+       GET /recipes HTTP/1.1
+       Host: couchdb:5984
+       Accept: */*
+
+   The returned headers are:
+
+   .. code-block:: http
+
+       Server: CouchDB/1.0.1 (Erlang OTP/R13B)
+       Date: Thu, 13 Jan 2011 13:39:34 GMT
+       Content-Type: text/plain;charset=utf-8
+       Content-Length: 227
+       Cache-Control: must-revalidate
+
+   Note that the returned content type is ``text/plain`` even though the
+   information returned by the request is in JSON format.
+
+   Explicitly specifying the ``Accept`` header:
+
+   .. code-block:: http
+
+       GET /recipes HTTP/1.1
+       Host: couchdb:5984
+       Accept: application/json
+
+   The headers returned include the ``application/json`` content type:
+
+   .. code-block:: http
+
+       Server: CouchDB/1.0.1 (Erlang OTP/R13B)
+       Date: Thu, 13 Jan 2011 13:40:11 GMT
+       Content-Type: application/json
+       Content-Length: 227
+       Cache-Control: must-revalidate
+
+Response Headers
+----------------
+
+Response headers are returned by the server when sending back content
+and include a number of different header fields, many of which are
+standard HTTP response header and have no significance to CouchDB
+operation. The list of response headers important to CouchDB are listed
+below.
+
+-  ``Content-type``
+
+   Specifies the MIME type of the returned data. For most request, the
+   returned MIME type is ``text/plain``. All text is encoded in Unicode
+   (UTF-8), and this is explicitly stated in the returned
+   ``Content-type``, as ``text/plain;charset=utf-8``.
+
+-  ``Cache-control``
+
+   The cache control HTTP response header provides a suggestion for
+   client caching mechanisms on how to treat the returned information.
+   CouchDB typically returns the ``must-revalidate``, which indicates
+   that the information should be revalidated if possible. This is used
+   to ensure that the dynamic nature of the content is correctly
+   updated.
+
+-  ``Content-length``
+
+   The length (in bytes) of the returned content.
+
+-  ``Etag``
+
+   The ``Etag`` HTTP header field is used to show the revision for a
+   document.
+
+.. _json:
+
+JSON Basics
+===========
+
+The majority of requests and responses to CouchDB use the JavaScript
+Object Notation (JSON) for formatting the content and structure of the
+data and responses.
+
+JSON is used because it is the simplest and easiest to use solution for
+working with data within a web browser, as JSON structures can be
+evaluated and used as JavaScript objects within the web browser
+environment. JSON also integrates with the server-side JavaScript used
+within CouchDB.
+
+JSON supports the same basic types as supported by JavaScript, these
+are:
+
+-  Number (either integer or floating-point).
+
+-  String; this should be enclosed by double-quotes and supports Unicode
+   characters and backslash escaping. For example:
+
+   .. code-block:: javascript
+
+       "A String"
+
+-  Boolean - a ``true`` or ``false`` value. You can use these strings
+   directly. For example:
+
+   .. code-block:: javascript
+
+       { "value": true}
+
+-  Array - a list of values enclosed in square brackets. For example:
+
+   .. code-block:: javascript
+
+       ["one", "two", "three"]
+
+-  Object - a set of key/value pairs (i.e. an associative array, or
+   hash). The key must be a string, but the value can be any of the
+   supported JSON values. For example:
+
+   .. code-block:: javascript
+
+       {
+          "servings" : 4,
+          "subtitle" : "Easy to make in advance, and then cook when ready",
+          "cooktime" : 60,
+          "title" : "Chicken Coriander"
+       }
+           
+
+   In CouchDB, the JSON object is used to represent a variety of
+   structures, including the main CouchDB document.
+
+Parsing JSON into a JavaScript object is supported through the
+``eval()`` function in JavaScript, or through various libraries that
+will perform the parsing of the content into a JavaScript object for
+you. Libraries for parsing and generating JSON are available in many
+languages, including Perl, Python, Ruby, Erlang and others.
+
+.. warning::
+   Care should be taken to ensure that your JSON structures are
+   valid, invalid structures will cause CouchDB to return an HTTP status code
+   of 500 (server error).
+
+.. _errors:
+
+HTTP Status Codes
+=================
+
+With the interface to CouchDB working through HTTP, error codes and
+statuses are reported using a combination of the HTTP status code
+number, and corresponding data in the body of the response data.
+
+A list of the error codes returned by CouchDB, and generic descriptions
+of the related errors are provided below. The meaning of different
+status codes for specific request types are provided in the
+corresponding API call reference.
+
+-  ``200 - OK``
+
+   Request completed successfully.
+
+-  ``201 - Created``
+
+   Document created successfully.
+
+-  ``202 - Accepted``
+
+   Request has been accepted, but the corresponding operation may not
+   have completed. This is used for background operations, such as
+   database compaction.
+
+-  ``304 - Not Modified``
+
+   The additional content requested has not been modified. This is used
+   with the ETag system to identify the version of information returned.
+
+-  ``400 - Bad Request``
+
+   Bad request structure. The error can indicate an error with the
+   request URL, path or headers. Differences in the supplied MD5 hash
+   and content also trigger this error, as this may indicate message
+   corruption.
+
+-  ``401 - Unauthorized``
+
+   The item requested was not available using the supplied
+   authorization, or authorization was not supplied.
+
+-  ``403 - Forbidden``
+
+   The requested item or operation is forbidden.
+
+-  ``404 - Not Found``
+
+   The requested content could not be found. The content will include
+   further information, as a JSON object, if available. The structure
+   will contain two keys, ``error`` and ``reason``. For example:
+
+   .. code-block:: javascript
+
+       {"error":"not_found","reason":"no_db_file"}
+
+-  ``405 - Resource Not Allowed``
+
+   A request was made using an invalid HTTP request type for the URL
+   requested. For example, you have requested a ``PUT`` when a ``POST``
+   is required. Errors of this type can also triggered by invalid URL
+   strings.
+
+-  ``406 - Not Acceptable``
+
+   The requested content type is not supported by the server.
+
+-  ``409 - Conflict``
+
+   Request resulted in an update conflict.
+
+-  ``412 - Precondition Failed``
+
+   The request headers from the client and the capabilities of the
+   server do not match.
+
+-  ``415 - Bad Content Type``
+
+   The content types supported, and the content type of the information
+   being requested or submitted indicate that the content type is not
+   supported.
+
+-  ``416 - Requested Range Not Satisfiable``
+
+   The range specified in the request header cannot be satisfied by the
+   server.
+
+-  ``417 - Expectation Failed``
+
+   When sending documents in bulk, the bulk load operation failed.
+
+-  ``500 - Internal Server Error``
+
+   The request was invalid, either because the supplied JSON was
+   invalid, or invalid information was supplied as part of the request.
+
+.. _api-overview:
+
+CouchDB API Overview
+====================
+
+The components of the API URL path help determine the part of the
+CouchDB server that is being accessed. The result is the structure of
+the URL request both identifies and effectively describes the area of
+the database you are accessing.
+
+As with all URLs, the individual components are separated by a forward
+slash.
+
+As a general rule, URL components and JSON fields starting with the
+``_`` (underscore) character represent a special component or entity
+within the server or returned object. For example, the URL fragment
+``/_all_dbs`` gets a list of all of the databases in a CouchDB instance.
+
+The remainder of the URL API structure can be divided up according to
+the URL structure. The different sections are divided as follows:
+
+-  ``/db``
+
+   Database methods, related to adding, updating or deleting databases,
+   and setting database parameters and operations. For more detailed
+   information, see :ref:`api-db`.
+
+-  ``/db/doc``
+
+   Document methods, those that create, store, update or delete CouchDB
+   documents and their attachments. For more information, see :ref:`api-doc`.
+
+-  ``/db/_local/local-doc``
+
+   Document methods, those that create, store, update or delete CouchDB
+   documents only within the local database. Local documents are not
+   synchronized with other databases. For more information, see
+   :ref:`api-local`.
+
+-  ``/db/_design/design-doc``
+
+   Design documents provide the methods and structure for recovering
+   information from a CouchDB database in the form of views, shows and
+   lists. For more information, see :ref:`api-design`.
+
+-  ``/_special``
+
+   Special methods that obtain or set information about the CouchDB
+   instance, including methods for configuring replication, accessing
+   the logs, and generate Universally Unique IDs (UUIDs). For more
+   information, see :ref:`api-misc`.
+
+-  ``/_config``
+
+   Methods for getting, and settings, CouchDB configuration parameters.
+   For more information, see :ref:`api-config`.

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/api/authn.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/api/authn.rst b/share/sphinx-docs/api/authn.rst
new file mode 100644
index 0000000..66dd7f2
--- /dev/null
+++ b/share/sphinx-docs/api/authn.rst
@@ -0,0 +1,29 @@
+======================
+Authentication Methods
+======================
+
+.. todo:: Authentication Methods
+
+The CouchDB Authentication methods provide an interface for obtaining
+session and authorization data.
+
+A list of the available methods and URL paths are provided below:
+
++--------+-------------------------+-------------------------------------------+
+| Method | Path                    | Description                               |
++========+=========================+===========================================+
+| GET    | /_oauth/access_token    | TBC                                       |
++--------+-------------------------+-------------------------------------------+
+| GET    | /_oauth/authorize       | TBC                                       |
++--------+-------------------------+-------------------------------------------+
+| POST   | /_oauth/authorize       | TBC                                       |
++--------+-------------------------+-------------------------------------------+
+| GET    | /_oauth/request_token   | TBC                                       |
++--------+-------------------------+-------------------------------------------+
+| GET    | /_session               | Returns cookie based login user           |
+|        |                         | information                               |
++--------+-------------------------+-------------------------------------------+
+| POST   | /_session               | Do cookie based user login                |
++--------+-------------------------+-------------------------------------------+
+| DELETE | /_session               | Logout cookie based user                  |
++--------+-------------------------+-------------------------------------------+

http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/sphinx-docs/api/configuration.rst
----------------------------------------------------------------------
diff --git a/share/sphinx-docs/api/configuration.rst b/share/sphinx-docs/api/configuration.rst
new file mode 100644
index 0000000..a57e5d2
--- /dev/null
+++ b/share/sphinx-docs/api/configuration.rst
@@ -0,0 +1,285 @@
+.. _api-config:
+
+=====================
+Configuration Methods
+=====================
+
+The CouchDB API Server Configuration Methods provide an interface to
+query and update the various configuration values within a running
+CouchDB instance.
+
+A list of the available methods and URL paths are provided below:
+
++--------+-------------------------+-------------------------------------------+
+| Method | Path                    | Description                               |
++========+=========================+===========================================+
+| GET    | /_config                | Obtain a list of the entire server        |
+|        |                         | configuration                             |
++--------+-------------------------+-------------------------------------------+
+| GET    | /_config/section        | Get all the configuration values for the  |
+|        |                         | specified section                         |
++--------+-------------------------+-------------------------------------------+
+| GET    | /_config/section/key    | Get a specific section/configuration value|
++--------+-------------------------+-------------------------------------------+
+| PUT    | /_config/section/key    | Set the specified configuration value     |
++--------+-------------------------+-------------------------------------------+
+| DELETE | /_config/section/key    | Delete the current setting                |
++--------+-------------------------+-------------------------------------------+
+
+``GET /_config``
+================
+
+* **Method**: ``GET /_config``
+* **Request**: None
+* **Response**: Returns a structure configuration name and value pairs,
+  organized by section
+* **Admin Privileges Required**: yes
+* **Return Codes**:
+
+  * **200**:
+    Request completed successfully.
+
+Returns the entire CouchDB server configuration as a JSON structure. The
+structure is organized by different configuration sections, with
+individual values.
+
+For example, to get the configuration for a server:
+
+.. code-block:: http
+
+    GET http://couchdb:5984/_config
+    Accept: application/json
+
+The response is the JSON structure:
+
+.. code-block:: javascript
+
+    {
+       "query_server_config" : {
+          "reduce_limit" : "true"
+       },
+       "couchdb" : {
+          "os_process_timeout" : "5000",
+          "max_attachment_chunk_size" : "4294967296",
+          "max_document_size" : "4294967296",
+          "uri_file" : "/var/lib/couchdb/couch.uri",
+          "max_dbs_open" : "100",
+          "view_index_dir" : "/var/lib/couchdb",
+          "util_driver_dir" : "/usr/lib64/couchdb/erlang/lib/couch-1.0.1/priv/lib",
+          "database_dir" : "/var/lib/couchdb",
+          "delayed_commits" : "true"
+       },
+       "attachments" : {
+          "compressible_types" : "text/*, application/javascript, application/json,  application/xml",
+          "compression_level" : "8"
+       },
+       "uuids" : {
+          "algorithm" : "utc_random"
+       },
+       "daemons" : {
+          "view_manager" : "{couch_view, start_link, []}",
+          "auth_cache" : "{couch_auth_cache, start_link, []}",
+          "uuids" : "{couch_uuids, start, []}",
+          "stats_aggregator" : "{couch_stats_aggregator, start, []}",
+          "query_servers" : "{couch_query_servers, start_link, []}",
+          "httpd" : "{couch_httpd, start_link, []}",
+          "stats_collector" : "{couch_stats_collector, start, []}",
+          "db_update_notifier" : "{couch_db_update_notifier_sup, start_link, []}",
+          "external_manager" : "{couch_external_manager, start_link, []}"
+       },
+       "stats" : {
+          "samples" : "[0, 60, 300, 900]",
+          "rate" : "1000"
+       },
+       "httpd" : {
+          "vhost_global_handlers" : "_utils, _uuids, _session, _oauth, _users",
+          "secure_rewrites" : "true",
+          "authentication_handlers" : "{couch_httpd_oauth, oauth_authentication_handler},
+                                       {couch_httpd_auth, cookie_authentication_handler},
+                                       {couch_httpd_auth, default_authentication_handler}",
+          "port" : "5984",
+          "default_handler" : "{couch_httpd_db, handle_request}",
+          "allow_jsonp" : "false",
+          "bind_address" : "192.168.0.2",
+          "max_connections" : "2048"
+       },
+       "query_servers" : {
+          "javascript" : "/usr/bin/couchjs /usr/share/couchdb/server/main.js"
+       },
+       "couch_httpd_auth" : {
+          "authentication_db" : "_users",
+          "require_valid_user" : "false",
+          "authentication_redirect" : "/_utils/session.html",
+          "timeout" : "600",
+          "auth_cache_size" : "50"
+       },
+       "httpd_db_handlers" : {
+          "_design" : "{couch_httpd_db, handle_design_req}",
+          "_compact" : "{couch_httpd_db, handle_compact_req}",
+          "_view_cleanup" : "{couch_httpd_db, handle_view_cleanup_req}",
+          "_temp_view" : "{couch_httpd_view, handle_temp_view_req}",
+          "_changes" : "{couch_httpd_db, handle_changes_req}"
+       },
+       "replicator" : {
+          "max_http_sessions" : "10",
+          "max_http_pipeline_size" : "10"
+       },
+       "log" : {
+          "include_sasl" : "true",
+          "level" : "info",
+          "file" : "/var/log/couchdb/couch.log"
+       },
+       "httpd_design_handlers" : {
+          "_update" : "{couch_httpd_show, handle_doc_update_req}",
+          "_show" : "{couch_httpd_show, handle_doc_show_req}",
+          "_info" : "{couch_httpd_db,   handle_design_info_req}",
+          "_list" : "{couch_httpd_show, handle_view_list_req}",
+          "_view" : "{couch_httpd_view, handle_view_req}",
+          "_rewrite" : "{couch_httpd_rewrite, handle_rewrite_req}"
+       },
+       "httpd_global_handlers" : {
+          "_replicate" : "{couch_httpd_misc_handlers, handle_replicate_req}",
+          "/" : "{couch_httpd_misc_handlers, handle_welcome_req, <<\"Welcome\">>}",
+          "_config" : "{couch_httpd_misc_handlers, handle_config_req}",
+          "_utils" : "{couch_httpd_misc_handlers, handle_utils_dir_req, \"/usr/share/couchdb/www\"}",
+          "_active_tasks" : "{couch_httpd_misc_handlers, handle_task_status_req}",
+          "_session" : "{couch_httpd_auth, handle_session_req}",
+          "_log" : "{couch_httpd_misc_handlers, handle_log_req}",
+          "favicon.ico" : "{couch_httpd_misc_handlers, handle_favicon_req, \"/usr/share/couchdb/www\"}",
+          "_all_dbs" : "{couch_httpd_misc_handlers, handle_all_dbs_req}",
+          "_oauth" : "{couch_httpd_oauth, handle_oauth_req}",
+          "_restart" : "{couch_httpd_misc_handlers, handle_restart_req}",
+          "_uuids" : "{couch_httpd_misc_handlers, handle_uuids_req}",
+          "_stats" : "{couch_httpd_stats_handlers, handle_stats_req}"
+       }
+    }
+        
+
+``GET /_config/section``
+========================
+
+* **Method**: ``GET /_config/section``
+* **Request**: None
+* **Response**: All the configuration values within a specified section
+* **Admin Privileges Required**: yes
+* **Return Codes**:
+
+  * **200**:
+    Request completed successfully.
+
+Gets the configuration structure for a single section. For example, to
+retrieve the CouchDB configuration section values:
+
+.. code-block:: http
+
+    GET http://couchdb:5984/_config/couchdb
+    Accept: application/json
+
+The returned JSON contains just the configuration values for this
+section:
+
+.. code-block:: javascript
+
+    {
+       "os_process_timeout" : "5000",
+       "max_attachment_chunk_size" : "4294967296",
+       "max_document_size" : "4294967296",
+       "uri_file" : "/var/lib/couchdb/couch.uri",
+       "max_dbs_open" : "100",
+       "view_index_dir" : "/var/lib/couchdb",
+       "util_driver_dir" : "/usr/lib64/couchdb/erlang/lib/couch-1.0.1/priv/lib",
+       "database_dir" : "/var/lib/couchdb",
+       "delayed_commits" : "true"
+    }
+
+``GET /_config/section/key``
+============================
+
+* **Method**: ``GET /_config/section/key``
+* **Request**: None
+* **Response**: Value of the specified key/section
+* **Admin Privileges Required**: yes
+* **Return Codes**:
+
+  * **200**:
+    Request completed successfully.
+
+Gets a single configuration value from within a specific configuration
+section. For example, to obtain the current log level:
+
+.. code-block:: http
+
+    GET http://couchdb:5984/_config/log/level
+    Accept: application/json
+
+Returns the string of the log level:
+
+.. code-block:: javascript
+
+    "info"
+
+.. note::
+   The returned value will be the JSON of the value, which may be a
+   string or numeric value, or an array or object. Some client
+   environments may not parse simple strings or numeric values as valid JSON.
+
+.. _api-put-config:
+
+``PUT /_config/section/key``
+============================
+
+* **Method**: ``PUT /_config/section/key``
+* **Request**: Value structure
+* **Response**: Previous value
+* **Admin Privileges Required**: yes
+* **Return Codes**:
+
+  * **200**:
+    Configuration option updated successfully
+
+  * **500**:
+    Error setting configuration
+
+Updates a configuration value. The new value should be supplied in the
+request body in the corresponding JSON format. For example, if you are
+setting a string value, you must supply a valid JSON string.
+
+For example, to set the function used to generate UUIDs by the
+``GET /_uuids`` API call to use the ``utc_random`` generator:
+
+.. code-block:: http
+
+    PUT http://couchdb:5984/_config/uuids/algorithm
+    Content-Type: application/json
+
+    "utc_random"
+
+The return value will be empty, with the response code indicating the
+success or failure of the configuration setting.
+
+``DELETE /_config/section/key``
+===============================
+
+* **Method**: ``DELETE /_config/section/key``
+* **Request**: None
+* **Response**: Previous value
+* **Admin Privileges Required**: yes
+* **Return Codes**:
+
+  * **409**:
+    Supplied revision is incorrect or missing
+
+Deletes a configuration value. The returned JSON will be the value of
+the configuration parameter before it was deleted. For example, to
+delete the UUID parameter:
+
+.. code-block:: http
+
+    DELETE http://couchdb:5984/_config/uuids/algorithm
+    Content-Type: application/json
+
+The returned value is the last configured UUID function:
+
+.. code-block:: javascript
+
+    "random"


Mime
View raw message