Chilkat 16-Dec-2021 — idToken HTTP Header
What’s going on w/ Chilkat support today…
1. Long HTTP request headers present a difficulty because some web servers choke on header fields that are too long and require folding, whereas others choke on folded headers. Given that HTTP requests are MIME, and the request/response headers are MIME headers, header folding follows the MIME specification. Folding SHOULD occur at whitespace. However, in certain long headers, such as ID tokens or base64 access tokens, there is no whitespace. Thus Chilkat uses “B” encoding to properly encode. So you may see a header field like this:
idToken: ?utf-8?B?....= =?utf-8?B?...= =?utf-8?B?...=
It was a mistake to fold the idToken and Authorization header fields because the servers that process these header fields choke on the folding. (Apparently, it’s too much to ask for a server to properly implement the MIME and HTTP specifications — i.e. properly handle MIME header folding.) In Chilkat v184.108.40.206, we avoid folding the Authorization header. We now discovered that it’s best to avoid folding the idToken header.
The error returned by the web server that choked on the folded idToken header field was: status code = 500, Error message “jwt malformed”.
2. Still working to resolve issues with Utimaco HSM. Apparently it does not support (in PKCS11) the attribute CKA_SUBJECT for private keys. The Utimaco HSM returns CKR_ATTRIBUTE_TYPE_INVALID when C_GetAttributeValue is called with CKA_SUBJECT. Damnit. Anyway.. checking to see if CKA_MODULUS is supported. We need a way to match the correct private key for a given certificate…