Hi Scott, You're a bloody angel. So much time on moi.
I think I took the right steps. Here
is the little debug file: HTTPAPI Ver 1.10
released 2004-09-24
http_url_post():
entered
http_persist_open():
entered
http_long_ParseURL():
entered
(GSKit) Handle
is not valid.
ssl_error(1):
(GSKit) Handle is not valid.
SetError() #29:
gsk_sec_soc_open: (GSKit) Handle is not valid. I followed through in debug, the problem manifests
in CommSSL_Connect proc of COMMSSLR4 at this call: c
eval
rc = gsk_secure_soc_open(wkEnvH: wwSSLh) The pointer args were each *NULL, and the rc
came back = 1. What am I doing wrong? Thanks, Peter -----Original Message----- Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx> Hi Peter, > Therefore a *NULL value was returned, and the code in the caller > dictated that efforts come to a halt. There was no specific error
msg, > but I'm telling you this is where things broke down. The HTTP_error() subprocedure returns the "specific error
message" that you don't think exists. When you call HTTP_error() (after HTTP_url_post() returns) what does it
say? > I will try to grasp what you've said below (instructions for
creating > the log), but I've not much to add - this is where the code
essentially > "dies" in my case. The problem is, there are MANY possible reasons for the connection to fail. Probably over 100
possibilities. I need to know *WHY* the connection fails, not which subprocedure it
fails in That's what HTTP_Error()
(or the log file, if you want to take it to the next level) will tell you. ----------------------------------------------------------------------- This is the FTPAPI mailing list.
To unsubsribe from the list send mail to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr ----------------------------------------------------------------------- |