As also stated inside the documentation: “any successful request could lead to a 307 Temporary Redirect response.”
This is done for performance reasons: redirecting the client to the node which holds the requested blob file or is responsible for storing the uploading blob file. Blob files are shard the same way like normal records,
with the limitation that blob files as a whole are stored on a concrete node (it’s content is not chunked and split across the cluster).
To avoid streaming possible large content through the connected node (aka. handler node), we return a 307 redirect header to let the client directly connect to the node holding the file or is responsible for storing the file. This sharding logic is done using the blob’s sha1 digest digest and the number of data nodes N by simply running: digest % N = <TARGET_NODE> .
For historical reasons, the check if a blob digest really exists, happens only after the redirect on the node responsible for the concrete blob file.
We could check this earlier nowadays (as we store the digests also inside a lucene index), please file a feature request on our github repository if needed.
This should not happen for DELETE (as here no possible large data is sent), but only for GET, PUT or HEAD requests.
In your example I do not see any DELETE request being redirected. If this is really the case, this would be a bug.