Curly quotes(Chinese punctuation) usually input from Chinese input method.
When read from english context, it makes some confusion.
Change-Id: Ibd50299ee287c56ec4759ea8ff53d47d006144f8
The pointer to using COPY to the same object as a mechanism to set only
a subset of the metadata, it does not mention that doing so results in
a full copy of the object in question on the backend.
Add a note so it's clear that there is a tradeoff involved.
Change-Id: I0c20a4909a6c3ff672f753d26cb9fb2f5f33d1f4
From openstackdocstheme 1.18.0, valid Git URLs can be retrieved by
openstackdocstheme[1], we do not need giturl option anymore.
[1] https://review.openstack.org/532163
Change-Id: I579cebae6486d250915f936f0c1c61008471c089
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, 'Content-Type' header key name is used in response
parameter tables except Container GET table. On the other hand, 'Content_Type'
is used in Container GET table.
This patch fixes the 'Content_Type' in Container GET table to 'Content-Type'.
Change-Id: Idf242477dd089202635b69b85b0c19739e0c6321
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
Also removed a bunch of unnecessary unquotes. Just use path_info
instead (it's already unquoted).
Partial-Bug: #1670915
Change-Id: If1af43485b4708cab6c4b5d7f6f0a334d8752518
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
For now, last modified timestamp is supported only on
object listing. (i.e. GET container)
For example:
GET container with json format results in like as:
[{"hash": "d41d8cd98f00b204e9800998ecf8427e", "last_modified":
"2015-06-10T04:58:23.460230", "bytes": 0, "name": "object",
"content_type": "application/octet-stream"}]
However, container listing (i.e. GET account) shows just a dict
consists of ("name", "bytes", "name") for each container.
For example:
GET accounts with json format result in like as:
[{"count": 0, "bytes": 0, "name": "container"}]
This patch is for supporting last_modified key in the container
listing results as well as object listing like as:
[{"count": 0, "bytes": 0, "name": "container", "last_modified":
"2015-06-10T04:58:23.460230"}]
This patch is changing just output for listing. The original
timestamp to show the last modified is already in container table
of account.db as a "put_timestamp" column.
Note that this patch *DOESN'T* change the put_timestamp semantics.
i.e. the last_modified timestamp will be changed only at both PUT
container and POST container.
(PUT object doesn't affect the timestamp)
Note that the tuple format of returning value from
swift.account.backend.AccountBroker.list_containers is now
(name, object_count, bytes_used, put_timestamp, 0)
* put_timestamp is added *
Original discussion was in working session at Vancouver Summit.
Etherpads are around here:
https://etherpad.openstack.org/p/liberty-swift-contributors-meetuphttps://etherpad.openstack.org/p/liberty-container-listing-update
DocImpact
Change-Id: Iba0503916f1481a20c59ae9136436f40183e4c5b
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
Swift returns `X-Openstack-Request-Id` for container and
object requests as well as account. A couple api-ref docs are
missing this value in the response examples.
Change-Id: Ifcd67a620e04be5e92b43c7749ee4acb50bb171d
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
The os-api-ref 1.0.0 is out. We can remove the support to older version now.
Reference:
6d41feb58d
Change-Id: I0b28cd3f6b5c393d63b9ab2b4dcd3b7b3c20f9b4
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
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
Move the account listing sample responses to follow the sample
requests, and to precede the request/response parameter definitions to
be consistent with other parts of the doc.
Related-Change: I315b4e550b7d10880fbc00fce9311127ba609c2d
Change-Id: Ia20acacd238db4a423b8cd89af1658222b4c5828
Move repeated test re metadata header syntax to an include
file and make it be rendered as a note.
Also make already included text about metadata header value
encoding be a note.
Change-Id: I4795836587492954ad24dd5baaa5d668746d6040
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
Currently, Swift api-ref is not configured with logABug feature.
When users click "Report bug" button, it leads to "openstack-manuals"
which is default.
Change-Id: I3b6fb410000637ff03d99110d440de88a5adc30c
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