User bio
404 bio not found
Member since Sep 26, 2018
Posts:
Joe has not published any posts yet.
Replies:
show all 5
Joe Boykin · Jan 28, 2019 go to post

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

Joe Boykin · Jan 17, 2019 go to post

Hi Eduard,

I came across this post from 2 years ago when trying to work out the simplest way to get current RFC 822/1123 HTTP-Date values from current timestamps for a request header value (eg the %Net.HttpRequest 'Date' property) in something I'm working on.
At the risk of telling you something you've found out elsewhere since then, it turns out there's already a classmethod that will output this (in GMT) from $horolog (or any $horolog-style ddddd,sssss value, with the assumption it's in local time/date):

write ##class(%CSP.StreamServer).ToHTTPDate($horolog)
>Fri, 18 Jan 2019 04:09:44 GMT

write $zdatetime($horolog,2)
>18 Jan 2019 15:09:44  //AEST timestamp

The Documatic details are here.

Cheers

Joe

Certifications & Credly badges:
Joe has no Certifications & Credly badges yet.
Followers:
Joe has no followers yet.
Following:
Joe has not followed anybody yet.