[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of CommSSL_Connect in HTTP application
----- Original Message -----
From: "Scott Klement" <sk@xxxxxxxxxxxxxxxx>
To: "HTTPAPI and FTPAPI Projects" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, August 17, 2006 2:40 AM
Subject: Re: Use of CommSSL_Connect in HTTP application
> Hi Eric,
>
> > Anyone know of a way to use the CommSSL_Connect procedure by itself from
> > within my application?
>
> CommSSL_Connect is intended to be an internal routine used by HTTPAPI.
> It's not intended to be called from your programs. Of course, since you
> have the source code, you're welcome to use it as an example of how to
> write your own SSL routines, if that's something you need to do.
>
> > I am quite new at this socket stuff. I have created test applications
> > to open a non secure socket to a remote server and Send a 'GET
> > http://www ...' that is used to prepare data on the remote server. It
> > all works great, due mostly to the LIBHTTP library that we installed
> > from the scottklement site. The next step is to perform a similar
> > function using SSL. This is where my troubles began.
>
> HTTPAPI is intended to allow you to perform HTTP access from your
> applications. But instead of using it, you're using the socket API to
> write your own?
>
> If you're going to write your own, then why are you using HTTPAPI? I'm
> just really confused.
The original non-secure program uses the socket APIs along with your
procedures. And your prototypes are used to access the APIs and the
procedures. So the non-secure version of my program is a mix of both the
APIs and your prototypes and procedures. You might say that this program is
a mix of writing my own and using HTTPAPI. It is a good experiment ... that
created a positive end result.
> To perform a GET request with HTTPAPI, you do this:
>
> rc = http_url_get( 'http://www.example.com/foo/bar'
> : '/tmp/result.txt' );
>
> This is all it takes to perform a GET request. You don't need to use the
> socket API. You don't need to manually format the HTTP protocol commands,
> keywords, etc -- nor parse them -- just call the existing routine in
> HTTPAPI, as shown above.
>
> There are many more routines in HTTPAPI, they're intended to make your
> life easier so that you don't HAVE to write your own GET requests from the
> ground up.
>
> Check out the source members named EXAMPLE1 - EXAMPLE19. They demonstrate
> many of the functions of HTTPAPI. Theres "reference documentation" in the
> comments in the HTTPAPI_H member as well.
In the original non-secure version, I tested such things as error
processing, error recognition, output to screens, and output to a file.
These are some of the things that I must take into account in a real
application. In the secure (SSL) test version, that started as the
non-secure version, I quickly found out that accessing the items needed was
going to be more difficult. You ask why? The short answer is - Because the
APIs were being mixed with your procedures. I could not see that at the
time, because I thought your procedures would mix with APIs in the secure
version like they did in the non-secure version. My choices were to write
my own socket application using APIs or interface to your library for
everything I needed to do. Interfacing to your library was the overwhelming
winner.
> > I have reviewed the latest code examples from LIBHTTP and found no
> > direct 'call' to CommSSL_Connect from the examples.
>
> That's because you're not supposed to call CommSSL_Connect() manually...
> it's an internal routine intended for use by HTTPAPI itself, not from your
> programs.
>
> If you want to do an SSL HTTP request instead of a plain-text one, all you
> need to do is this:
>
> rc = http_url_get( 'https://www.example.com/foo/bar'
> : '/tmp/result.txt' );
>
> The only difference between this and the previous example is that I
> specified "https:" instead of "http:" in the URL. HTTPAPI will see that
> change, and it'll use the SSL routines instead of the plaintext routines
> to download the document.
>
> Again, take a look at the EXAMPLE members, they demonstrate SSL as well as
> regular HTTP calls.
>
The examples are very helpful.
> > The compile gave the error - 'Name or indicator not defined' for
> > CommSSL_Connect. I thought it should find CommSSL_Connect since
> > COMMSSLR4 is one of the modules in the HTTPAPIR4 service program. Why
> > does the compile not find it?
>
> The 'Name or indicator not defined' is because it can't find the prototype
> -- and has nothing to do with the binding of modules. But, if you fixed
> that error (by including the prototype) your next problem would be a
> binding error looking for the routine.
>
> Why? because CommSSL_Connect() isn't exported from the service program.
> Why isn't it exported? Because it's an internal routine, and you were
> never supposed to call it directly.
>
> If you don't like that behavior, you're welcome to use the code as a guide
> of how to write your own routine that functions the way you want it to
> function. But, HTTPAPI is not intended to be a general-purpose socket
> programming toolkit. And it's not intended to be a general-purpose SSL
> programming toolkit. It's purpose is purely for making HTTP calls, so
> that's all you can do with HTTPAPI.
>
My experimental SSL program now only uses your prototypes and no APIs. And
it works great! I am also retrieving the error messages and codes as
needed. The screen and other outputs that I need will be easy to produce.
Thanks for all your help.
> -----------------------------------------------------------------------
> 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
-----------------------------------------------------------------------