Curly quotes(Chinese punctuation) usually input from Chinese input method.
When read from english context, it makes some confusion.
Change-Id: Ibd50299ee287c56ec4759ea8ff53d47d006144f8
Add a symbolic link ("symlink") object support to Swift. This
object will reference another object. GET and HEAD
requests for a symlink object will operate on the referenced object.
DELETE and PUT requests for a symlink object will operate on the
symlink object, not the referenced object, and will delete or
overwrite it, respectively.
POST requests are *not* forwarded to the referenced object and should
be sent directly. POST requests sent to a symlink object will
result in a 307 Error.
Historical information on symlink design can be found here:
https://github.com/openstack/swift-specs/blob/master/specs/in_progress/symlinks.rst.
https://etherpad.openstack.org/p/swift_symlinks
Co-Authored-By: Thiago da Silva <thiago@redhat.com>
Co-Authored-By: Janie Richling <jrichli@us.ibm.com>
Co-Authored-By: Kazuhiro MIYAHARA <miyahara.kazuhiro@lab.ntt.co.jp>
Co-Authored-By: Kota Tsuyuzaki <tsuyuzaki.kota@lab.ntt.co.jp>
Change-Id: I838ed71bacb3e33916db8dd42c7880d5bb9f8e18
Signed-off-by: Thiago da Silva <thiago@redhat.com>
In current API reference, 'bytes' and 'name' descriptions of Container GET are
shared with Account GET. However, the descriptions are not correct for
Container GET.
This patch separate descriptions for Container GET and descriptions for Account
GET and fix descriptions for Container GET.
Change-Id: Ibedd08c5d9ebe145caf567edbd9757d7bc83b96d
While Donagh was kind enough to add Destination-Account in the related
change, we still hadn't documented the PUT-with-X-Copy-From equivalent.
Change-Id: I156ae2d8664873d3f6cc1f742bf950913fd462b0
Related-Change: I315b4e550b7d10880fbc00fce9311127ba609c2d
Closes-Bug: 1367975
With this commit, the tempurl middleware accepts (besides
the traditional unix timestamps) also timestamps according
to the format '%Y-%m-%dT%H:%M:%SZ' (one acceptable form of ISO 8601).
The idea is to make the tempurls more user-friendly,
and has been formulated here:
Change-Id: I346a0241060a9559d178b30e60c957792bbeb9f0
Implements: blueprint human-readable-tempurl-timestamp
With a multipart-manifest PUT request, if client sends the md5 of the
segments' etags, a 422 Unprocessable Entity response is returned. This
patch fixes that and confirms the etag
Change-Id: I4598a2a3f16ca8727bb07bbb6d8efcfcae777796
Closes-Bug: #1213200
Co-Authored-By: Tim Burke <tim@swiftstack.com>
Currently, conditional headers, e.g. If-Match, If-Modified-Since, etc.,
are listed for the GET objects API call, but not in the HEAD objects
call in the api-ref documentation. This patch adds the missing headers
to the HEAD documentation.
Change-Id: Idd1c248cc27415d148a1b9a5eb2e95f25b8c4da0
Closes-Bug: #1630212
Documents the syntax and meaning of container ACLs. Account ACLs
were already pretty well documented. However the account
ACL text was moved as part of this change.
TempAuth and keystoneauth have diffent ACLs. However, I decided
to describe both in one section/table because there are many
"examples" of ACLs in other documents, and it's better that
someone coming here from those sources become aware that the
specific ACL might not apply to them. In addition, the
referrer and .rlistings is common to both.
Some changes were also made to the api-ref document. The doc
and api-ref documents are published as seperate documents, so
the cross references from the api-ref section will not work
until this patch merges and the documents are rebuilt.
Change-Id: Icd2d6c278050c263b833ae76545c041f54fae68d
Many other OpenStack services use a `[X-]OpenStack-Request-Id` header
to return a unique identifier for the request. Swift will now return
`X-Trans-Id` as well as `X-Openstack-Request-Id`.
Change-Id: I56cd4738808b99c0a08463f83c100be51a62db05
Closes-Bug: #1572786
Now, instead of saying
X-Versions-Location: <container>
X-Versions-Mode: history
clients should just say
X-History-Location: <container>
Since we've never had a release featuring a user-settable
X-Versions-Mode header, support may be dropped and that is now ignored.
Change-Id: Icfd0f481d4e40dd5375c737190aea7ee8dbc3bf9
Clarify Content-Type header definition for listings.
Distinguish between request and response definitions for
X-Account-Meta-Temp-URL-Key* headers.
Insert X-Container-Meta-Quota-* headers missing from some
request/response definitions.
Improve X-Container-Meta-Access-Control-Expose-Headers
parameter formatting.
Distinguish between request and response definitions for
X-Container-Meta-Temp-URL-Key* headers.
Co-Authored-By: Christian Schwede <cschwede@redhat.com>
Change-Id: I8fc7610395973b520aa9ddd72c94e1eb75f602cd
Related-Change: I315b4e550b7d10880fbc00fce9311127ba609c2d
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
