[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Applying HTTPAPI and eXpat updates - seeking advice



Michael,

Yes, if you build HTTPAPI with SSL support, the stuff that was bound when it did not have SSL support will get signature faults, et al. That's what I'm trying to tell you.

If you re-bind those existing programs the problem will go away. From this point on, I would suggest always using SSL support, as there's no reason not to.

-SK



On 1/18/2016 3:22 PM, Koester, Michael wrote:
Thanks Scott.
I am not concerned about not having SSL/TLS functionality in the existing stuff -- just my new piece.  That said, will I get signature faults on the existing stuff if I don't recreate/re-bind?

Michael Koester

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, January 18, 2016 4:08 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Applying HTTPAPI and eXpat updates - seeking advice

Hello,

Unfortunately, HTTPAPI uses a different signature when you compile it
without SSL vs. when it is compiled with SSL.
This is something I really wish I had never done.  At the time I did it, I
thought it was pretty slick to just remove the SSL/TLS support, not even
compile it into the program.  But, now it causes problem like this
one.   Really, whomever built 1.24 on your system should never have
compiled it without SSL, there's no reason to do this on V5R1 or newer
versions of the OS...   just compile SSL support always, it doesn't hurt
anything!

Maybe I should just remove the option to compile without SSL so others
don't make this mistake.

But, since you've already built it with SSL removed, you're going to have
to recreate, or at least re-bind, all of the programs that call
HTTPAPIR4 in order to add SSL support to it.

-SK


On 1/18/2016 1:58 PM, Koester, Michael wrote:
We have a couple mission-critical applications using LIBHTTP, which
hasn't been messed with in 4 years (appears to be version 1.24, without
the SSL option).
I now need to extend the capabilities to handle TLS (aka SSL)
communications, and after a few tries, I now have a test of that working
successfully in library LIBHTTP2 (which is version 1.29).
I don't believe I have any custom mods in LIBHTTP, but since the initial
foray into HTTP & EXPAT stuff we also implemented a project that used
Thomas Raddatz' WSDL2RPG work.  I don't know if that has hooks into
LIBHTTP or not.
So now I need to integrate the updated v 1.29 with SSL into LIBHTTP.
Can't run both in Production without LIBL problems.
My hope is that I can delete LIBHTTP2, and run INSTALL (of v1.29 with
SSL) to LIBHTTP as the target library.
After doing that, can I expect that the existing applications should
continue to run without having to recreate objects in the existing
applications?  I'll create the objects for my new functions after LIBHTTP
is updated -- I'm mainly concerned with the existing applications.
Many thanks,
Michael Koester

----------------------------------------------------------------------
- This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
----------------------------------------------------------------------
-

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------