Chilkat v11.5.0 Release Notes

✨ New Features

HttpCurl

A new Chilkat class has been added: HttpCurl

The Chilkat.HttpCurl class executes curl commands and can automatically resolve dependent values needed by a request.

Variables such as {{access_token}}, {{site_id}}, or {{drive_id}} may appear in URLs, headers, query parameters, or request bodies. If a variable is not yet known, HttpCurl builds an execution plan from previously defined curl functions, runs the required steps, extracts values from JSON responses, and then executes the final target request.

Use AddFunction with AddOutput or AddOutput2 to define how prerequisite values are obtained. Use SetVar to provide known values, ClearVar to invalidate them, and ExaminePlan to inspect the dependency plan before running it.

After DoYourThing completes, the response can be read as text, binary data, JSON, XML, or streamed directly to a file. Diagnostic properties such as StatusCode, FailReason, FailedCurl, and LastErrorText help troubleshoot failures.

EnableSecrets

Added the boolean EnableSecrets property to several Chilkat classes. When set to true, it provides the ability to pass a secret name rather than the actual value of a sensitive item. For example, a password for Ftp2, or a client_secret for OAuth2 client credentials. The value (such as client_secret) would’ve been previously stored via the Chilkat.Secrets API to the local manager, which on Windows is the Window Credentials Manager, and on Apple is the Apple Keychain.

• Secrets Conceptual Overview — See Chilkat Secrets API for a refresher on the Secrets API.
• When EnableSecrets is true, certain Chilkat methods and properties are secrets-aware. A passed-in value having the format “!!part1|part2|part3|part4” where a secret name is specified by providing 2 to 4 parts will get auto-resolved by looking up the secret in the local manager and found value will be used instead. This makes it easier for applications to avoid embedding sensitive information in source code.

For more information, see Chilkat EnableSecrets

New Architectures and Builds

• WatchOS — Removed the armv7k slice and added the arm64 slice. (full-fat arm64 (64-bit instructions, 64-bit pointers). Also added arm64 simulator slice.
• tvOS — Added the arm64 simulator slice.
• Ruby — Added Ruby 4.0.* builds for Windows, macOS, and Linux.
• linux-musl-arm64 for .NET Core — Added linux-musl-arm64 build for .NET Core.

Misc

• SOCKS — In Chilkat classes having SOCKS proxy properties, added the ability for a SOCKS destination host to be an IPv6 address.
• FTP2 — Added the GetLastJsonData method. See Enhanced FTP TLS Diagnostics and Expired Certificate Handling
• TLS — Added the AllowExpiredServerCerts keyword that can be added to the UncommonOptions property. The allows for TLS connections to ignore expired server certificates when making TLS connections. This applies to all Chilkat classes that can establish TLS connections and have the UncommonOptions property.
• Gzip — Added the GetGzipInfo and GetGzipBd methods.
• Jws — Added the SetSigningCert method.

🛠 Fixes & Improvements

Misc

• Pdf AddEmbeddedFiles — Fixed a problem where attachments added by calling AddEmbeddedFiles were subsequently missing after signing
• XmlDSigGen — Fixed a problem with handling the <XPath xmlns=http://www.w3.org/2002/06/xmldsig-filter2 Filter=”intersect”> transform.
• Zip AppendZip — Fixed the AppendZip method.
• CodeSign — Fixed a problem with VerifySignature where an uncommonly encountered countersignature was present. Chilkat did not recognize the OID or ASN.1 format for the countersignature.
• SFtp — Fixed a problem with downloading files from a server that did not behave well according to the SFTP protocol specification. (In other words, a workaround for a badly behaving server.)

MS Office365 Automatic Client Credentials

Fixed: Access tokens obtained via the Microsoft 365 client credentials flow do not include expiration-time information. As a result, Chilkat interprets the token lifetime as zero and must acquire a new access token for each new session (SMTP, IMAP, etc.).

In previous versions, Chilkat incorrectly assumed a default token expiration time when no expiration information was present. This could cause subsequent sessions that reused the same object instance to attempt authentication with an expired access token, resulting in authentication failures.