If we're going to talk about replacing an object, we should use the
same object name as the previous example.
Including a non-zero content-length on PUT but not providing a body
will timeout.
Not including the '-' in '-H' will make curl complain:
Rebuilt URL to: H/
* Could not resolve host: H
* Closing connection 1
201 Created responses have content-length of zero, not 116.
Change-Id: Ifd878559ee4036e4893221c7968f53021f38e236
Fixes a number of technical issues with the api-ref section
including:
- Added missing headers
- The header descriptions were made specific to whether they
are used in requests or responses and the verb in question
(example: Content-Length in object HEAD is the object size,
not the response body length).
- Added references to API features such as bulk delete.
- Many typographical fixes (e.g., spaces in the middle
of header names)
- Restored xml and json account/container listing
examples.
The following areas were not updated and it is proposed
to defer them to a subsequent update. This is because
I don't have time or their merit is debatable:
- ACLs (as used in a Keystone context) are not
described.
- Account create/delete is not described.
- I left List Endpoints as-is.
Change-Id: I315b4e550b7d10880fbc00fce9311127ba609c2d
In RFC 7233, response body size of range requests with parameter
'bytes=N-M' is (M - N + 1). And response of object GET request with
range parameter in current Swift implementation is according to the
RFC. However, in current api reference explains that response body
size of object GET request with 'Range: bytes=10-15' is five
( != 15 - 10 + 1).
This patch fixes the api reference explanation.
Change-Id: I8371864f8e5adb42c1e56b7ea26c556ea1252728
Clarify that synced segment container names must be the same
when syncing large objects.
Also add multipart-menifest query string option to API ref
for object GETs.
Change-Id: Ib2d2a1e6c1e5eff215fc75c2b49e7d6758b17b7e
Partial-Bug: #1613681
Closes-Bug: #1613316
This change introduces the concept of a "versioning mode" for
versioned_writes. The following modes are supported:
* stack
When deleting, check whether any previous versions exist in the
versions container. If none is found, the object is deleted. If the
most-recent version in the versions container is not a delete
marker, it is copied into the versioned container (overwriting the
current version if one exists) and then deleted from the versions
container. This preserves the previous behavior.
If the most-recent version in the versions container is a delete
marker and a current version exists in the versioned container, the
current version is deleted. If the most-recent version in the
versions container is a delete marker and no current version exists
in the versioned container, we copy the next-most-recent version
from the versions container into the versioned container (assuming
it exists and is not a delete marker) and delete both the
most-recent version (i.e., the delete marker) and the just-copied
next-most-recent version from the versions container.
With this mode, DELETEs to versioned containers "undo" operations
on containers. Previously this was limited to undoing PUTs, but now
it will also undo DELETEs performed while in "history" mode.
* history
When deleting, check whether a current version exists in the
versioned container. If one is found, it is copied to the versions
container. Then an empty "delete marker" object is also put into the
versions container; this records when the object was deleted.
Finally, the original current version is deleted from the versioned
container. As a result, subsequent GETs or HEADs will return a 404,
and container listings for the versioned container do not include
the object.
With this mode, DELETEs to versioned containers behave like DELETEs
to other containers, but with a history of what has happened.
Clients may specify (via a new X-Versions-Mode header) which mode a
container should use. By default, the existing "stack" mode is used.
Upgrade consideration:
======================
Clients should not use the "history" mode until all proxies in the
cluster have been upgraded. Attempting to use the "history" mode during
a rolling upgrade may result in some requests being served by proxies
running old code (which necessarily uses the "stack" mode), leading to
data loss.
Change-Id: I555dc17fefd0aa9ade681aa156da24e018ebe74b
