Returns the HTTP headers containing a minimal amount of information about
the specified attachment. The method supports the same query arguments as
the GET/{db}/{docid}/{attname} method, but only the header information
(including attachment size, encoding and the MD5 hash as an
ETag), is returned.

Returns the file attachment associated with the document. The raw data of
the associated attachment is returned (just as if you were accessing a
static file. The returned Content-Type will be the same as the
content type set when the document attachment was submitted into the
database.

Uploads the supplied content as an attachment to the specified document.
The attachment name provided must be a URL encoded string. You must supply
the Content-Type header, and for an existing document you must also supply
either the rev query argument or the If-Match HTTP header. If
the revision is omitted, a new, otherwise empty document will be created
with the provided attachment, or a conflict will occur.

If case when uploading an attachment using an existing attachment name,
CouchDB will update the corresponding stored content of the database. Since
you must supply the revision information to add an attachment to the
document, this serves as validation to update the existing attachment.

Note

Uploading an attachment updates the corresponding document revision.
Revisions are tracked for the parent document, not individual
attachments.

HTTP allows you to specify byte ranges for requests. This allows the
implementation of resumable downloads and skippable audio and video streams
alike. 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 :header`Content-Type` instead of
text/plain).

shell> cat file.txt
My hovercraft is full of eels!

Now let’s store this text file as an attachment in CouchDB. First, we create a
database:

HTTP supports many ways to specify single and even multiple byte
ranges. Read all about it in RFC 2616#section-14.27.

Note

Databases that have been created with CouchDB 1.0.2 or earlier will support
range requests in 2.3, 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 2.3 to take advantage of a better algorithm to
find byte ranges.