I've been trying to track down a weird intermittent failure when automating IE. It basically just needs to open the browser and post a string which contains a user name, password hash and 3 other search parameters. Occasionally the website would reject/fail on the request. It appears as though VFP is tacking on an additional character onto the string I'm passing it.

The basic code looks like this:

loIE = CREATEOBJECT("InternetExplorer.Application")
loIE.Visible = .T.

lcPostData = "User=" + m.tcUser + "Pass=" + m.tcHash && Shortened version of real string
lcBinary = CREATEBINARY(m.lcPostData)

lcHeader = "Content-Type: application/x-www-form-urlencoded" ;
               + CHR(13) + CHR(10)

loIE.Navigate2(This.cLoginURL, , , m.lcBinary, m.lcHeader)

When it works, VFP has only tacked on a CHR(0) to the end of my post string. In cases where it fails, it's embedded some other weird character. I can see the extra character through Fiddler.

I thought I could work around this by explicitly passing the Content-Length and making it 1 character shorter. That sort of works, but appears to cause this particular server to spit out an invalid redirect one request later (it's adding a null before the GET header). That causes a 400 error in the browser.

Before I try to work with the vendor to see if they'd be willing to try an IIS registry patch I've found, I was wondering if anyone else has run into this and have any work arounds?