The date header contains the remote server's current time. That's not what we want. Instead, we want the last-modified value for the file being inspected with the [info] (or equivalent) request. Thanks to Andrew Trusty for finding, diagnosing, and suggesting a fix. And thanks to DreamObjects for "forgetting" to include a date header in their response to a HEAD of an object on occasion, that led us to find this. This should also improve --no-check-md5 cases where the timestamp is being checked, as we won't think that remote files have a timestamp of "now".
This way we can catch all all GET and POST calls as https://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectsinRequesterPaysBuckets.html indicates we should do. This also lets us [ls] an object in a requester-pays bucket which we couldn't do before.
…emote2remote: If there was failed copy, seq number was preserved but previously uploaded file number was forgotten, thus user could have faced an invalid indication like: 14/8 when there is 6 upload following 6 remote copy failures.
…are bytes, so unicodise them also)
…e start of the operation (reported by a status 200 but an "Error" root entry in the xml body) In addition, for the move, It is good to check for the CopyObject xml reply to see if it is a success. But, if there is a status of 200 and no "data" in response, don't fail. Other S3 server implementations use only status code and don't return any body when there is no error. References: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html http://doc.s3.amazonaws.com/proposals/copy.html
Suggested by Debian patches. This automatically escapes dashes and the word 'Cache-Control' in the generated manpage. There is still an instance where the word Cache-Control is getting split across newlines due to the 80-character limit, which it doesn't catch, but it doesn't break the formatting of the rest of the manpage. It just looks like 'Cache- Control' in the result (note the extra space after the dash). I'll live with that.