RE: Questions Regarding "HTTP/1.1 500 Internal Server Error"

["Ron" <ron@xxxxxxxxxxxx>]

Scott,

Thanks for the quick reply. I've done more research and discovered a web
site that explained all the HTTP response codes:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

That improved my understanding a great deal. Your explanation showed me how
to capture the HTTP return code so I have all the pieces (HTTP error number,
original HTTP return code) I want now.

I'm writing a "middle layer" between HTTPAPI and our application programs
and this type of information is invaluable. Rather than coding every bit of
the SOAP/XML in our front line programs, and calling HTTPAPI directly, we've
created a "template" XML document that we load in and then we fill in the
element values/attributes through calls to our own APIs (the XML document
content is actually stored in a database file and then converted back to a
stream of data). Once the entire XML document is built (under the covers) we
send it down the pipe to your APIs. That way the front line developer does
not have to understand the complexity of building a valid soap message, they
just assign values to elements (about as simple as EVALing a field).

Along with the "template" document we have a database of information stored
by web service vendor, interface, operation and version. This includes
information such as URL, endpoint, user IDs passwords, HTTPAPI related
settings (ie: strip CRLFs, timeout values), soap action, etc. The front line
developer just has to know the vendor (ie: WebServiceX), interface (ie:
WebServiceXInterface), operation (ie: ConversionRate) and version they want
to use and the framework is built for them with a single API call.

But none of this would be possible without your excellent work.

Regards,
Ron



-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, October 01, 2010 9:02 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Questions Regarding "HTTP/1.1 500 Internal Server Error"

Hello Ron,

On 10/1/2010 8:22 AM, Ron wrote:
>     1)       is HTTPAPI error #13 always just generated for this type of
>     situation (what triggers error #13)?

13 means "HTTP_RESP", and indicates that HTTPAPI detected the error by 
reading the response code from the HTTP server.  (In this case, the 
response code was 500 -- but any response code aside from 200 would 
indicate an error.)

>
>     2)       is 500 a standard return code for HTTP?
>

500 means "internal server error", and means that the server detected an 
error on it's own side of the conversation.  Usually, it means that a 
program that the HTTP server ran (e.g. the web service) ended abnormally.

It's generally not a very useful error code, because there are so many 
possible causes.


>     3)       can I get the 500 programmically out of HTTPAPI at runtime?

The number 500 should be returned from the http_url_post_xxx or 
http_url_get_xxx routine that you're calling.

     code = http_url_post_xml(...etc...);
     select;
     when code = 500;
        // do whatever
     when code <> 1;
        msg = http_error();
     endsl;

-----------------------------------------------------------------------
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
-----------------------------------------------------------------------