1 Pithos v2 Developer Guide
2 =========================
7 Pithos is a storage service implemented by GRNET (http://www.grnet.gr). Data is stored as objects, organized in containers, belonging to an account. This hierarchy of storage layers has been inspired by the OpenStack Object Storage (OOS) API and similar CloudFiles API by Rackspace. The Pithos API follows the OOS API as closely as possible. One of the design requirements has been to be able to use Pithos with clients built for the OOS, without changes.
9 However, to be able to take full advantage of the Pithos infrastructure, client software should be aware of the extensions that differentiate Pithos from OOS. Pithos objects can be updated, or appended to. Pithos will store sharing permissions per object and enforce corresponding authorization policies. Automatic version management, allows taking account and container listings back in time, as well as reading previous instances of objects.
11 The storage backend of Pithos is block oriented, permitting efficient, deduplicated data placement. The block structure of objects is exposed at the API layer, in order to encourage external software to implement advanced data management operations.
13 This document's goals are:
15 * Define the Pithos ReST API that allows the storage and retrieval of data and metadata via HTTP calls
16 * Specify metadata semantics and user interface guidelines for a common experience across client software implementations
18 The present document is meant to be read alongside the OOS API documentation. Thus, it is suggested that the reader is familiar with associated technologies, the OOS API as well as the first version of the Pithos API. This document refers to the second version of Pithos. Information on the first version of the storage API can be found at http://code.google.com/p/gss.
20 Whatever marked as to be determined (**TBD**), should not be considered by implementors.
25 ========================= ================================
27 ========================= ================================
28 0.7 (Oct 21, 2011) Suggest upload/download methods using hashmaps.
29 \ Propose syncing algorithm.
30 \ Support cross-account object copy and move.
31 \ Pass token as a request parameter when using ``POST`` via an HTML form.
32 \ Optionally use source account to update object from another object.
33 \ Use container ``POST`` to upload missing blocks of data.
34 \ Report policy in account headers.
35 \ Add insufficient quota reply.
36 0.6 (Sept 13, 2011) Reply with Merkle hash as the ETag when updating objects.
37 \ Include version id in object replace/change replies.
38 \ Change conflict (409) replies format to text.
39 \ Tags should be migrated to a meta value.
40 \ Container ``PUT`` updates metadata/policy.
41 \ Report allowed actions in shared object replies.
42 \ Provide ``https://hostname/login`` for Shibboleth authentication.
43 \ Use ``hashmap`` parameter in object ``GET``/``PUT`` to use hashmaps.
44 0.5 (July 22, 2011) Object update from another object's data.
45 \ Support object truncate.
46 \ Create object using a standard HTML form.
47 \ Purge container/object history.
48 \ List other accounts that share objects with a user.
49 \ List shared containers/objects.
50 \ Update implementation guidelines.
51 \ Check preconditions when creating/updating objects.
52 0.4 (July 01, 2011) Object permissions and account groups.
53 \ Control versioning behavior and container quotas with container policy directives.
54 \ Support updating/deleting individual metadata with ``POST``.
55 \ Create object using hashmap.
56 0.3 (June 14, 2011) Large object support with ``X-Object-Manifest``.
57 \ Allow for publicly available objects via ``https://hostname/public``.
58 \ Support time-variant account/container listings.
59 \ Add source version when duplicating with ``PUT``/``COPY``.
60 \ Request version in object ``HEAD``/``GET`` requests (list versions with ``GET``).
61 0.2 (May 31, 2011) Add object meta listing and filtering in containers.
62 \ Include underlying storage characteristics in container meta.
63 \ Support for partial object updates through ``POST``.
64 \ Expose object hashmaps through ``GET``.
65 \ Support for multi-range object ``GET`` requests.
66 0.1 (May 17, 2011) Initial release. Based on OpenStack Object Storage Developer Guide API v1 (Apr. 15, 2011).
67 ========================= ================================
69 Pithos Users and Authentication
70 -------------------------------
72 Pithos keeps separate databases for users and objects.
74 Each user is uniquely identified by the ``Uniq`` field. This should be used as the user's account in the API. The API uses the ``Token`` field to authenticate a user, thus allowing cross-account requests. All API requests require a token.
76 User entries can be modified/added via the management interface available at ``https://hostname/admin``.
78 Pithos is also compatible with Shibboleth (http://shibboleth.internet2.edu/). The connection between Shibboleth and Pithos is done by ``https://hostname/login``. An application that wishes to connect to Pithos, but does not have a token, should redirect the user to the login URI.
80 The login URI accepts the following parameters:
82 ====================== =========================
83 Request Parameter Name Value
84 ====================== =========================
85 next The URI to redirect to when the process is finished
86 renew Force token renewal (no value parameter)
87 ====================== =========================
89 The login process starts by redirecting the user to an external URI (controlled by Shibboleth), where the actual authentication credentials are entered. Then, the user is redirected back to the login URI from Shibboleth, with various identification information in the request headers.
91 If the user does not exist in the database, Pithos adds the user and creates a random token. If the user exists, the token has not expired and ``renew`` is not set, the existing token is reused. Finally, the login URI redirects to the URI provided with ``next``, adding the ``user`` and ``token`` parameters, which contain the ``Uniq`` and ``Token`` fields respectively.
96 The URI requests supported by the Pithos API follow one of the following forms:
98 * Top level: ``https://hostname/v1/``
99 * Account level: ``https://hostname/v1/<account>``
100 * Container level: ``https://hostname/v1/<account>/<container>``
101 * Object level: ``https://hostname/v1/<account>/<container>/<object>``
103 All requests must include an ``X-Auth-Token`` - as a header, or a parameter.
105 The allowable request operations and respective return codes per level are presented in the remainder of this chapter. Common to all requests are the following return codes.
107 ========================= ================================
108 Return Code Description
109 ========================= ================================
110 400 (Bad Request) The request is invalid
111 401 (Unauthorized) Missing or invalid token
112 403 (Forbidden) Request not allowed
113 404 (Not Found) The requested resource was not found
114 503 (Service Unavailable) The request cannot be completed because of an internal error
115 ========================= ================================
122 ========= ==================
123 Operation Description
124 ========= ==================
125 GET Authentication (for compatibility with the OOS API) or list allowed accounts
126 ========= ==================
131 If the ``X-Auth-User`` and ``X-Auth-Key`` headers are given, a dummy ``X-Auth-Token`` and ``X-Storage-Url`` will be replied, which can be used as a guest token/namespace for testing Pithos.
133 ================ =====================
134 Return Code Description
135 ================ =====================
136 204 (No Content) The request succeeded
137 ================ =====================
139 If an ``X-Auth-Token`` is already present, the operation will be interpreted as a request to list other accounts that share objects to the user.
141 ====================== =========================
142 Request Parameter Name Value
143 ====================== =========================
144 limit The amount of results requested (default is 10000)
145 marker Return containers with name lexicographically after marker
146 format Optional extended reply type (can be ``json`` or ``xml``)
147 ====================== =========================
149 The reply is a list of account names.
150 If a ``format=xml`` or ``format=json`` argument is given, extended information on the accounts will be returned, serialized in the chosen format.
151 For each account, the information will include the following (names will be in lower case and with hyphens replaced with underscores):
153 =========================== ============================
155 =========================== ============================
156 name The name of the account
157 last_modified The last account modification date (regardless of ``until``)
158 =========================== ============================
160 Example ``format=json`` reply:
164 [{"name": "user", "last_modified": "2011-07-19T10:48:16"}, ...]
166 Example ``format=xml`` reply:
170 <?xml version="1.0" encoding="UTF-8"?>
174 <last_modified>2011-07-19T10:48:16</last_modified>
176 <account>...</account>
179 =========================== =====================
180 Return Code Description
181 =========================== =====================
182 200 (OK) The request succeeded
183 204 (No Content) The user has no access to other accounts (only for non-extended replies)
184 =========================== =====================
186 Will use a ``200`` return code if the reply is of type json/xml.
193 ========= ==================
194 Operation Description
195 ========= ==================
196 HEAD Retrieve account metadata
198 POST Update account metadata
199 ========= ==================
204 ==================== ===========================
205 Request Header Name Value
206 ==================== ===========================
207 If-Modified-Since Retrieve if account has changed since provided timestamp
208 If-Unmodified-Since Retrieve if account has not changed since provided timestamp
209 ==================== ===========================
213 ====================== ===================================
214 Request Parameter Name Value
215 ====================== ===================================
216 until Optional timestamp
217 ====================== ===================================
219 Cross-user requests are not allowed to use ``until`` and only include the account modification date in the reply.
221 ========================== =====================
222 Reply Header Name Value
223 ========================== =====================
224 X-Account-Container-Count The total number of containers
225 X-Account-Bytes-Used The total number of bytes stored
226 X-Account-Until-Timestamp The last account modification date until the timestamp provided
227 X-Account-Group-* Optional user defined groups
228 X-Account-Policy-* Account behavior and limits
229 X-Account-Meta-* Optional user defined metadata
230 Last-Modified The last account modification date (regardless of ``until``)
231 ========================== =====================
235 ================ =====================
236 Return Code Description
237 ================ =====================
238 204 (No Content) The request succeeded
239 ================ =====================
245 ==================== ===========================
246 Request Header Name Value
247 ==================== ===========================
248 If-Modified-Since Retrieve if account has changed since provided timestamp
249 If-Unmodified-Since Retrieve if account has not changed since provided timestamp
250 ==================== ===========================
254 ====================== =========================
255 Request Parameter Name Value
256 ====================== =========================
257 limit The amount of results requested (default is 10000)
258 marker Return containers with name lexicographically after marker
259 format Optional extended reply type (can be ``json`` or ``xml``)
260 shared Show only shared containers (no value parameter)
261 until Optional timestamp
262 ====================== =========================
264 The reply is a list of container names. Account headers (as in a ``HEAD`` request) will also be included.
265 Cross-user requests are not allowed to use ``until`` and only include the account/container modification dates in the reply.
267 If a ``format=xml`` or ``format=json`` argument is given, extended information on the containers will be returned, serialized in the chosen format.
268 For each container, the information will include all container metadata (names will be in lower case and with hyphens replaced with underscores):
270 =========================== ============================
272 =========================== ============================
273 name The name of the container
274 count The number of objects inside the container
275 bytes The total size of the objects inside the container
276 last_modified The last container modification date (regardless of ``until``)
277 x_container_until_timestamp The last container modification date until the timestamp provided
278 x_container_policy_* Container behavior and limits
279 x_container_meta_* Optional user defined metadata
280 =========================== ============================
282 For examples of container details returned in JSON/XML formats refer to the OOS API documentation.
284 =========================== =====================
285 Return Code Description
286 =========================== =====================
287 200 (OK) The request succeeded
288 204 (No Content) The account has no containers (only for non-extended replies)
289 304 (Not Modified) The account has not been modified
290 412 (Precondition Failed) The condition set can not be satisfied
291 =========================== =====================
293 Will use a ``200`` return code if the reply is of type json/xml.
299 ==================== ===========================
300 Request Header Name Value
301 ==================== ===========================
302 X-Account-Group-* Optional user defined groups
303 X-Account-Meta-* Optional user defined metadata
304 ==================== ===========================
308 ====================== ============================================
309 Request Parameter Name Value
310 ====================== ============================================
311 update Do not replace metadata/groups (no value parameter)
312 ====================== ============================================
314 No reply content/headers.
316 The operation will overwrite all user defined metadata, except if ``update`` is defined.
317 To create a group, include an ``X-Account-Group-*`` header with the name in the key and a comma separated list of user names in the value. If no ``X-Account-Group-*`` header is present, no changes will be applied to groups. The ``update`` parameter also applies to groups. To delete a specific group, use ``update`` and an empty header value.
319 ================ ===============================
320 Return Code Description
321 ================ ===============================
322 202 (Accepted) The request has been accepted
323 ================ ===============================
331 ========= ============================
332 Operation Description
333 ========= ============================
334 HEAD Retrieve container metadata
336 PUT Create/update container
337 POST Update container metadata
338 DELETE Delete container
339 ========= ============================
345 ==================== ===========================
346 Request Header Name Value
347 ==================== ===========================
348 If-Modified-Since Retrieve if container has changed since provided timestamp
349 If-Unmodified-Since Retrieve if container has not changed since provided timestamp
350 ==================== ===========================
354 ====================== ===================================
355 Request Parameter Name Value
356 ====================== ===================================
357 until Optional timestamp
358 ====================== ===================================
360 Cross-user requests are not allowed to use ``until`` and only include the container modification date in the reply.
362 =========================== ===============================
363 Reply Header Name Value
364 =========================== ===============================
365 X-Container-Object-Count The total number of objects in the container
366 X-Container-Bytes-Used The total number of bytes of all objects stored
367 X-Container-Block-Size The block size used by the storage backend
368 X-Container-Block-Hash The hash algorithm used for block identifiers in object hashmaps
369 X-Container-Until-Timestamp The last container modification date until the timestamp provided
370 X-Container-Object-Meta A list with all meta keys used by objects (**TBD**)
371 X-Container-Policy-* Container behavior and limits
372 X-Container-Meta-* Optional user defined metadata
373 Last-Modified The last container modification date (regardless of ``until``)
374 =========================== ===============================
376 The keys returned in ``X-Container-Object-Meta`` are all the unique strings after the ``X-Object-Meta-`` prefix, formatted as a comma-separated list. See container ``PUT`` for a reference of policy directives. (**TBD**)
378 ================ ===============================
379 Return Code Description
380 ================ ===============================
381 204 (No Content) The request succeeded
382 ================ ===============================
388 ==================== ===========================
389 Request Header Name Value
390 ==================== ===========================
391 If-Modified-Since Retrieve if container has changed since provided timestamp
392 If-Unmodified-Since Retrieve if container has not changed since provided timestamp
393 ==================== ===========================
397 ====================== ===================================
398 Request Parameter Name Value
399 ====================== ===================================
400 limit The amount of results requested (default is 10000)
401 marker Return containers with name lexicographically after marker
402 prefix Return objects starting with prefix
403 delimiter Return objects up to the delimiter (discussion follows)
404 path Assume ``prefix=path`` and ``delimiter=/``
405 format Optional extended reply type (can be ``json`` or ``xml``)
406 meta Return objects having the specified meta keys (can be a comma separated list)
407 shared Show only shared objects (no value parameter)
408 until Optional timestamp
409 ====================== ===================================
411 The ``path`` parameter overrides ``prefix`` and ``delimiter``. When using ``path``, results will include objects ending in ``delimiter``.
413 The keys given with ``meta`` will be matched with the strings after the ``X-Object-Meta-`` prefix.
415 The reply is a list of object names. Container headers (as in a ``HEAD`` request) will also be included.
416 Cross-user requests are not allowed to use ``until`` and include the following limited set of headers in the reply:
418 =========================== ===============================
419 Reply Header Name Value
420 =========================== ===============================
421 X-Container-Block-Size The block size used by the storage backend
422 X-Container-Block-Hash The hash algorithm used for block identifiers in object hashmaps
423 X-Container-Object-Meta A list with all meta keys used by allowed objects (**TBD**)
424 Last-Modified The last container modification date
425 =========================== ===============================
427 If a ``format=xml`` or ``format=json`` argument is given, extended information on the objects will be returned, serialized in the chosen format.
428 For each object, the information will include all object metadata (names will be in lower case and with hyphens replaced with underscores):
430 ========================== ======================================
432 ========================== ======================================
433 name The name of the object
434 hash The ETag of the object
435 bytes The size of the object
436 content_type The MIME content type of the object
437 content_encoding The encoding of the object (optional)
438 content-disposition The presentation style of the object (optional)
439 last_modified The last object modification date (regardless of version)
440 x_object_version The object's version identifier
441 x_object_version_timestamp The object's version timestamp
442 x_object_modified_by The user that committed the object's version
443 x_object_manifest Object parts prefix in ``<container>/<object>`` form (optional)
444 x_object_sharing Object permissions (optional)
445 x_object_shared_by Object inheriting permissions (optional)
446 x_object_allowed_to Allowed actions on object (optional)
447 x_object_public Object's publicly accessible URI (optional)
448 x_object_meta_* Optional user defined metadata
449 ========================== ======================================
451 Extended replies may also include virtual directory markers in separate sections of the ``json`` or ``xml`` results.
452 Virtual directory markers are only included when ``delimiter`` is explicitly set. They correspond to the substrings up to and including the first occurrence of the delimiter.
453 In JSON results they appear as dictionaries with only a ``"subdir"`` key. In XML results they appear interleaved with ``<object>`` tags as ``<subdir name="..." />``.
454 In case there is an object with the same name as a virtual directory marker, the object will be returned.
456 For examples of object details returned in JSON/XML formats refer to the OOS API documentation.
458 =========================== ===============================
459 Return Code Description
460 =========================== ===============================
461 200 (OK) The request succeeded
462 204 (No Content) The account has no containers (only for non-extended replies)
463 304 (Not Modified) The container has not been modified
464 412 (Precondition Failed) The condition set can not be satisfied
465 =========================== ===============================
467 Will use a ``200`` return code if the reply is of type json/xml.
473 ==================== ================================
474 Request Header Name Value
475 ==================== ================================
476 X-Container-Policy-* Container behavior and limits
477 X-Container-Meta-* Optional user defined metadata
478 ==================== ================================
480 No reply content/headers.
482 If no policy is defined, the container will be created with the default values.
483 Available policy directives:
485 * ``versioning``: Set to ``auto``, ``manual`` or ``none`` (default is ``manual``)
486 * ``quota``: Size limit in KB (default is ``0`` - unlimited)
488 If the container already exists, the operation is equal to a ``POST`` with ``update`` defined.
490 ================ ===============================
491 Return Code Description
492 ================ ===============================
493 201 (Created) The container has been created
494 202 (Accepted) The request has been accepted
495 ================ ===============================
501 ==================== ================================
502 Request Header Name Value
503 ==================== ================================
504 Content-Length The size of the supplied data (optional, to upload)
505 Content-Type The MIME content type of the supplied data (optional, to upload)
506 Transfer-Encoding Set to ``chunked`` to specify incremental uploading (if used, ``Content-Length`` is ignored)
507 X-Container-Policy-* Container behavior and limits
508 X-Container-Meta-* Optional user defined metadata
509 ==================== ================================
513 ====================== ============================================
514 Request Parameter Name Value
515 ====================== ============================================
516 update Do not replace metadata/policy (no value parameter)
517 ====================== ============================================
519 No reply content/headers, except when uploading data, where the reply consists of a list of hashes for the blocks received (in a simple text format, with one hash per line).
521 The operation will overwrite all user defined metadata, except if ``update`` is defined.
522 To change policy, include an ``X-Container-Policy-*`` header with the name in the key. If no ``X-Container-Policy-*`` header is present, no changes will be applied to policy. The ``update`` parameter also applies to policy - deleted values will revert to defaults. To delete/revert a specific policy directive, use ``update`` and an empty header value. See container ``PUT`` for a reference of policy directives.
524 To upload blocks of data to the container, set ``Content-Type`` to ``application/octet-stream`` and ``Content-Length`` to a valid value (except if using ``chunked`` as the ``Transfer-Encoding``).
526 ================ ===============================
527 Return Code Description
528 ================ ===============================
529 202 (Accepted) The request has been accepted
530 ================ ===============================
536 ====================== ===================================
537 Request Parameter Name Value
538 ====================== ===================================
539 until Optional timestamp
540 ====================== ===================================
542 If ``until`` is defined, the container is "purged" up to that time (the history of all objects up to then is deleted).
544 No reply content/headers.
546 ================ ===============================
547 Return Code Description
548 ================ ===============================
549 204 (No Content) The request succeeded
550 409 (Conflict) The container is not empty
551 ================ ===============================
559 ========= =================================
560 Operation Description
561 ========= =================================
562 HEAD Retrieve object metadata
564 PUT Write object data or copy/move object
567 POST Update object metadata/data
569 ========= =================================
575 ==================== ================================
576 Request Header Name Value
577 ==================== ================================
578 If-Match Retrieve if ETags match
579 If-None-Match Retrieve if ETags don't match
580 If-Modified-Since Retrieve if object has changed since provided timestamp
581 If-Unmodified-Since Retrieve if object has not changed since provided timestamp
582 ==================== ================================
586 ====================== ===================================
587 Request Parameter Name Value
588 ====================== ===================================
589 version Optional version identifier
590 ====================== ===================================
594 ========================== ===============================
595 Reply Header Name Value
596 ========================== ===============================
597 ETag The ETag of the object
598 Content-Length The size of the object
599 Content-Type The MIME content type of the object
600 Last-Modified The last object modification date (regardless of version)
601 Content-Encoding The encoding of the object (optional)
602 Content-Disposition The presentation style of the object (optional)
603 X-Object-Version The object's version identifier
604 X-Object-Version-Timestamp The object's version timestamp
605 X-Object-Modified-By The user that comitted the object's version
606 X-Object-Manifest Object parts prefix in ``<container>/<object>`` form (optional)
607 X-Object-Sharing Object permissions (optional)
608 X-Object-Shared-By Object inheriting permissions (optional)
609 X-Object-Allowed-To Allowed actions on object (optional)
610 X-Object-Public Object's publicly accessible URI (optional)
611 X-Object-Meta-* Optional user defined metadata
612 ========================== ===============================
616 ================ ===============================
617 Return Code Description
618 ================ ===============================
619 200 (No Content) The request succeeded
620 ================ ===============================
626 ==================== ================================
627 Request Header Name Value
628 ==================== ================================
629 Range Optional range of data to retrieve
630 If-Range Retrieve the missing part if entity is unchanged; otherwise, retrieve the entire new entity (used together with Range header)
631 If-Match Retrieve if ETags match
632 If-None-Match Retrieve if ETags don't match
633 If-Modified-Since Retrieve if object has changed since provided timestamp
634 If-Unmodified-Since Retrieve if object has not changed since provided timestamp
635 ==================== ================================
639 ====================== ===================================
640 Request Parameter Name Value
641 ====================== ===================================
642 format Optional extended reply type (can be ``json`` or ``xml``)
643 hashmap Optional request for hashmap (no value parameter)
644 version Optional version identifier or ``list`` (specify a format if requesting a list)
645 ====================== ===================================
647 The reply is the object's data (or part of it), except if a hashmap is requested with ``hashmap``, or a version list with ``version=list`` (in both cases an extended reply format must be specified). Object headers (as in a ``HEAD`` request) are always included.
649 Hashmaps expose the underlying storage format of the object. Note that each hash is computed after trimming trailing null bytes of the corresponding block.
651 Example ``format=json`` reply:
655 {"block_hash": "sha1", "hashes": ["7295c41da03d7f916440b98e32c4a2a39351546c", ...], "block_size": 131072, "bytes": 242}
657 Example ``format=xml`` reply:
661 <?xml version="1.0" encoding="UTF-8"?>
662 <object name="file" bytes="24223726" block_size="131072" block_hash="sha1">
663 <hash>7295c41da03d7f916440b98e32c4a2a39351546c</hash>
667 Version lists include the version identifier and timestamp for each available object version. Version identifiers can be arbitrary strings, so use the timestamp to find newer versions.
669 Example ``format=json`` reply:
673 {"versions": [[23, 1307700892], [28, 1307700898], ...]}
675 Example ``format=xml`` reply:
679 <?xml version="1.0" encoding="UTF-8"?>
681 <version timestamp="1307700892">23</version>
682 <version timestamp="1307700898">28</version>
683 <version timestamp="...">...</version>
686 The ``Range`` header may include multiple ranges, as outlined in RFC2616. Then the ``Content-Type`` of the reply will be ``multipart/byteranges`` and each part will include a ``Content-Range`` header.
688 ========================== ===============================
689 Reply Header Name Value
690 ========================== ===============================
691 ETag The ETag of the object
692 Content-Length The size of the data returned
693 Content-Type The MIME content type of the object
694 Content-Range The range of data included (only on a single range request)
695 Last-Modified The last object modification date (regardless of version)
696 Content-Encoding The encoding of the object (optional)
697 Content-Disposition The presentation style of the object (optional)
698 X-Object-Version The object's version identifier
699 X-Object-Version-Timestamp The object's version timestamp
700 X-Object-Modified-By The user that comitted the object's version
701 X-Object-Manifest Object parts prefix in ``<container>/<object>`` form (optional)
702 X-Object-Sharing Object permissions (optional)
703 X-Object-Shared-By Object inheriting permissions (optional)
704 X-Object-Allowed-To Allowed actions on object (optional)
705 X-Object-Public Object's publicly accessible URI (optional)
706 X-Object-Meta-* Optional user defined metadata
707 ========================== ===============================
711 =========================== ==============================
712 Return Code Description
713 =========================== ==============================
714 200 (OK) The request succeeded
715 206 (Partial Content) The range request succeeded
716 304 (Not Modified) The object has not been modified
717 412 (Precondition Failed) The condition set can not be satisfied
718 416 (Range Not Satisfiable) The requested range is out of limits
719 =========================== ==============================
725 ==================== ================================
726 Request Header Name Value
727 ==================== ================================
728 If-Match Put if ETags match with current object
729 If-None-Match Put if ETags don't match with current object
730 ETag The MD5 hash of the object (optional to check written data)
731 Content-Length The size of the data written
732 Content-Type The MIME content type of the object
733 Transfer-Encoding Set to ``chunked`` to specify incremental uploading (if used, ``Content-Length`` is ignored)
734 X-Copy-From The source path in the form ``/<container>/<object>``
735 X-Move-From The source path in the form ``/<container>/<object>``
736 X-Source-Account The source account to copy/move from
737 X-Source-Version The source version to copy from
738 Content-Encoding The encoding of the object (optional)
739 Content-Disposition The presentation style of the object (optional)
740 X-Object-Manifest Object parts prefix in ``<container>/<object>`` form (optional)
741 X-Object-Sharing Object permissions (optional)
742 X-Object-Public Object is publicly accessible (optional)
743 X-Object-Meta-* Optional user defined metadata
744 ==================== ================================
748 ====================== ===================================
749 Request Parameter Name Value
750 ====================== ===================================
751 format Optional extended request type (can be ``json`` or ``xml``)
752 hashmap Optional hashmap provided instead of data (no value parameter)
753 ====================== ===================================
755 The request is the object's data (or part of it), except if a hashmap is provided (using ``hashmap`` and ``format`` parameters). If using a hashmap and all different parts are stored in the server, the object is created, otherwise the server returns Conflict (409) with the list of the missing parts (in a simple text format, with one hash per line).
757 Hashmaps should be formatted as outlined in ``GET``.
759 ========================== ===============================
760 Reply Header Name Value
761 ========================== ===============================
762 ETag The MD5 hash of the object (on create)
763 X-Object-Version The object's new version
764 ========================== ===============================
766 The ``X-Object-Sharing`` header may include either a ``read=...`` comma-separated user/group list, or a ``write=...`` comma-separated user/group list, or both separated by a semicolon (``;``). Groups are specified as ``<account>:<group>``. To publish the object, set ``X-Object-Public`` to ``true``. To unpublish, set to ``false``, or use an empty header value.
768 ============================== ==============================
769 Return Code Description
770 ============================== ==============================
771 201 (Created) The object has been created
772 409 (Conflict) The object can not be created from the provided hashmap, or there are conflicting permissions (a list of missing hashes, or a list of conflicting sharing paths will be included in the reply - in simple text format)
773 411 (Length Required) Missing ``Content-Length`` or ``Content-Type`` in the request
774 413 (Request Entity Too Large) Insufficient quota to complete the request
775 422 (Unprocessable Entity) The MD5 checksum of the data written to the storage system does not match the (optionally) supplied ETag value
776 ============================== ==============================
782 ==================== ================================
783 Request Header Name Value
784 ==================== ================================
785 If-Match Proceed if ETags match with object
786 If-None-Match Proceed if ETags don't match with object
787 Destination The destination path in the form ``/<container>/<object>``
788 Destination-Account The destination account to copy to
789 Content-Type The MIME content type of the object (optional)
790 Content-Encoding The encoding of the object (optional)
791 Content-Disposition The presentation style of the object (optional)
792 X-Source-Version The source version to copy from
793 X-Object-Manifest Object parts prefix in ``<container>/<object>`` form (optional)
794 X-Object-Sharing Object permissions (optional)
795 X-Object-Public Object is publicly accessible (optional)
796 X-Object-Meta-* Optional user defined metadata
797 ==================== ================================
799 Refer to ``PUT``/``POST`` for a description of request headers. Metadata is also copied, updated with any values defined. Sharing/publishing options are not copied.
801 ========================== ===============================
802 Reply Header Name Value
803 ========================== ===============================
804 X-Object-Version The object's new version
805 ========================== ===============================
809 ============================== ==============================
810 Return Code Description
811 ============================== ==============================
812 201 (Created) The object has been created
813 409 (Conflict) There are conflicting permissions (a list of conflicting sharing paths will be included in the reply - in simple text format)
814 413 (Request Entity Too Large) Insufficient quota to complete the request
815 ============================== ==============================
821 Same as ``COPY``, without the ``X-Source-Version`` request header. The ``MOVE`` operation is always applied on the latest version.
827 ==================== ================================
828 Request Header Name Value
829 ==================== ================================
830 If-Match Proceed if ETags match with object
831 If-None-Match Proceed if ETags don't match with object
832 Content-Length The size of the data written (optional, to update)
833 Content-Type The MIME content type of the object (optional, to update)
834 Content-Range The range of data supplied (optional, to update)
835 Transfer-Encoding Set to ``chunked`` to specify incremental uploading (if used, ``Content-Length`` is ignored)
836 Content-Encoding The encoding of the object (optional)
837 Content-Disposition The presentation style of the object (optional)
838 X-Source-Object Update with data from the object at path ``/<container>/<object>`` (optional, to update)
839 X-Source-Account The source account to update from
840 X-Source-Version The source version to update from (optional, to update)
841 X-Object-Bytes The updated object's final size (optional, when updating)
842 X-Object-Manifest Object parts prefix in ``<container>/<object>`` form (optional)
843 X-Object-Sharing Object permissions (optional)
844 X-Object-Public Object is publicly accessible (optional)
845 X-Object-Meta-* Optional user defined metadata
846 ==================== ================================
850 ====================== ============================================
851 Request Parameter Name Value
852 ====================== ============================================
853 update Do not replace metadata (no value parameter)
854 ====================== ============================================
856 The ``Content-Encoding``, ``Content-Disposition``, ``X-Object-Manifest`` and ``X-Object-Meta-*`` headers are considered to be user defined metadata. An operation without the ``update`` parameter will overwrite all previous values and remove any keys not supplied. When using ``update`` any metadata with an empty value will be deleted.
858 To change permissions, include an ``X-Object-Sharing`` header (as defined in ``PUT``). To publish, include an ``X-Object-Public`` header, with a value of ``true``. If no such headers are defined, no changes will be applied to sharing/public. Use empty values to remove permissions/unpublish (unpublishing also works with ``false`` as a header value). Sharing options are applied to the object - not its versions.
860 To update an object's data:
862 * Either set ``Content-Type`` to ``application/octet-stream``, or provide an object with ``X-Source-Object``. If ``Content-Type`` has some other value, it will be ignored and only the metadata will be updated.
863 * If the data is supplied in the request (using ``Content-Type`` instead of ``X-Source-Object``), a valid ``Content-Length`` header is required - except if using chunked transfers (set ``Transfer-Encoding`` to ``chunked``).
864 * Set ``Content-Range`` as specified in RFC2616, with the following differences:
866 * Client software MAY omit ``last-byte-pos`` of if the length of the range being transferred is unknown or difficult to determine.
867 * Client software SHOULD not specify the ``instance-length`` (use a ``*``), unless there is a reason for performing a size check at the server.
868 * If ``Content-Range`` used has a ``byte-range-resp-spec = *``, data will be appended to the object.
870 Optionally, truncate the updated object to the desired length with the ``X-Object-Bytes`` header.
872 A data update will trigger an ETag change. Updated ETags correspond to the single Merkle hash of the object's hashmap (refer to http://bittorrent.org/beps/bep_0030.html for more information).
874 No reply content. No reply headers if only metadata is updated.
876 ========================== ===============================
877 Reply Header Name Value
878 ========================== ===============================
879 ETag The new ETag of the object (data updated)
880 X-Object-Version The object's new version
881 ========================== ===============================
885 ============================== ==============================
886 Return Code Description
887 ============================== ==============================
888 202 (Accepted) The request has been accepted (not a data update)
889 204 (No Content) The request succeeded (data updated)
890 409 (Conflict) There are conflicting permissions (a list of conflicting sharing paths will be included in the reply - in simple text format)
891 411 (Length Required) Missing ``Content-Length`` in the request
892 413 (Request Entity Too Large) Insufficient quota to complete the request
893 416 (Range Not Satisfiable) The supplied range is invalid
894 ============================== ==============================
896 The ``POST`` method can also be used for creating an object via a standard HTML form. If the request ``Content-Type`` is ``multipart/form-data``, none of the above headers will be processed. The form should have an ``X-Object-Data`` field, as in the following example. The token is passed as a request parameter. ::
898 <form method="post" action="https://pithos.dev.grnet.gr/v1/user/folder/EXAMPLE.txt?X-Auth-Token=0000" enctype="multipart/form-data">
899 <input type="file" name="X-Object-Data">
900 <input type="submit">
903 This will create/override the object with the given name, as if using ``PUT``. The ``Content-Type`` of the object will be set to the value of the corresponding header sent in the part of the request containing the data (usually, automatically handled by the browser). Metadata, sharing and other object attributes can not be set this way.
905 ========================== ===============================
906 Reply Header Name Value
907 ========================== ===============================
908 ETag The MD5 hash of the object
909 X-Object-Version The object's new version
910 ========================== ===============================
914 ============================== ==============================
915 Return Code Description
916 ============================== ==============================
917 201 (Created) The object has been created
918 413 (Request Entity Too Large) Insufficient quota to complete the request
919 ============================== ==============================
925 ====================== ===================================
926 Request Parameter Name Value
927 ====================== ===================================
928 until Optional timestamp
929 ====================== ===================================
931 If ``until`` is defined, the object is "purged" up to that time (the history up to then is deleted).
933 No reply content/headers.
935 =========================== ==============================
936 Return Code Description
937 =========================== ==============================
938 204 (No Content) The request succeeded
939 =========================== ==============================
941 Sharing and Public Objects
942 ^^^^^^^^^^^^^^^^^^^^^^^^^^
944 Read and write control in Pithos is managed by setting appropriate permissions with the ``X-Object-Sharing`` header. The permissions are applied using prefix-based inheritance. Thus, each set of authorization directives is applied to all objects sharing the same prefix with the object where the corresponding ``X-Object-Sharing`` header is defined. For simplicity, nested/overlapping permissions are not allowed. Setting ``X-Object-Sharing`` will fail, if the object is already "covered", or another object with a longer common-prefix name already has permissions. When retrieving an object, the ``X-Object-Shared-By`` header reports where it gets its permissions from. If not present, the object is the actual source of authorization directives.
946 A user may ``GET`` another account or container. The result will include a limited reply, containing only the allowed containers or objects respectively. A top-level request with an authentication token, will return a list of allowed accounts, so the user can easily find out which other users share objects. The ``X-Object-Allowed-To`` header lists the actions allowed on an object, if it does not belong to the requesting user.
948 Objects that are marked as public, via the ``X-Object-Public`` meta, are also available at the corresponding URI returned for ``HEAD`` or ``GET``. Requests for public objects do not need to include an ``X-Auth-Token``. Pithos will ignore request parameters and only include the following headers in the reply (all ``X-Object-*`` meta is hidden):
950 ========================== ===============================
951 Reply Header Name Value
952 ========================== ===============================
953 ETag The ETag of the object
954 Content-Length The size of the data returned
955 Content-Type The MIME content type of the object
956 Content-Range The range of data included (only on a single range request)
957 Last-Modified The last object modification date (regardless of version)
958 Content-Encoding The encoding of the object (optional)
959 Content-Disposition The presentation style of the object (optional)
960 ========================== ===============================
962 Public objects are not included and do not influence cross-user listings. They are, however, readable by all users.
967 List of differences from the OOS API:
969 * Support for ``X-Account-Meta-*`` style headers at the account level. Use ``POST`` to update.
970 * Support for ``X-Container-Meta-*`` style headers at the container level. Can be set when creating via ``PUT``. Use ``POST`` to update.
971 * Header ``X-Container-Object-Meta`` at the container level and parameter ``meta`` in container listings. (**TBD**)
972 * Account and container policies to manage behavior and limits. Container behavior overrides account settings. Account quota sets the maximum bytes limit, regardless of container values.
973 * Headers ``X-Container-Block-*`` at the container level, exposing the underlying storage characteristics.
974 * All metadata replies, at all levels, include latest modification information.
975 * At all levels, a ``HEAD`` or ``GET`` request may use ``If-Modified-Since`` and ``If-Unmodified-Since`` headers.
976 * Container/object lists include all associated metadata if the reply is of type json/xml. Some names are kept to their OOS API equivalents for compatibility.
977 * Option to include only shared containers/objects in listings.
978 * Object metadata allowed, in addition to ``X-Object-Meta-*``: ``Content-Encoding``, ``Content-Disposition``, ``X-Object-Manifest``. These are all replaced with every update operation, except if using the ``update`` parameter (in which case individual keys can also be deleted). Deleting meta by providing empty values also works when copying/moving an object.
979 * Multi-range object ``GET`` support as outlined in RFC2616.
980 * Object hashmap retrieval through ``GET`` and the ``format`` parameter.
981 * Object create via hashmap through ``PUT`` and the ``format`` parameter.
982 * Object create using ``POST`` to support standard HTML forms.
983 * Partial object updates through ``POST``, using the ``Content-Length``, ``Content-Type``, ``Content-Range`` and ``Transfer-Encoding`` headers. Use another object's data to update with ``X-Source-Object`` and ``X-Source-Version``. Truncate with ``X-Object-Bytes``. New ETag corresponds to the Merkle hash of the object's hashmap.
984 * Include new version identifier in replies for object replace/change requests.
985 * Object ``MOVE`` support.
986 * Conditional object create/update operations, using ``If-Match`` and ``If-None-Match`` headers.
987 * Time-variant account/container listings via the ``until`` parameter.
988 * Object versions - parameter ``version`` in ``HEAD``/``GET`` (list versions with ``GET``), ``X-Object-Version-*`` meta in replies, ``X-Source-Version`` in ``PUT``/``COPY``.
989 * Sharing/publishing with ``X-Object-Sharing``, ``X-Object-Public`` at the object level. Cross-user operations are allowed - controlled by sharing directives. Available actions in cross-user requests are reported with ``X-Object-Allowed-To``. Permissions may include groups defined with ``X-Account-Group-*`` at the account level. These apply to the object - not its versions.
990 * Support for prefix-based inheritance when enforcing permissions. Parent object carrying the authorization directives is reported in ``X-Object-Shared-By``.
991 * Copy and move between accounts with ``X-Source-Account`` and ``Destination-Account`` headers.
992 * Large object support with ``X-Object-Manifest``.
993 * Trace the user that created/modified an object with ``X-Object-Modified-By``.
994 * Purge container/object history with the ``until`` parameter in ``DELETE``.
996 Clarifications/suggestions:
998 * Authentication is done by another system. The token is used in the same way, but it is obtained differently. The top level ``GET`` request is kept compatible with the OOS API and allows for guest/testing operations.
999 * Some processing is done in the variable part of all ``X-*-Meta-*`` headers. If it includes underscores, they will be converted to dashes and the first letter of all intra-dash strings will be capitalized.
1000 * A ``GET`` reply for a level will include all headers of the corresponding ``HEAD`` request.
1001 * To avoid conflicts between objects and virtual directory markers in container listings, it is recommended that object names do not end with the delimiter used.
1002 * The ``Accept`` header may be used in requests instead of the ``format`` parameter to specify the desired request/reply format. The parameter overrides the header.
1003 * Container/object lists use a ``200`` return code if the reply is of type json/xml. The reply will include an empty json/xml.
1004 * In headers, dates are formatted according to RFC 1123. In extended information listings, the ``last_modified`` field is formatted according to ISO 8601 (for OOS API compatibility). All other fields (Pithos extensions) use integer tiemstamps.
1005 * The ``Last-Modified`` header value always reflects the actual latest change timestamp, regardless of time control parameters and version requests. Time precondition checks with ``If-Modified-Since`` and ``If-Unmodified-Since`` headers are applied to this value.
1006 * A copy/move using ``PUT``/``COPY``/``MOVE`` will always update metadata, keeping all old values except the ones redefined in the request headers.
1007 * A ``HEAD`` or ``GET`` for an ``X-Object-Manifest`` object, will include modified ``Content-Length`` and ``ETag`` headers, according to the characteristics of the objects under the specified prefix. The ``Etag`` will be the MD5 hash of the corresponding ETags concatenated. In extended container listings there is no metadata processing.
1015 Hopefully this API will allow for a multitude of client implementations, each supporting a different device or operating system. All clients will be able to manipulate containers and objects - even software only designed for OOS API compatibility. But a Pithos interface should not be only about showing containers and folders. There are some extra user interface elements and functionalities that should be common to all implementations.
1017 Upon entrance to the service, a user is presented with the following elements - which can be represented as folders or with other related icons:
1019 * The ``home`` element, which is used as the default entry point to the user's "files". Objects under ``home`` are represented in the usual hierarchical organization of folders and files.
1020 * The ``trash`` element, which contains files that have been marked for deletion, but can still be recovered.
1021 * The ``shared`` element, which contains all objects shared by the user to other users of the system.
1022 * The ``others`` element, which contains all objects that other users share with the user.
1023 * The ``groups`` element, which contains the names of groups the user has defined. Each group consists of a user list. Group creation, deletion, and manipulation is carried out by actions originating here.
1024 * The ``history`` element, which allows browsing past instances of ``home`` and - optionally - ``trash``.
1026 Objects in Pithos can be:
1028 * Moved to trash and then deleted.
1029 * Shared with specific permissions.
1030 * Made public (shared with non-Pithos users).
1031 * Restored from previous versions.
1033 Some of these functions are performed by the client software and some by the Pithos server.
1035 In the first version of Pithos, objects could also be assigned custom tags. This is no longer supported. Existing deployments can migrate tags into a specific metadata value, i.e. ``X-Object-Meta-Tags``.
1037 Implementation Guidelines
1038 ^^^^^^^^^^^^^^^^^^^^^^^^^
1040 Pithos clients should use the ``pithos`` and ``trash`` containers for active and inactive objects respectively. If any of these containers is not found, the client software should create it, without interrupting the user's workflow. The ``home`` element corresponds to ``pithos`` and the ``trash`` element to ``trash``. Use ``PUT`` with the ``X-Move-From`` header, or ``MOVE`` to transfer objects from one container to the other. Use ``DELETE`` to remove from ``pithos`` without trashing, or to remove from ``trash``. When moving objects, detect naming conflicts with the ``If-Match`` or ``If-None-Match`` headers. Such conflicts should be resolved by the user.
1042 Object names should use the ``/`` delimiter to impose a hierarchy of folders and files.
1044 The ``shared`` element should be implemented as a read-only view of the ``pithos`` container, using the ``shared`` parameter when listing objects. The ``others`` element, should start with a top-level ``GET`` to retrieve the list of accounts accessible to the user. It is suggested that the client software hides the next step of navigation - the container - if it only includes ``pithos`` and forwards the user directly to the objects.
1046 Public objects are not included in ``shared`` and ``others`` listings. It is suggested that they are marked in a visually distinctive way in ``pithos`` listings (for example using an icon overlay).
1048 A special application menu, or a section in application preferences, should be devoted to managing groups (the ``groups`` element). All group-related actions are implemented at the account level.
1050 Browsing past versions of objects should be available both at the object and the container level. At the object level, a list of past versions can be included in the screen showing details or more information on the object (metadata, permissions, etc.). At the container level, it is suggested that clients use a ``history`` element, which presents to the user a read-only, time-variable view of ``pithos`` contents. This can be accomplished via the ``until`` parameter in listings. Optionally, ``history`` may include ``trash``.
1052 Uploading and downloading data
1053 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1055 By using hashmaps to upload and download objects the corresponding operations can complete much faster.
1057 In the case of an upload, only the missing blocks will be submitted to the server:
1059 * Calculate the hash value for each block of the object to be uploaded. Use the hash algorithm and block size of the destination container.
1060 * Send a hashmap ``PUT`` request for the object.
1062 * Server responds with status ``201`` (Created):
1064 * Blocks are already on the server. The object has been created. Done.
1066 * Server responds with status ``409`` (Conflict):
1068 * Server's response body contains the hashes of the blocks that do not exist on the server.
1069 * For each hash value in the server's response (or all hashes together):
1071 * Send a ``POST`` request to the destination container with the corresponding data.
1073 * Repeat hashmap ``PUT``. Fail if the server's response is not ``201``.
1075 Consulting hashmaps when downloading allows for resuming partially transferred objects. The client should retrieve the hashmap from the server and compare it with the hashmap computed from the respective local file. Any missing parts can be downloaded with ``GET`` requests with the additional ``Range`` header.
1080 Consider the following algorithm for synchronizing a local folder with the server. The "state" is the complete object listing, with the corresponding attributes.
1084 L: local state (stored state from last sync with the server)
1085 C: current state (state computed right before sync)
1091 # No remote changes, nothing to do
1093 # Update local state to match that of the server
1096 # We have local changes
1098 # No remote changes, update the server
1102 # Both we and server have changes
1104 # We were lucky, we did the same change
1107 # We have conflicting changes
1112 * States represent file hashes (either MD5 or Merkle). Deleted or non-existing files are assumed to have a magic hash (e.g. empty string).
1113 * Updating a state (either local or remote) implies downloading, uploading or deleting the appropriate file.
1115 Recommended Practices and Examples
1116 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1118 Assuming an authentication token is obtained, the following high-level operations are available - shown with ``curl``:
1120 * Get account information ::
1123 -H "X-Auth-Token: 0000" \
1124 https://pithos.dev.grnet.gr/v1/user
1126 * List available containers ::
1129 -H "X-Auth-Token: 0000" \
1130 https://pithos.dev.grnet.gr/v1/user
1132 * Get container information ::
1135 -H "X-Auth-Token: 0000" \
1136 https://pithos.dev.grnet.gr/v1/user/pithos
1138 * Add a new container ::
1141 -H "X-Auth-Token: 0000" \
1142 https://pithos.dev.grnet.gr/v1/user/test
1144 * Delete a container ::
1146 curl -X DELETE -D - \
1147 -H "X-Auth-Token: 0000" \
1148 https://pithos.dev.grnet.gr/v1/user/test
1150 * List objects in a container ::
1153 -H "X-Auth-Token: 0000" \
1154 https://pithos.dev.grnet.gr/v1/user/pithos
1156 * List objects in a container (extended reply) ::
1159 -H "X-Auth-Token: 0000" \
1160 https://pithos.dev.grnet.gr/v1/user/pithos?format=json
1162 It is recommended that extended replies are cached and subsequent requests utilize the ``If-Modified-Since`` header.
1164 * List metadata keys used by objects in a container
1166 Will be in the ``X-Container-Object-Meta`` reply header, included in container information or object list (``HEAD`` or ``GET``). (**TBD**)
1168 * List objects in a container having a specific meta defined ::
1171 -H "X-Auth-Token: 0000" \
1172 https://pithos.dev.grnet.gr/v1/user/pithos?meta=favorites
1174 * Retrieve an object ::
1177 -H "X-Auth-Token: 0000" \
1178 https://pithos.dev.grnet.gr/v1/user/pithos/README.txt
1180 * Retrieve an object (specific ranges of data) ::
1183 -H "X-Auth-Token: 0000" \
1184 -H "Range: bytes=0-9" \
1185 https://pithos.dev.grnet.gr/v1/user/pithos/README.txt
1187 This will return the first 10 bytes. To get the first 10, bytes 30-39 and the last 100 use ``Range: bytes=0-9,30-39,-100``.
1189 * Add a new object (folder type) (**TBD**) ::
1192 -H "X-Auth-Token: 0000" \
1193 -H "Content-Type: application/folder" \
1194 https://pithos.dev.grnet.gr/v1/user/pithos/folder
1196 * Add a new object ::
1199 -H "X-Auth-Token: 0000" \
1200 -H "Content-Type: text/plain" \
1202 https://pithos.dev.grnet.gr/v1/user/pithos/folder/EXAMPLE.txt
1204 * Update an object ::
1207 -H "X-Auth-Token: 0000" \
1208 -H "Content-Length: 10" \
1209 -H "Content-Type: application/octet-stream" \
1210 -H "Content-Range: bytes 10-19/*" \
1212 https://pithos.dev.grnet.gr/v1/user/folder/EXAMPLE.txt
1214 This will update bytes 10-19 with the data specified.
1216 * Update an object (append) ::
1219 -H "X-Auth-Token: 0000" \
1220 -H "Content-Length: 10" \
1221 -H "Content-Type: application/octet-stream" \
1222 -H "Content-Range: bytes */*" \
1224 https://pithos.dev.grnet.gr/v1/user/folder/EXAMPLE.txt
1226 * Update an object (truncate) ::
1229 -H "X-Auth-Token: 0000" \
1230 -H "X-Source-Object: /folder/EXAMPLE.txt" \
1231 -H "Content-Range: bytes 0-0/*" \
1232 -H "X-Object-Bytes: 0" \
1233 https://pithos.dev.grnet.gr/v1/user/folder/EXAMPLE.txt
1235 This will truncate the object to 0 bytes.
1237 * Add object metadata ::
1240 -H "X-Auth-Token: 0000" \
1241 -H "X-Object-Meta-First: first_meta_value" \
1242 -H "X-Object-Meta-Second: second_meta_value" \
1243 https://pithos.dev.grnet.gr/v1/user/folder/EXAMPLE.txt
1245 * Delete object metadata ::
1248 -H "X-Auth-Token: 0000" \
1249 -H "X-Object-Meta-First: first_meta_value" \
1250 https://pithos.dev.grnet.gr/v1/user/folder/EXAMPLE.txt
1252 Metadata can only be "set". To delete ``X-Object-Meta-Second``, reset all metadata.
1254 * Delete an object ::
1256 curl -X DELETE -D - \
1257 -H "X-Auth-Token: 0000" \
1258 https://pithos.dev.grnet.gr/v1/user/folder/EXAMPLE.txt
projects / pithos / blob