SLO does not validate submanifests on read

[Tim Burke]

Create some segment data:

$ curl http://saio:8090/v1/AUTH_test/c/x -X PUT -d 123
$ curl http://saio:8090/v1/AUTH_test/c/y -X PUT -d 456
$ curl http://saio:8090/v1/AUTH_test/c/z -X PUT -d 789

Create a manifest:

$ curl http://saio:8090/v1/AUTH_test/c/xy?multipart-manifest=put -X PUT -d '[{"path":"c/x"},{"path":"c/y"}]'

...that gets referenced by another manifest:

$ curl http://saio:8090/v1/AUTH_test/c/xyz?multipart-manifest=put -X PUT -d '[{"path":"c/xy"},{"path":"c/z"}]'

Note that despite the client sending only the path, the size and etag information *did* get recorded in the manifest, and we expect that to be used for validation on read:

$ curl -s http://saio:8090/v1/AUTH_test/c/xy?multipart-manifest=get | python -m json.tool
[
    {
        "name": "/c/x",
        "bytes": 3,
        "hash": "202cb962ac59075b964b07152d234b70",
        "content_type": "application/x-www-form-urlencoded",
        "last_modified": "2023-09-28T15:40:41.000000"
    },
    {
        "name": "/c/y",
        "bytes": 3,
        "hash": "250cf8b51c773f3f8dc8b4be867a9a02",
        "content_type": "application/x-www-form-urlencoded",
        "last_modified": "2023-09-28T15:40:46.000000"
    }
]
$ curl -I http://saio:8090/v1/AUTH_test/c/xy
HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
X-Static-Large-Object: True
Etag: "79e3c0c96e5d7ccac5763c4f49bfb98d"
Last-Modified: Thu, 28 Sep 2023 15:41:48 GMT
X-Timestamp: 1695915707.36800
Accept-Ranges: bytes
X-Manifest-Etag: 2edc64e9befdc6c8424abfac3bef0253
X-Trans-Id: tx9f619a7af3f348b68e92e-0065159f69
X-Openstack-Request-Id: tx9f619a7af3f348b68e92e-0065159f69
Date: Thu, 28 Sep 2023 15:44:41 GMT

$ curl -s http://saio:8090/v1/AUTH_test/c/xyz?multipart-manifest=get | python -m json.tool
[
    {
        "name": "/c/xy",
        "bytes": 6,
        "hash": "79e3c0c96e5d7ccac5763c4f49bfb98d",
        "content_type": "application/x-www-form-urlencoded",
        "last_modified": "2023-09-28T15:41:48.000000",
        "sub_slo": true
    },
    {
        "name": "/c/z",
        "bytes": 3,
        "hash": "68053af2923e00204c3ca7c6a3150cf7",
        "content_type": "application/x-www-form-urlencoded",
        "last_modified": "2023-09-28T15:40:51.000000"
    }
]

But it isn't! If you overwrite the referenced manifest

$ curl http://saio:8090/v1/AUTH_test/c/xy?multipart-manifest=put -X PUT -d '[{"path":"c/z"},{"path":"c/z"}]'

The subsequent GET sends the new data, and there's no indication that it's been modified from the original upload!

$ curl http://saio:8090/v1/AUTH_test/c/xyz
789789789

The expectation is that client should have gotten a 409, similar to what would happen in other cases where the backing data for an SLO has changed.

[Tim Burke (1-tim-z)]

Ugh -- looks like between 1.9.1 (which introduced the ability to have sub-SLOs) and 1.12.0 (specifically, https://github.com/openstack/swift/commit/19017195) Swift would write down sub-SLOs with the manifest's ETag / Content-Length -- so any fix ought to make sure those are still readable.