v9.5.0.60 Update: New Features, Fixes, Changes, etc.

  • ActiveX, .NET: Fixed problems with the LastMethodSuccess property. Version 9.5.0.60 is a patch for .NET and ActiveX only for this one issue. The Mono builds, .NET Core, and .NET UWP (Windows Runtime) did not have any problem with LastMethodSuccess, and therefore remain at v9.5.0.59. Other languages (C++, Java, Perl, Python, etc.) are also unaffected and therefore remain at v9.5.0.59.

v9.5.0.59 Update: New Features, Fixes, Changes, etc.

  • OAuth2: Added the OAuth2 class.
  • FTP2: Fixed SyncRemoteTree/SyncRemoteTree2 progress monitoring callbacks.
  • Crypt2: Fixed the GenerateUuid to respect RFC 4122. The GenerateUuid method generates the version 4 variant, which is composed of entirely random data except for the few bits that signify version 4.
  • Compression: Fixed the CompressFile method for large files. See Fixed CompressFile
  • MHT: Fixed: MS-Word html files with %20 in file paths needed to be replaced with SPACE chars.
  • Cert/SMIME/PKCS7: Fixed: When a cert doesn’t have the Issuer CN, the encrypted message could not be decrypted using Chilkat library, even though the cert does have subject key id.
  • REST: Dropbox workaround: DropBox is not Q/B decoding header fields as it should do (if it were
    behaving according to standards). Two modifications were made: (1) Disable Q/B encoding for header fields when Dropbox is the endpoint. (2) Added a new REST property named AllowHeaderQB to enable/disable Q/B encoding for header fields. It is enabled by default.
  • SSH: Fixed: ChannelReceiveUntilMatch did not work for some cases with wildcard (*) match patterns.
  • Android/Java: Fixed the emoji utf-8 problem. The use of emoji’s caused issues with the underlying JNI implementation because Java uses modified-utf8, which is only different because it must use surrogate pairs for chars that encode to longer than 3 bytes. Chilkat will now (internally) emit the correct modified utf-8 using surrogate pairs to keep the JNI fat and happy (given that this problem was discovered w/ the pizza slice emoji for a major pizza chain).
  • HTTP/TrustedRoots: Fixed: When verifying the web server certificate for a TLS connection, the Windows registry-based root CA cert stores were not being searched when TrustSystemCaRoots was true.
    Now Chilkat will correctly search for the root cert, and if found, will trust the root cert.
  • PEM: Added the “AddItem” method. See the very bottom of this example: AddItem
  • MHT: Enhancement: MHT will not try to embed images when the data is already embedded, such as:
    <img style=”display:block;margin:0 auto 5px;text-align:center;” src=”data:image/png;base64,iVBORw0KGg…
  • HTTP: Fixed auto-follow of HTTP redirects when the redirect URL is a Protocol-relative_URL (i.e. URLs beginning with “//”)
  • Zip: Added the AppendDataEncoded method.
  • Python/FreeBSD: Fixed the installer for Python on FreeBSD.
  • Email: Fixed Q/B decoding issue for address related headers. The SPACE char between the friendly name and the email address was dropped when Q/B decoding.
  • JSON: Fixed a parse problem that occurred when a Unicode char was the very last char in a JSON value string. For example if the value string ended with “\\u6e2c”, then this final char was dropped in the string returned by various methods.
  • TLS 1.2: Fixed: The server would close the TLS connection during initial handshake (after receiving the ClientHello) if it picked the cipher suite TLS_ECDHE_ECDSA in TLS 1.2. The reason is that Chilkat did not include the ECDSA/SHA1 signature hash algorithm as a candidate for the Server Key Exchange. (Note: This was not a security issue — it was just a case where the TLS handshake would fail if the server picked a particular cipher suite, only in TLS 1.2, and expected to use a paricular Server Key Exchange signature hash algorithm.)
  • SSH: Added the hmac-sha1-96 algorithm to what is supported in the internal SSH connection protocol.
  • Email: Eliminated problems arising from X.400 email addresses where there is no “@” character.
  • HTTP: Fixed the ReceiveRate callback (so that it’s actually called) for the WinRT and Unicode C++ builds.
  • Unicode C++: Event callbacks were broken starting in v9.5.0.58 for the Unicode C++ builds. (They were working in v9.5.0.57, broken in .58, and now fixed in .59)
  • IMAP: A particular kind of email on a particular IMAP server would cause a hang (or timeout) when downloading the email for the case where AutoDownloadAttachments is disabled.
  • SFTP: Worked around problems with the Devart SSH server.
  • Email: Fixed email structure problems for certain situations when SetHtmlBody was called.
  • HTTP/S3: Fixed a problem caused when filenames contain SPACE chars.
  • Email: The ComputeGlobalKey method was deprecated and should not be used. The inputs to the MD5 hash algorithm were not properly canonicalized, and therefore the computed key could change from version to version (based on fixes, improvements, etc. in the MIME processing).
  • Email: Added the ComputeGlobalKey2 method, which is properly canonicalized to avoid the issues of the original ComputeGlobalKey implementation.
  • XMP: Fixed: TIFF files with EXIF IFD’s were not correctly re-written.
  • Email/MIME: Fixed problems where the values in address related header fields were not returned Q/B decoded. (For example, the value returned by the GetHeaderField method should be Q/B decoded.)
  • SSH: Fixed a performance problem w/ the ChannelPoll method for very small timeouts.
  • Zip: Fixed a problem w/ encrypted zips for Unicode C++ (CkZipW) on Mac OS X. The issue has to do with the fact that wchar_t is 4 bytes per char (on Mac OS X) as opposed to 2 bytes per char.
  • Email: Fixed GetSignedByCert so that it will still return the certificate even if the signature validation fails.
  • FTPS: Fixed a PBSZ/”PROT P” problem with the Global eXchange Services Secure FTP brand of FTP server.
  • JSON: Fixed a JSON parsing problem having to do with escaped chars.
  • MHT: Fixed a problem with “link” tags where attributes such as “media” were getting dropped.

OAuth2 for Desktop Applications (C#, VB.NET using Chilkat)

Here are C# and VB.NET sample applications (on GitHub) for doing OAuth2 authorization using Chilkat for Facebook, Google, LinkedIn, Salesforce, and GitHub.

OAuth2 Sample for Desktop Applications (C#) for Facebook, Google, LinkedIn, Salesforce, and GitHub

OAuth2 Sample for Desktop Applications (VB.NET) for Facebook, Google, LinkedIn, Salesforce, and GitHub

 

 

Damn You Windows Firewall!

One particular cause of the following error is finally known:

sockRecv(47ms):
    WindowsError: An existing connection was forcibly closed by the remote host.
    WindowsErrorCode: 0x2746
    numBytesRequested: 5
    Failed to receive data on the TCP socket
--sockRecv
sockRecv failed.
sockRecvN_buf: Did not receive the exact number of bytes desired.
numBytesToReceive: 5

This error was caused by the Windows Firewall doing stateful FTP filtering. The solution is to disable stateful FTP filtering so that the firewall does not block any FTP traffic. (This is typically prescribed for the server-side of FTP, but it also applies to the client-side.)

Note: The Windows Firewall’s stateful FTP filtering only causes problems when the connection is SSL/TLS. Clear (non-secured) connections are not affected.

To disable stateful FTP filtering, open an administrative command prompt, and type the following:

netsh advfirewall set global StatefulFTP disable

Also Note: The above error could also be a result of the connection truly being closed by the remote host, or something on the server-side. This solution only applies to the case where Windows Firewall (on the client-side computer) is interfering with a SSL/TLS FTP connection.

How to Reproduce the Problem

To reproduce the problem, write a program that establishes a TLS connection with an FTP server.   After authenticating, write a simple loop that calls ftp.Noop 1500 times.   If Windows Firewall is interfering, it is likely to fail in the same place every time.  For example, in my case the error occurs on iteration 699 every time.

Also, the error may not be easily reproducible even if Windows Firewall is a problem.  For example, the problem seemed to be not reproducible if the FTP server was not a Windows-hosted FTP server.   One might suspect the server-side to be the problem, but the connection reset ([RST, ACK] in a WireShark trace) definitely originated from the client-side.

Disabling the firewall’s Stateful Packet Inspection (SPI) feature solved the problem every time. (It should be the case that stateful packet inspection should NEVER try to inspect the packets of a TLS encrypted channel for the simple fact that it’s impossible to inspect.  The firewall does not have the ability to decrypt the packets in the channel, and therefore it cannot inspect anything. The firewall’s only choices SHOULD be to simply allow or disallow the connection.  I don’t understand why stateful packet inspection should ever be “monkeying around” with encrypted channels..)

v9.5.0.58 Update: New Features, Fixes, Changes, etc.

  • Rest: Added the Rest class.
  • Jwt: Added the Jwt class.
  • AuthAws: Added the AuthAws class.
  • AuthGoogle: Added the AuthGoogle class.
  • AuthAzureAD: Added the AuthAzureAD class.
  • AuthAzureStorage: Added the AuthAzureStorage class.
  • ServerSentEvent: Added the ServerSentEvent class.
  • CertStore: Fixed a memory leak in the LoadPemFile method.
  • Charset: Fixed problems in the VerifyData method having to do with us-ascii and utf-8.
  • C++: Now includes utf16_t classes. Except for certain classes such as CkString and CkByteData, there are three options for each C++ class:
    the multibyte class, the wchar_t class, and the utf16_t class. For example, CkSFtp, CkSFtpW, and CkSFtpU.
  • FTP2: (FIXED) The SyncRemoteTree/SyncRemoteTree2 progress monitoring (event callbacks) were not working
  • FTP2: Added the LargeFileUpload method.
  • IMAP: Added new methods: HasCapability, GetQuotaRoot, GetQuota, and SetQuota.
  • LastErrorText: The Windows logged-on username is no longer automatically logged at the top of every LastErrorText.
    (This was originally done to help w/ support issues so tht Chilkat might notice if the program runs in the context of a Service or IIS, which could be a clue to the cause of certain problems.)
  • SSL/TLS: Internal client-side and server-side renegotiate problems were fixed.
  • FTP2: Backslash chars in paths sent to the server are automatically converted to forward-slashes
  • PrivateKey/PublicKey: Deprecated many methods and added new methods. Originally these classes were for RSA keys, but have since become
    a classes that can contain either RSA, DSA, or ECC keys. Methods with “RSA” in the name were deprecated. Also, methods with confusing names were deprecated and replaced with methods having better names.
  • SFTP: Fixed problems with certain SSH/SFTP servers where certain downloads would hang.
  • TLS: Added support for the SHA512 server key exchange hash algorithm. (See http://www.chilkatforum.com/questions/10395/sslallowedciphers-options)
  • StringBuilder: Added a StringBuilder class, which is more helpful in some older programming languages as opposed to others.
  • Email: Fixed problems with comma characters found in email addresses that are Q/B encoded.
  • JsonObject: Crash bug fixed in the StringOf method.
  • Email: (FIXED) Comma characters embedded in an email address friendly name, such as “Doug, Smith ” would interfere with the parsing of the email address.
  • SFTP: Added the SyncDirectives property.
  • LoadTaskResult: (FIXED) The ActiveX LoadTaskResult methods always returned 0, regardless of success/failure.
  • MHT: (FIXED) Chilkat hangs with specific HTML on calling mht.GetEML. The problem had to do with infinite recursion: The CSS that is downloaded itself contained an import for the same CSS (or indirectly contained an import for a CSS that then contained an import for a CSS that was previously downloaded, causing a loop).
  • Crypt2: The value of the KeyLength property should always be in agreement with the number of bytes of key material provided by the application.
    The SetEncodedKey method correctly has the side-effect of also setting the KeyLength property. However, setting the SecretKey property directly did not also have this desired side-effect.
    This was fixed. If the SecretKey property is set with 16 bytes of data (128 bits) then the KeyLength property is automatically updated to 128.
  • PHP: Added Windows builds for PHP as FastCGI with IIS using the Non-Thread Safe (NTS) versions of PHP. See https://www.chilkatsoft.com/php.asp
  • Tar: Fixed a crash bug in the VerifyTar method (for corrupt/garbage input files).
  • CkDateTime: added the GetAsTimestamp and SetFromTimestamp methods.
  • Email: Fixed issues having to do with structuring an email with multipart/related, multipart/alternative, etc.
  • Ftp2: Regarding the ForceIpAddress property: By default, Chilkat will NOT try to bind the data socket to the IP address specified by the ForceIpAddress property.
    You may use a special “bind-” prefix in the ForceIpAddress property to cause the data socket to be bound to the ForceIpAddress property. For example, put_ForceIpAddress(“bind-80.130.210.228”)
    There was an undocumented feature where you can set the ForceIpAddress property equal to the keyword “control”. In this case, the IP address of the control connection is used.
    Also, Chilkat will now recognize the error message “I won’t open a connection to…”, and will automatically retry using the IP address from the message.
  • Csv: (FIXED) Csv.WriteFile2 did not work with utf-16.
  • CkString (C++): Added getUtf16 and setStringUtf16 methods.
  • IMAP/MailMan: (FIXED) The new format of the IMAP-only unlock code unloced IMAP, but not the MailMan object.
  • AbortCurrent: Added the AbortCurrent property to classes that can have event callbacks.
  • HTTP: Fixed a problem involving HTTP redirect responses in combination with HTTP proxies where both SSL/TLS and non-SSL/TLS URLs are involved.
  • IMAP: Added the capability to handle DIGEST-MD5 authentication for IMAP.
  • HTTP: Fixed problems handling 407 responses. Also fixed behavior when receiving a response with a “proxy-connection:close” header.
  • SshKey: (FIXED) SshKey.FromPuttyPrivateKey() failed if comment contained umlauts. See
    http://www.chilkatforum.com/questions/10082/sshkeyfromputtyprivatekey-fails-if-comment-contains-umlauts
  • JsonObject: (FIXED) Calling json.AddObjectAt on an empty JSON document failed.
  • FTP2: Reverted the Microsoft FTP workaround added to v9.5.0.56.
  • Socket: The non-SSL/TLS HTTP proxy functionality was fixed.
  • SCP: The DownloadFile method did not close the channel.

iOS C/C++ Static Library Sizes

There is often alarm at the size of the Chilkat static libraries (.a) for iOS. This should not be of too much concern, because after building your app in Release mode, your app’s executable will NOT grow by the size of the static library. It will only grow by a very small fraction of the total size of the .a

There are some common misunderstandings about static libraries that should be cleared up.

  1. You do NOT include the static library (.a) in the package you submit to the app store.
  2. When building your program, Xcode only pulls in the library code that is directly or indirectly used.   (This is true for any C/C++ linker.)   If, for example, Chilkat added functionality for SNMP, Jabber, and Bitcoin, and if this new code caused growth in the .a by 100MB, then it would only cause an increase in your app’s size if your app actually uses the new code.
  3. You may be unaware of the vast number of already-existing system libs (.a) and the vast sizes if all of these were summed up.  Obviously, these are not included in their entirety in your app’s executable.  The same applies to the Chilkat static libs.
  4. You can always check to see how much your app’s executable actually grows in size after linking with Chilkat by examining the size of the executable after linking.
  5. The Chilkat universal lib is composed of both the simulator static libs (x86 + x86_64), and the device libs (arm64, armv7, armv7s).   Your application built for the App Store would not be including alternatives for the simulator.
  6. This Apple Technical Q&A discusses general techniques for reducing the size of an app:  https://developer.apple.com/library/ios/qa/qa1795/_index.html

iOS: Preparing your Apps for IPv6

Chilkat classes that communicate over TCP/TLS include a property named PreferIpv6. This should be set to YES/true to tell Chilkat to use IPv6 when possible. (If the underlying DNS resolution provides both IPv4 and IPv6 choices, then Chilkat will by default choose the IPv4 address. To tell Chilkat to choose the IPv6 choice, set the PreferIpv6 property equal to YES/true.)

Note: All Chilkat classes that communicate over TCP/TLS will include a PreferIpv6 property. This includes Http, MailMan, Imap, Ftp2, Socket, Ssh, SFtp, etc.

For more information, see Using IPv6 in Chilkat Apps for iOS

Hints for Minimizing Size of Windows CE 6.0 EXE in Visual Studio 2008

Chilkat continues to support (and will continue to support for many years to come) older development environments and platforms. The C++ lib for Windows CE (specifically for VS2008) is one such case. The size of the EXE in this environment can matter. Here is one customer’s helpful hints on how to reduce the size of the EXE when building/linking:

Hints for Minimizing Size of Windows CE 6.0 EXE in Visual Studio 2008

The .NET Assembly “Incorrect Format” Error

If you get this error in a Windows Forms project…

Look in your Project–>Properties (ALT+F7) and go to the “Build” tab.
You’ll see the “Platform target”

– If it’s set to “x64”, then make sure you reference the 64-bit Chilkat assembly.
– If it’s set to “x86”, then make sure you reference the 32-bit Chilkat assembly.
– If it’s set to “Any CPU” and the “Prefer 32-bit” checkbox is checked, then your app will run in 32-bit mode and you should reference the 32-bit Chilkat assembly.
– If it’s set to “Any CPU” and the “Prefer 32-bit” checkbox is NOT checked, then your app will run according to the computer (64-bit or 32-bit). It is unlikely you’re developing on a 32-bit Windows computer, so in that case you’d reference the 64-bit Chilkat assembly.

Chilkat .NET Assemblies – Matching Visual Studio versions to .NET Framework Versions to VC++ Runtime Versions.

 

Each version of Visual Studio has a corresponding version of the .NET Framework that is the natural/default version for it.  It’s the latest version of the .NET Framework that existed when the particular version of Visual Studio was released.  For example:

VS2015 — .NET 4.6
VS2013 — .NET 4.5 (actually 4.5.1, but we only care about major/minor numbers)
VS2012 — .NET 4.5
VS2010 — .NET 4.0
VS2008 — .NET 3.5
VS2005 — .NET 2.0

If using a particular version of Visual Studio, this determines everything else.  (You could, for example, use VS2015 with .NET 4.0, but why bother?)  Here are the choices:

VS2015 .NET 4.6 Chilkat .NET for 4.6 needs VC++ 2015 runtime (also known as VC++ 14)
VS2013 .NET 4.5 Chilkat .NET for 4.5 (built with VS2013) needs VC++ 2013 runtime (also known as VC++ 12)
VS2012 .NET 4.5 Chilkat .NET for 4.5 (built with VS2012) needs VC++ 2012 runtime (also known as VC++ 11)
VS2010 .NET 4.0 Chilkat .NET for 4.0 needs VC++ 2010 runtime (x86)(x64) (also known as VC++ 10)
VS2005/2008 .NET 2.0/3.5 Chilkat .NET for 2.0/3.5 needs VC++ 2005 runtime (x86)(x64) (also known as VC++ 8)