Re: Firewall question

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi James,

> Yes, I know what one is, and yes, I've seen one. But isn't it produced 
> unconditionally, if one does a "callp http_debug(*ON), and suppressed 
> unconditonally if one doesn't?

True... but there's nothing to stop you from writing code in your 
program like this:

        if (SomeCondition);
             callp http_debug(*ON);
        else;
             callp http_debug(*OFF);
        endif;

Perhaps you'd want to check for an environment variable, or a data area 
with a paritular value, or a particular parameter to be passed, or 
something like that which could be used to indicate whether debugging is 
turned on or off.


> Yes. But I thought I saw a few more specific return codes in there, 
> somewhere.

No... the return code will be -1 to indicate "error", or it'll be the 
HTTP response code (for example, if you get a 404 Not found message from 
the HTTP server, it'll return 404 -- from HTTPAPI's perspective, 404 
isn't an error, it's just a different type of response from the server.)

To get an error number that actually means something, along with an 
error message, you'd need to call the http_error() routine.


> Looking once again at the EXAMPLE1 source (yes, I know, it does a get, 
> rather than a get_raw), I also see an "eval msg = http_error" statement. 
> Or does that just return a message based on the return code itself?

http_error() returns the very last error that occurred during a session. 
  It's value is NOT based on the return value from the various get or 
post routines... the get/post routines only return something to tell if 
*IF* an error has occurred, they don't tell you what the error is. 
http_error() gives you the last error message (and optionally, also the 
last error number) that occurred... which is far more useful for 
troubleshooting, albeit, not as useful as a debug log.

http_error() only provides the last error, while a debug log shows the 
entire process, what data is exchanged, and all of the errors...

Any time you get an error, you should always be calling http_error -- 
otherwise, the user has no information at all about what went wrong.

> 
> Idea: What if I revise the client so that if it fails both attempts, it 
> calls http_debug(*ON), then repeats both attempts?
> 

That's probably a good idea.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------