Hey Dave,

I encountered similar issues with 'text/*' ( text/plain, text/csv, etc) Content-Type header values when I included them in the v4 signed canonical request, and found (in my case) that this is due to Caché appending the charset based on the instance's localization settings (string "; charset=UTF-8") for this header value, eg "Content-Type=text/csv; charset=UTF-8". That likely means you're passing "text/csv" into your signing algorithm to derive your signature but the actual request you're sending has "text/csv; charset=UTF-8", hence the signature failure on the AWS end.

As per this doc,

• The ContentCharset property controls the desired character set for any content of the request if the content is of type text (text/html or text/xml for example). If you do not specify this property, Caché uses the default encoding of the Caché server.

  Note:

  If you set this property, you must first set the ContentType property.

• The NoDefaultContentCharset property controls whether to include an explicit character set for content of type text if you have not set the ContentCharset property. By default, this property is false.

Since this isn't one of the headers that needs to be included in AWS v4 signing for the authorisation header,  I just removed this from the list to sign (while still passing it in the actual HTTP request) so I could retain the default charset without too much fuss (I'm not too worried about an attack here, since I'm signing payloads), but the other options (as far as I can tell) would be to pass the same full string to your signing function (including the charset), or prevent charset from being included in Content-Type via that NoDefaultContentCharset property.

Cheers

Joe

I'd like to join, Evgeny. Thanks.