Make the volume API simple/standard #14

Activity

1. ctengel commented on Aug 21, 2025

   

   ctengel

   on Aug 21, 2025

   OwnerAuthor

   More actions

   As we do enhancements #2 #4 #8 around node status, disk free, metadata we want to have this
2. ctengel

   added this to the Basic milestone on Aug 21, 2025
3. ctengel

   self-assigned this

   on Aug 21, 2025
4. ctengel

   pinned this issue on Aug 21, 2025
5. ctengel commented on Aug 24, 2025

   

   ctengel

   on Aug 24, 2025

   OwnerAuthor

   More actions

   emulating webdav LISTPROP is pointless

   S3 ListObjects we are already not far off from (already using size for instance) Main things to add would be checksum and mime type

   there should be a single status endpoint with

   • status - readonly, readwrite, notready (i.e. coming online, or still processing old requests, send no new requests)
   • volume size
   • volume free

   (these not covered by S3; per WebDAV we could use quota-used-bytes and quota-available-bytes

   Other things on objects themselves will use standard HTTP headers:

   • Range
   • Content-Type
   • Content-Digest
   • Content-Length

   I think that's really it. It's not complicated; there's less in common with S3 and WebDAV than originally thought think main thing still left to do in this issue is put together an OpenAPI spec for the handful of endpoints we support:

   • GET /bucket
   • GET /bucket/object
   • PUT /bucket/object
   • GET /health

   The locator API is largely similar, mainly add info on number of replicas, and more 307s.... maybe add replicas: 1 to each volserve response.
6. ctengel

   unpinned this issue on Aug 24, 2025
7. ctengel

   pinned this issue on Jan 16, 2026
8. ctengel

   added 2 commits that reference this issue on May 15, 2026

   Add OpenAPI spec for standardized volume API (issue #14)

   ...

   3cf88eb

   Implement Phase 1: Add standard HTTP headers to object API

   ...

   0ec034b
9. ctengel commented on May 19, 2026

   

   ctengel

   on May 19, 2026

   OwnerAuthor

   More actions

   Do we want bucket listing (i.e. GET /)?
10. ctengel commented on May 19, 2026

    

    ctengel

    on May 19, 2026

    OwnerAuthor

    More actions

    While not an initial goal - unifying the locator and object server API into a single API spec would be ideal
11. ctengel commented on May 19, 2026

    

    ctengel

    on May 19, 2026

    OwnerAuthor

    More actions

    1. Download both autogenerated open apis
    2. Generalize, harmonize
    3. Get influence from PR
    4. Influence from standards
    5. Finalize
    6. Adjust code to match
12. ctengel

    added 3 commits that reference this issue on May 20, 2026

    Improvements to the OpenAPI spec

    ...

    12f8d68

    API standardization improvements, part of #14

    ...

    857aa53

    OpenAPI spec updates and WebDAV harmonization

    ...

    4fa2d88
13. ctengel commented on May 21, 2026

    

    ctengel

    on May 21, 2026

    OwnerAuthor

    More actions

    Lots of enhancements

    Security

    • Path traversal fix — new safe_path() resolves and rejects any object/bucket path escaping OBJECT_DIRECTORY.

    API behavior

    • Content-Length now optional on PUT (object server and locator); locator assumes 1 GiB when absent.
    • /health response renamed available → quota-available-bytes; added quota-used-bytes (RFC 4331). Breaking change.
    • GET / → 403 on both servers (bucket enumeration intentionally disabled).
    • HEAD /{bucket}/ added to the locator (200 / 404 / 503).
    • Directory entries in GET /{bucket}/ return "size": null instead of 0.
    • Length-mismatch on PUT now returns 400 and deletes the partial file (previously 500 + orphan file blocking the key).

    Docs & spec

    • New consolidated openapi.yaml (spec v0.3.0).
    • README — added "Client guidance" (redirects, Content-Length, digests, CORS) plus v0.2.0 and v0.3.0 breaking-change sections.

    Tests

    • New pytest suite (tests/test_object_server.py) covering digest headers, MIME detection, and the length-mismatch 400 path.

    closed via e2b8083 and its parents
14. ctengel

    closed this as completedon May 21, 2026
15. ctengel

    unpinned this issue on May 21, 2026