The Content-SHA256 header of the POST example did not match the actual SHA-256 for the content. The signature was also generated with the bad SHA-256.
The signature for the response example did not match the expected result. (signing the base string with the secret key provided for the GET request, as it is quite clearly a response to that request)
Removed a number of occurrences of "GET or HEAD" and replaced with "Content-Length > 0". (or == 0, depending on context) While the official HTTP specification states that web servers may ignore bodies associated with GET requests, certain services - such as Elasticsearch and transitively Plexus - do process bodies for GET requests. The original "GET or HEAD" definition also curiously omitted OPTIONS and DELETE, neither of which are expected to have a body, in the same manner as GET and HEAD.
Clarified that the content length restriction in the base string only applies to ContentType and BodyHash. Originally, this confused me, as I interpreted that it pertained to Timestamp instead. In hindsight, it's logical, but it's better to avoid confusion.
For the recalculated signatures, I am perfectly liable to be wrong, and would be happy if this was pointed out.
For the recalculated signatures, I am perfectly liable to be wrong, and would be happy if this was pointed out.