Hi Scott,
Thanks for the recommendation. I'll add a loop for any error and just
retry; that makes a lot of sense.
I included the entire debug log with my last response. I'll attach it again
for your convenience.
Thanks,
Kevin
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, June 3, 2015 1:57 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Socket Reset
Kevin,
In the world of communications, you have to expect errors to occur
sometimes. This error (which is more properly known as "Connection Reset",
not "Socket Reset" -- the phrase "Socket Reset" doesn't make a lot of sense)
is a normal error that can occur sometimes, especially if there is some
flaky hardware somewhere out there.
If it's only happening once in a while, then I would suspect that the
network is getting overwhelmed with requests or something like that.
If it happens every single time, then it may be a software error and would
require more/deeper look.
As for your code, no rc will never be 30. The return code from HTTPAPI
is either a positive number when the server reports an error (like 403
forbidden, 404 not found, 500 internal server error, etc) or for errors like
this, it returns -1. You can call http_error() to get the specific error
that occurred, so the code would be like this:
rc = http_url_post(%Trim(URL) : pXmlBuffer + 2 : DataSize : wResponse);
if rc<>1;
http_error(err);
if err = HTTP_SSSNFD;
// error occurred during SSL handshake, handle it here
endif;
endif;
Having said that, I'm not if I'd be this specific (only handling this one
particular error) instead of retrying on all errors. Sure, it's happening
during the SSL handshake now, but a communication error could occur
anywhere. Why not just handle all -1 type errors, retrying say 5 times if
needed?
Mike is implying that this error is not "bubbling up" If that's the case,
it'd be a bug in HTTPAPI, and that will cause a bunch of spurious errors
after this occurs. I would need the entire debug log to help with that (you
can just delete the sensitive stuff, and send me everything else.)
But, I'm not sure if that's true (that it's not bubbling up) or whether the
issue is just that you didn't know that you needed to check http_error()?
-SK
On 6/3/2015 1:45 PM, Mike Krebs wrote:
Looks like some debug is needed in the bowels of the service program as I
would think the error 30 should have bubbled up and stopped any further
activity. Maybe Scott could hop in here and offer some explanation.
But you did get more activity...The debug is showing a 0 length message
sent at least twice. So, from that standpoint, the web service acted
accordingly. Part of the question becomes why did the program send 0 length
messages twice (the first one ending in a timeout). Is this a multiple
request program and steps 2 and 3 ran even though 1 didn't?
Is step 2/3 using something that step 1 is supposed to build? Maybe a if
xmldata<> '' is needed to prevent 2 and 3 from running?
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kevin
Wengert
Sent: Tuesday, June 2, 2015 5:29 PM
To: 'HTTPAPI and FTPAPI Projects'
Subject: RE: Socket Reset
Hi Mike,
It didn't try to parse the result, but it did receive the response. My
program got an error, so it did nothing with the information it received.
Here is my code trying to get the delivery receipt:
rc = http_url_post(%Trim(URL)
: pXmlBuffer + 2
: DataSize
: wResponse);
Right now, I'm only processing if rc = 1. Would rc = 30 when I get the
handshake error? If so, I could create a loop to retry until rc <> 30? I
think that would fix half my issue.
I've also attached the entire debug log, except the portions that are
sensitive.
Thanks,
Kevin
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
Sent: Tuesday, June 2, 2015 2:34 PM
To: HTTPAPI and FTPAPI Projects
Subject: RE: Socket Reset
The HTTPAPI procedure didn't return an error after getting the 30 error
code?
It doesn't make sense that it just continued on and tried to parse the
result. In fact, I am surprised it went on to receive any data.
The error says it happened during the handshake - the sending server
should not have seen the request unless they count the initial contact as a
request. It is isn't a very secure connection if the request is sent before
the handshake is completed. Seems kind of weird.
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kevin
Wengert
Sent: Tuesday, June 2, 2015 12:24 PM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: Socket Reset
Good Morning,
I've got a problem that I haven't seen before that is causing me fits.
I'm sending a vendor information about deliveries via HTTP. Using the same
port, I can request copies of the delivery receipts that I then email to
customers. It's important to note that on the same port, if I send an empty
request, if their webservice has an xml document describing an order
delivery, called an orderSummaryEvent, it will send that document as a
response.
Now, the problem. For each orderSummaryEvent, a unique id is included
that I use to get the copy of the delivery receipt. My customer reported
that one of these delivery receipts was missing, and I checked the debug
log, which contained this error:
(GSKit) I/O: A connection with a remote socket was reset by that socket.
ssl_error(406): (GSKit) I/O: A connection with a remote socket was
reset by that socket.
SetError() #30: SSL Handshake: (GSKit) I/O: A connection with a remote
socket was reset by that
At that point, it looks like my xml that requested the delivery receipt
was compromised. Normally, I can see the request in the debug log, but now
it doesn't show with the "senddoc(): entered" line in the debug line.
Instead, there is no data there, so the web service thinks I'm looking for
an orderSummaryEvent, and happily sends me one. This procedure has no idea
what to do with it and it gets lost.
I'd like to trap the remote socket reset error and retry the request
again.
Any ideas how to go about doing that?
Thanks,
Kevin Wengert
<http://t.signauxsix.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6
v5dlPl
N7fRYjzd7ldzW4X9Hrn1pctGFW4mgbKq1k1H6H0?si=5663939049816064&pi=6550b2c
d-43c3
-4845-9c81-42099cac9078>
----------------------------------------------------------------------
- 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
-----------------------------------------------------------------------