Comment 10 for bug 1980954

Reviewed: https://review.opendev.org/c/openstack/swift/+/850782
Committed: https://opendev.org/openstack/swift/commit/e6ee372744de9855ac3bfe5dea0859c42ae85cc2
Submitter: "Zuul (22348)"
Branch: master

commit e6ee372744de9855ac3bfe5dea0859c42ae85cc2
Author: Tim Burke <email address hidden>
Date: Fri Jul 22 15:04:04 2022 -0700

    slo: Reduce overhead for 'Not an SLO manifest' responses

    When clients issue a ?multipart-manifest=delete request to non-SLOs, we
    try to fetch the manifest then drain and close the response upon seeing
    it wasn't actually an SLO manifest. This could previously cause the extra
    transfer (and discard) of several gigabytes of data.

    Now, add two extra headers to the request:

      * Range: bytes=-1
      * X-Backend-Ignore-Range-If-Metadata-Present: X-Static-Large-Object

    The first limits how much data we'll be discarding, while the second tells
    object servers to ignore the range header if it's an SLO manifest. Note
    that object-servers may still need to return more than one byte to the
    proxy -- an EC policy will require that we get a full fragment's worth
    from each server -- but at least we've got a better cap on our downside.

    Why one byte? Because range requests weren't designed to be able to
    return no data. Why the last byte (as opposed to the first)? Because
    bytes=0-0 will 416 on a zero-byte object, while bytes=-1 will 200.

    Note that the backend header was introduced in Swift 2.24.0 -- if we get
    a response from an older object-server, it may respect the Range header
    even though it's returning an SLO manifest. In that case, retry without
    either header.

    Related-Bug: #1980954
    Co-Authored-By: Romain de Joux <email address hidden>
    Change-Id: If3861e5b9c4f17ab3b82ea16673ddb29d07820a1