• HTTP:  Fixed problem with setting Content-Type header in HTTP POST to text/namevalue (which is required for POSTs to payflowpro.paypal.com).  The POST body was URL encoded when it shouldn’t have been.  When sending namevalue POSTs to payflowpro, be sure to specify the content-type in the HTTP request object:  requestObject.AddHeader(”content-type”,”text/namevalue”)
• SSH / SFTP: For AuthenticatePw, if the server’s authentication is keyboard-interactive
  and it fails because a password change has been requested, then the PasswordChangeRequested property will be set to true.  The AuthenticatePw method
  should be re-called with a password having the form “|oldPassword|newPassword|”.  (Vertical bar characters delimit the old and new passwords.)
• RSA: Fixed problem with 768-bit RSA keys w/ encoding/decoding to XML format.
• General: (may apply to Email, MIME, RSA, Crypt, etc.)  Fixed internal ASN.1 parsing issue with decoding a sequence using the indefinite length encoding.
• MIME, Email, IMAP, Crypt: Added new methods:  AddPfxSourceFile and AddPfxSourceData to allow for any number of PFX files to be searched for required certificates and private keys when signing, encrypting, decrypting, etc.
• Email: Added methods for creating DSN’s and MDN’s:  CreateDsn, CreateMdn.
• SshTunnel: Added SshTunnel.ListenPort for listening at port 0 and letting the bind automatically allocate a port number.
• Socket: Added the ability to listen at port 0
  and then get the allocated port number via the LocalPort property.
• XML: Added “/A/tag,attrName,attrValuePattern” to the ChilkatPath method.  Allows for navigation to a node having a specified tag and also an attribute w/ value matching a pattern.
• Cert: Added the SetPrivateKey method to simplify using a separate private key with a certificate.  The LinkPrivateKey method is only required if the private key is located in the Windows Protected Store and not directly accessible.
• HTTP: Fixed HttpRequest.AddParam so that multiple params with the same name may be added.
• CertStore: Fixed the CreateFileStore method.
• HTTP: Added HttpRequest methods to allow the content-type to be specified for uploads:  AddFileForUpload2, AddBytesForUpload2, AddStringForUpload2.
• Email: Added Email.SigningHashAlg property, which can be set to “sha1″, “sha256″, etc.  The Chilkat CSP object is not usually needed anymore.
• RSA, Crypt, etc. Fixed parsing/decryption of AES-128-CBC encryption for PEM files.
• Email, MIME: Added Pkcs7EncryptAlg, Pkcs7KeyLength properties.  These properties control the public-key encryption algorithms and key length without the need for using the Chilkat CSP object.
• HTTP: Added Http.AddQuickHeader and Http.RemoveQuickHeader methods.  It can be used to add custom headers (or delete default headers) for any of the HTTP methods beginning with “Quick” such as QuickGetStr, or any of the Download methods.
• Note about Google XOAUTH for IMAP: If your application can calculate the XOAUTH data, it may authenticate by calling SendRawCommand(”AUTHORIZE XOAUTH <base64Data>”)
• MailMan/POP3: Added the Pop3Stls property for explicit TLS.
• MIME: Added the GetHeaderFieldAttribute method.
• HTTP: Fixed problem with automatically following redirects to external domains.
• MHT: Fixed AbortCheck event callbacks (they were not getting called).
• Self-Extracting EXE: Removed -url option from standard build (to reduce size…)
• Socket: Fixed Socket ReceiveUntilMatch w.r.t. certain situations with non-usascii characters.
• Mailman/POP3: Will Auto-retry POP3 connect/login w/ STLS if “-ERR this server requires SSL/TLS protection” is received.
• DKIM: Added new methods:  LoadDomainKeyPkBytes and LoadDkimPkBytes.
• Zip: May now pass “*” to RemoveNoCompressExtension to remove all no-compress extensions.
• MIME: Added GetSignatureSigningTime and HasSignatureSigningTime methods.
• TAR: Fixed problem in UntarFirstMatchingToMemory.
• MHT: Fixed problems involving HTTP redirects to different domains.
• FTP: Fixed PutTree problems specific to WS_FTP servers.
• Zip: Fixed Zip.AppendOneFileOrDir for the case when the argument is a single directory with no files.
• HTML-to-XML/Text: Fixes for properly handling unclosed TR and TD tags.
• Cert/CSP ActiveX only: Moved ChilkatCSP to ChilkatCert.dll from ChilkatUtil.dll
  Use of the CSP object should be avoided if possible.  It is replaced with properties
  such as Pkcs7CryptAlg, Pkcs7KeyLength, SigningHashAlg.   (The CSP should only be used when necessary, such as with hardware tokens or smartcards.)
• MHT: Fixed problem w/ internal infinite loop if unclosed <iframe> tag was encountered.
• MIME: Mime.SetBodyFromPlainText, SetBodyFromHtml, and SetBodyFromXml have more precise definitions and behaviors.  See the reference documentation.
• Zip: Fixed multi-threaded problem regarding temp files.
• Cert: Added the SelfSigned property (read-only)  to know whether a certificate is self-signed or not.
• IMAP: PeekMode property was being reset when re-connecting or re-selecting a mailbox.  This was fixed.
• SMTPQ: Will now avoid retrying for failure cases where a retry would never succeed.
• FTP2: Added UploadRate and DownloadRate event callbacks.
• Zip/Self-Extracting EXE Note: Prior to calling WriteExe, call  SetExeConfigParam(”Cleanup”,”1″) to create an EXE that will cleanup files after finished.
• SSH/SFTP: Added the AuthenticatePwPk method to support password + public-key authentication.
• SFTP: Fixed problems with uploading large files where the upload could possibly get stuck and timeout.
• Email Object: The Email.UnwrapSecurity method has been removed.  When an email object loads MIME via the LoadEml method, or by calling SetFromMimeText, or when it is loaded internally by the MailMan/IMAP objects when receiving email from a server, the MIME is decomposed and stored in an internal email object model.  Because the MIME is decomposed, it is at this point that all signatures (if present) must be verified because the MIME is no longer available in its original form.  Therefore, it is not possible to unwrap the security layers at a later time.  The results of signature verification and/or decryption are available in the email object properties:  ReceivedSigned, ReceivedEncrypted, SignaturesValid, Decrypted, and by methods:  GetSignedByCert, GetEncryptedByCert, etc.Note: This only applies to the Chilkat.Email object, not the Chilkat.Mime object.
• MailMan/Imap: The AutoUnwrapSecurity property must always be true, therefore it is being removed.
• MailMan: Removed the AutoSaveCerts property.

Commands that assume an interactive user at a shell prompt should not be passed to SendRequestExec.  For example, the “more” command assumes there is a shell and that the user will press RETURN when another screenful of text is wanted.  It would be more appropriate to use the Unix/Linux “cat” command w/ SendRequestExec.

To run interactive commands, one should instead start a remote shell by (1) starting a pseudo-terminal by calling SendReqPty and then (2) starting a shell by calling SendReqShell. See this example:

ASP: SSH — Running Commands that Prompt for Additional Input, such as “su”
SQL Server: SSH — Running Commands that Prompt for Additional Input, such as “su”
C#: SSH — Running Commands that Prompt for Additional Input, such as “su”
Delphi: SSH — Running Commands that Prompt for Additional Input, such as “su”
Visual FoxPro: SSH — Running Commands that Prompt for Additional Input, such as “su”
PHP: SSH — Running Commands that Prompt for Additional Input, such as “su”
VB.NET: SSH — Running Commands that Prompt for Additional Input, such as “su”
Visual Basic: SSH — Running Commands that Prompt for Additional Input, such as “su”
VBScript: SSH — Running Commands that Prompt for Additional Input, such as “su”

When a command is passed to SendReqExec that produces no output, such as “echo 1 > test.txt”, then do not try to read the channel (such as by calling ChannelReadAndPoll) because no data will be forthcoming and the channel read will timeout (as expected). The correct sequence of method calls would be to:

1. Call SendReqExec to execute the command on the remote server.
2. Call ChannelSendClose to initiate the closing of the channel.
3. Call ChannelReceiveToClose to wait until the server closes the channel. In this case, no actual output data is returned because the command passed to SendReqExec produces no output.  This method is called to cleanly wait for the server’s “close” message.

A Chilkat customer provided this bit of Foxpro code:

DECLARE LONG DllRegisterServer IN <yourfile.dll>
IF DllRegisterServer() = 0
   * OK
ELSE
  * Not OK
ENDIF

It provides an alternative way to distribute an ActiveX DLL with a FoxPro application. Typically, one would create an installer, such as a .msi or something from an install software package (InstallShield perhaps), such that the installer registers any ActiveX DLL’s included in the setup/deployment project when installing. However, using the idea above, it should be possible to simply include the ActiveX DLL in the same directory as the EXE and potentially distribute as a simple .zip. When the app is first run, it could automatically register the ActiveX DLL.

(With permission from a Chilkat customer, for the benefit of others..)

Problem:

We did some extensive testing and found that our client sees this on their end what the connection fails:

SERVER:   13.07.2010  15:21:43  (57220) session ended on error, Buffer missing (error 132).

Do you know what that could possibly mean in relation to Chilkat’s SFTP?

Solution:

“The issue ended up being a security appliance (Untangle) we had. We added a bypass rule in there for port 22 and it went from working 3/5 times to 5/5 times.”

This post points to the various examples and blog posts scattered among the chilkatsoft.com, example-code.com, and cknotes.com involving progress monitoring of  FTP uploads and downloads using the Chilkat FTP2 ActiveX, .NET component, and C++ libs.

Important for Monitoring Upload Progress: The SendBufferSize property is set to a large value (512K) to maximize performance.  Unfortunately, this usually ruins the frequency of “percent done” callbacks for upload (not downloads, just uploads).  To improve the upload “percent done” callback frequency, set the SendBufferSize property to a smaller value, such as 4K.  It may slow the upload transfer rate a bit, but it improves the progress monitoring capability.  You can experiment with different values for SendBufferSize to determine what best suits your needs.

Monitoring Download Percent-Done: Be sure to read about the AutoGetSizeForProgress and the ProgressMonSize properties in the Chilkat online reference documentation.  Depending on your FTP server, it may be necessary to set the AutoGetSizeForProgress equal to True to properly receive percent-done event callbacks.  In most cases, neither property is needed — it entirely depends on whether the FTP server provides file-size information in the intermediate response to a “RETR” FTP protocol command.

FTP2 Events in C# and VB.NET:

• Don’t forget to enable events by setting the EnableEvents property = True.
• List of Chilkat.Ftp2 events in C# syntax.
• Using the ProgressMonSize property (in C#)
• FTP Upload Progress Monitoring in C#
• FTP Download Progress Monitoring in C#
• FTP Upload Progress Monitoring in VB.NET
• FTP Download Progress Monitoring in VB.NET
• Adding a Callback Event Handler in VB.NET

FTP2 Events in VB6

• FTP Upload with Progress Monitoring in VB6
• FTP Download with Progress Monitoring in VB6
• ProgressMonSize property in VB6

FTP2 Events in C++

• FTP Upload w/ Progress Monitoring in C++
• FTP Download w/ Progress Monitoring in C++

FTP2 Events in FoxPro:

• Blog post detailing FTP2 events using FoxPro syntax.

More Information:

• PercentDone callback counts as an AbortCheck
• AbortCheck Event in Chilkat .NET Components

Question:
I receive strange characters when downloading a text file using ReadFileText. Why does this happen?

Answer:
Using SSH/SFTP, files are downloaded exactly as-is byte-for-byte except if you call the ReadFileText* methods. The ReadFileText* methods require a charset (i.e. character encoding) to be specified in the method arguments. This allows the method to interpret the bytes according to a specific character encoding (such as utf-8, windows-1252, Shift_JIS, etc.) and then return the correct string (because strings in programming environments using ActiveX, or languages such as C#, VB.NET, Java, etc are objects with an internal Unicode representation).

To manually verify that a valid permanent unlock code was passed to UnlockComponent, examine the contents of the LastErrorText after calling UnlockComponent. The following message indicating a permanent unlock code was used should be present:

“Component successfully unlocked using permanent unlock code.”

See below:

ChilkatLog:
  UnlockComponent:
    DllDate: May 24 2010
    component: Email
    unlockCode: ****
    RegKey:
      LibDate: May 24 2010
      requiresPerm: 0
      re-parsing expire date...
      Component successfully unlocked using permanent unlock code.

All Chilkat classes / components use a property named LastErrorText.  It provides a way to get detailed information about what happened during any Chilkat method call.  The LastErrorText will contain information even when the method call is successful.

In almost every case, the LastErrorText will begin with information such as this:

ChilkatLog:
  Connect:
    DllDate: Jun  2 2009
    UnlockPrefix: ****
    Username: Jake
    Component: ActiveX

When contacting Chilkat support (support@chilkatsoft.com) you will probably be asked to provide the contents of the LastErrorText property. The information at the beginning of the LastErrorText is important. Here are the details:

DllDate: It tells Chilkat support how old of a version of the Chilkat component/library is being used. In most cases, if the DllDate is old, you will be asked to try the latest pre-release. (Click here to go to the Chilkat pre-release download web page.) The reason is that most problem reports are already fixed in the latest version (especially if the DllDate is old) and the information in LastErrorText is always improving. It’s best to begin investigating a problem by using the latest pre-release.

Also, (quite often) Chilkat support will provide a new build and ask the customer to re-test. In a surprisingly large percentage of cases (especially when using the ActiveX or .NET components), the customer does not actually use the new build and re-test using the same old-version. The DllDate allows Chilkat support to know if the customer is really testing with the new build.

UnlockPrefix: Provides Chilkat support with licensing information. If your 1-year support expired, you *may* be given a 1-support grace incident with the expectation that support will be renewed prior to any future support requests.

Username: This is the logged-on Windows OS username of the process. The main reason it is included is to allow us know if the process is an IIS worker process, or perhaps running as a Windows Service. In these cases, file access and I/O permissions may be more restricted than when running other applications.

Component: Allows Chilkat support to know if you are using the ActiveX, .NET, VC++ libs (and the version of VC++), etc. It saves time from having to ask which Chilkat lib/component is being used.

Also.. the first line after the opening “ChilkatLog” will be the name of the method call. In the sample above, it can be seen that “Connect” was the method call. (Quite often, a customer will not capture the contents immediately after the intended method call. )

Question:

UnlockComponent returns a failed status (0 / false) with this information in LastErrorText:

ChilkatLog:
DllDate: Feb 15 2010
component: Zip
unluckCode: Anything for 30-day trial
RegKey:
LibDate: Feb 15 2010
dateStr: 6 6 2010
mdy: 6/6/2010
keyT: 1278367200
curT: 1279490400
curDT: Mon, 19 Jul 2010 17:09:24 +0200
Trial has expired: 38

Answer:

If the string argument passed to UnlockComponent is NOT a permanent unlock code, then the LastErrorText will contain the exact string passed to it by your application.  In this case, it is easy to see that the string “Anything for 30-day trial” was passed to UnlockComponent.  To resolve the problem, check carefully the exact string being passed to UnlockComponent.  Make sure the permanent unlock code is passed to it.