Swift3 (1.12) * Stop using client accessible header for cross-middleware communication - Older swift3 using common HTTP header to communicate with auth middleware for Swift. Now, the auth information is in wsgi env variable to prevent the header from being passed by clients. This change closes a significant bug. See https://bugs.launchpad.net/swift3/+bug/1561199 in detail. - Plus, improve the auth middleware pipeline communication to let the auth middleware just call check_signature func with the user's secret. UpgradeInpact: - If you're using tempauth, you need to upgrade your swift to later than 2.14.0. - If you're using custom authentication middleware, you have to modify your middleware to use auth information from wsgi environ variable. The reference change is https://github.com/openstack/swift/commit/f3ef616dc6a2c4987c952b31232fa3bbb5bc6801. * Various improvement for auth mechanism in s3_token - Following a pipeline change, only contact Keystone once per client request. - If ONLY using the S3 API, keystonemiddleware.auth_token is no longer required. - IPv6 format for keystone host is supported - http_timeout option and delay_auth_decision option are supported. Those options allows other auth middlewares to continue serving requests even when either Keystone is down or rejects the request. * ceph/s3api testing is supported as tox environment * Add minimum segment size option for multipart upload is supported in swift3 config * Fix some error response codes and messages to fit actual S3 response * Other minor bug fixes and various improvements Swift3 (1.11) * Amazon S3 Signature V4 support - To track newer authentication for Amazon Web service, Swift3 now supports Signature V4 authentication. Note that currently Signature V4 is available only with keystone authentication and >=9.0.0 keystone is required. * s3_token middleware migrated from keystonemiddleware repository - Following a discussion at OpenStack Austin Summit, the s3_token middleware has been migrated from keystonemiddlware to maintain in swift3. To use the newest maintained s3_token middleware, a few configuration changes in proxy-server.conf is needed. * Fix unexpected HTTP verb handling - Older swift3 is able to run any methods implemented in the controllers via HTTP verb. This fix limits the acceptable HTTP verbs to PUT, GET, HEAD, POST, and DELETE which are available at S3. * Delete segments bucket when the original bucket is deleted - To keep clean the swift environment, delete segment bucket and all segment objects in the bucket for multipart upload when the original bucket is deleted. * Copy Source Range support - Previously, we only supported copying complete objects for multipart uploads. Now we can optionally specify a single range to copy via x-amz-copy-source-range header. * swift3 version info available in /info * Other minor bug fixes and various improvements Swift3 (1.10) * Supported Python minimum version bumped to 2.7 * S3Timestamp to ensure the transaction timestamp in Swift3 - Sometimes Swift3 needs X-Timestamp value to show the request result to the client as the response body (e.g. copy result). However, older versions of swift3 don't have the way to decide the request timestamp. This stuff allows Swift3 to make its own timestamp when a request coming and supports a format which fits to S3 xml format. * Fix URL-encoded x-amz-copy-source - Fix a bug encoding again URL-encoded x-amz-copy-source. * Ignore Content-Type for Delete object request - A standard S3 client may set a header "Content-Type" into a DELETE request and it causes unexpected error in the backend pure Swift. To solve this, now swift3 drops the Content-Type header from the request only when it's a DELETE object request. * Other minor bug fixes and small improvements Swift3 (1.9) * Date Header fixes (closes CVE-2015-8466) - Older versions of swift3 allow requests without any date headers, making them vulnerable to replay attacks. Now swift3 forces incomming requests to have either valid Date header or valid x-amz-date header. * Response fixes - Now swift3 returns correct (same syntax with actual S3) response in following case: -- content-type in ErrorResponse -- Etag in BucketListing * Allow to delete segments, when the DELETE request is for slo - If the incomming DELETE request is to slo object, swift3 now attempt to query multipart-manifest=delete to delete whole segments in the manifest. This will achieve to clean up part objects for multipart upload. * Accept chunked transfer-encodings * Update supported version of Keystone * Move to new namespace (from stackforge to openstack) * Other minor bug fixes and small improvements Swift3 (1.8) * multi object deletion support - achieve the stuff in Swift3 and drop s3multi dependency off * multi object upload support - includes Initiate, Upload Part, Upload Part (copy), Abort, List (Uploads and Parts) * Swift 2.3.0 Support * x-amz-request-id is now transuction id in Swift * new ACL mechanism partially support Swift3 now has a couple of ACL scheme. One is a traditional scheme using native container ACL conpatible with backend Swift. The other is new scheme called 's3acl' that works as completely compatible with actual S3 ACLs. The new scheme is build espicially forcused on: - Single bucket namespace - Owner/Grant achievement - Object ACL support Note that the new scheme is still under development, so don't use it for production w/o enough testing. * logger improvement * review workflow changed - because Swift3 has joined to stackforge, use gerrit review instead of git hub pull request * test and package environment improvement - Add tox based test - pbr support - functional tests improvement - FakeSwift to simulate backend Swift - pylint support * Refactors - split controllers like as original Swift - create Swift3 request/response classes - add XML validation - add pipeline validation - ACL handlers for s3acl * A tons of bug fixes - Thanks guys for working this!! Swift3 (<1.7) * TODO (or skip to write down?) swift3 (0.5) * Initial separation release