[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HTTPAPI and SSL
Scott Klement
<sk@scottklement.
com> To
Sent by: HTTPAPI and FTPAPI Projects
ftpapi-bounces@li <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
sts.scottklement. cc
com
Subject
Re: HTTPAPI and SSL
05/18/2011 12:16
PM
Please respond to
HTTPAPI and
FTPAPI Projects
<ftpapi@xxxxxxxxx
ttklement.com>
Oscar,
> The log is below. It sanitized it first. To me is shows that I contacted
> the app server with the message I constructed in my RPG program.
>>It also shows that message being sent. (Assuming that message is 827
>>bytes long.) It also shows the server stating that it successfully
>>received 827 bytes from HTTPAPI. (That's what the "200 OK" means...)
>>so what do you think was in those 827 bytes, unless it was the XML
>>document that the log shows?
It is the message I constructed that is in those 827 bytes I've seen it. I
didn't mean to imply that it wasn't the message.
> curious about the CommSSL_Read error however.
>>There is an "optional" response message that might or might not be sent
>>by the server. HTTPAPI waits a fraction of a second for that optional
>>response, and if it's not sent, it times out, and proceeds with the rest
>>of the process.
>>It's not an error. It's a normal response.
>>However, due to the extraordinary number of times I've been asked this
>>question, I removed that message from the log file. If you were using
>>the current version of HTTPAPI (your copy is very old) you would not
>>have seen this.
I've got the latest version and placed on our DEV box this morning. Sadly
this
particular process can only run in test/prod.
> Later in the log I can see
> that the app server responded with the message that the request XML is
> missing.
>>Perhaps instead of referring to the whole XML message, as you seem to
>>assume, it's actually referring to the contents of the <requestXML>
element?
>>In the log, it shows that the <requestXML> element contains
>>"***PAYLOAD_REMOVED***".
>>I would assume that's something you did when you sanitized your log
>>file? But, it also perfectly matches the error message you're getting.
>>So if that is from the sanitization, I'd say the contents of the
>><requestXML> are invalid. Perhaps you forgot to use entities for special
>>characters like <, > and & -- that would cause the payload to look like
>>it's part of the SOAP message, instead of a payload.
>>Hard to say, though... since I can only imagine what might be there.
***PAYLOAD_REMOVED*** is where I removed the data that was in the
requestXML.
The information I removed is valid XML. I did not however translate
the requestXML to escape the <,> and & and replace with &,<,>. This
rings some bells and may be the key to what I am missing.
> As I stated, I feel that this means the SSL communication is working.
> (Although I am curious why the AS400 is accepting a self signed cert
> where it doesn't trust the CA).
>>The SSL communication is 100% definitely working.
>>By default, HTTPAPI accepts any SSL connection, as long as the
>>cryptography can be negotiated. It does not do strict certificate
>>validation unless you call https_strict(*ON) to force a strict
>>validation of certificates.
>>Though, since you're using an old version of HTTPAPI, you won't have the
>>https_strict() feature. Please update your copy.
Downloaded the latest version. I will need to update so I can use
the https_strict(*ON) parameter. Just so I understand correctly, this
means that the certificate presented by the server will need to be
chained to a ROOT CA that I designate as trusted in DCM? We are in
the process of setting up a corporate CA for internal use.
> On the java side it seems simple enough. This is the method
> I exposed as a web service. The code executes because the system.out
prints
> but the value of requestXML is empty. I'm stumped. Any ideas are really
>>Exactly. So it's not that your document isn't sent. It's that the
>>requestXML element is empty. There's a mistake in the way the
>>requestXML element of your XML document is being constructed.
>>HTTPAPI knows nothing whatsoever about the data it's sending. As far as
>>it's concerned, it's just a string of bytes. It will send that string,
>>as-is, to the server.
>>So the error can't be in HTTPAPI. The error is almost certainly in the
>>code that's creating the contents of that string. I might even be able
>>to tell you what the mistake is, if I saw the XML data -- but you
>>removed it from the file, so I can't.
I think you are on to something with the contents of the requestXML string
being incorrect. I am going to try and escape the XML in it and see. No
time
today will try tomorrow. Thanks for taking the time to answer!
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------