7a7677868d
In the object server's PUT, POST, and DELETE handlers, we use the request's X-Timestamp value for checking object expiration. In the GET and HEAD handlers, we use it if present, but default to the current time. That way, one can still use curl to make direct object GET or HEAD requests as before. If one object server's clock is ahead of the proxy server's clock for some reason, and a client makes a POST request to update X-Delete-At, then the skewed-time object server may refuse the new X-Delete-At value. In a cluster where two of the three replicas for an object live on the same time-skewed node, this can result in confusing behavior for clients. A client can make a POST request to update X-Delete-At, receive a 400, and then discover later that the X-Delete-At value was updated anyway, since one object server accepted the POST and replication spread the new metadata around. DELETE is somewhat less confusing. The client might get a spurious 404 in the above case, but the object will still be removed. For PUT, an object server with a slow clock might refuse to overwrite an object with an "older" one because it believes the on-disk object is newer than the current time. Change-Id: I10c28f97d4c6aca1d64bef3b93506cfbb50ade30
362 KiB
362 KiB