SLO can erroneously respond with 416
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Fix Released
|
Medium
|
Tim Burke |
Bug Description
When the client does a ranged request or conditional request for an SLO, the first response from the object server likely isn't the correct one. As a result, SLO may need to go refetch the manifest to determine the correct response [1].
However, this second read may not match the first, for a variety of reasons:
- The initial response may have had stale data and the subsequent one newer, in which case we ought to act on the newer data (or tombstone).
- The initial response may have been new but the subsequent one stale; 503 seems best.
- The initial response may have been good but the subsequent one failed, either returning 404 from a handoff or 503 after running out of handoffs; 503 is appropriate.
Instead, currently, we never check the GET response [2], so we try to interpret whatever we got as JSON [3]. This likely fails, leading us to think the manifest is empty (!?). As a result, a ranged request (for example) will 416.
[1] https:/
[2] https:/
[3] https:/
Fix proposed to branch: master /review. opendev. org/671882
Review: https:/