Send Ftpapi mailing list submissions to
ftpapi@xxxxxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://scottklement.com/mailman/listinfo/ftpapi
or, via email, send a message with subject or body 'help' to
ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
ftpapi-owner@xxxxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ftpapi digest..."
Today's Topics:
1. RE: NULL CHARACTERS AT THE END OF STRING FIELD (Mike Krebs)
2. HTTPAPI - Field Length greater than 65535 (Kim Tay)
3. Re: HTTPAPI - Field Length greater than 65535 (Scott Klement)
4. Fwd: HTTPAPI 64K Length Issue (Scott Klement)
5. Re: Fwd: HTTPAPI 64K Length Issue (Scott Klement)
6. RE: Consuming a web service that requires certificate-based
authentication (Nick Townsend)
----------------------------------------------------------------------
Message: 1
Date: Thu, 2 May 2013 17:54:31 -0500
From: Mike Krebs <mkrebs@xxxxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: NULL CHARACTERS AT THE END OF STRING FIELD
Message-ID: <3DF08BA25872B644A1421B9F085B18299F48B1ED2B@xxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
To make sure I understand. You are passing 100 chars to a program that builds XML and the parm in that XML has x'00' filling out the 100 chars. Did you check the parm on the way in to the program? It probably has the x'00' in it too.
If so, how are you calling the program?
x'00' can occur for a couple of reasons. One is the 32 char rule for passing parameters to CLP. If you do this in a CLP:
pgm parm(&my100char)
dcl &my100char *char 100
and then call the program like this: call mypgm '1'
You can end up with this:
F1404040 40404040 40404040 40404040
40404040 40404040 40404040 40404040
40000000 00000000 00000000 00000000
etc
Not sure if that is what you are seeing but a common problem that causes x'00'.
Fixes for this are elsewhere and include using commands over the top of the CLP or initializing the variable you pass to the RPG yourself.
I think this will point you in the right direction.
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of gilles.renne@xxxxxxxxxxxxxxxxx
Sent: Thursday, May 02, 2013 9:40 AM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: NULL CHARACTERS AT THE END OF STRING FIELD
Hi
i consume a web service in which i have a STRING 100 characters long
if i send less that 98 charracters Marshaller_toString function add NULL at
the end then http return a bas request error
how can i porevent this NULL ?
regards
Gilles Renne
here is what i retrieve from httpapi_debug
and i send only "F0101Z1Payment Terms Code Invalid3352TRAR" on last
parameter.
parameter in entry
This message contains confidential information. To know more, please click on the following link: http://disclaimer.bureauveritas.com
------------------------------
Message: 2
Date: Thu, 2 May 2013 17:26:18 -0700
From: Kim Tay <johnny.tay@xxxxxx>
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: HTTPAPI - Field Length greater than 65535
Message-ID: <307EF448-280C-41DB-93E7-CFF88AF56117@xxxxxx>
Content-Type: text/plain; charset=us-ascii
Hi,
I met with an issue generating the Request XML and its length is greater than 64K. I look at the O/S and it show v6r1 L00 but it does not support beyond the 64K field length! What is the next possible solution? I saw some article by Scott using the %alloc, will this work and how! Hope someone can post an example that uses field beyond 64K.
Thanks!
------------------------------
Message: 3
Date: Thu, 02 May 2013 22:36:02 -0500
From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: HTTPAPI - Field Length greater than 65535
Message-ID: <518330A2.2010005@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
At V6R1, RPG supports larger fields than 65535. Simply declare one
that's larger than that.
You say "it does not support beyond the 64k field length". What are
you referring to, here? If you are truly at V6R1 (and not compiling to
an older release) than both RPG and HTTPAPI should support fields larger
than 64k. Can you be specific about what problem you're having, and
where you are having it?
Thanks!
On 5/2/2013 7:26 PM, Kim Tay wrote:
Hi,
I met with an issue generating the Request XML and its length is greater than 64K. I look at the O/S and it show v6r1 L00 but it does not support beyond the 64K field length! What is the next possible solution? I saw some article by Scott using the %alloc, will this work and how! Hope someone can post an example that uses field beyond 64K.
Thanks!
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
------------------------------
Message: 4
Date: Fri, 03 May 2013 09:41:35 -0500
From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Fwd: HTTPAPI 64K Length Issue
Message-ID: <5183CC9F.8050808@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
This reply was sent to me privately.. please keep your conversations
on the mailing list so that everyone can participate and benefit from
them. Thanks!!
-------- Original Message --------
Subject: HTTPAPI 64K Length Issue
Date: Fri, 3 May 2013 06:39:36 -0700
From: Kim Tay <johnny.tay@xxxxxx>
I was using HTTPAPI in v6r1 L00 and defined a field "REQDATA A
LEN(200000)", but it does not hold the string beyond 65535 and it does
not complained. The only error I got is went I sent the request and I
will get HTTP error because the Request was not well formed. Either the
way I defined the field. By the way s there another way of defining a
field beyond 64K? Appreciate any hints! Thanks!
-------------- next part --------------
This reply was sent to me privately.. please keep your conversations
on the mailing list so that everyone can participate and benefit from
them. Thanks!!
-------- Original Message --------
Subject: HTTPAPI 64K Length Issue
Date: Fri, 3 May 2013 06:39:36 -0700
From: Kim Tay [1]<johnny.tay@xxxxxx>
I was using HTTPAPI in v6r1 L00 and defined a field "REQDATA A
LEN(200000)", but it does not hold the string beyond 65535 and it does
not complained. The only error I got is went I sent the request and I
will get HTTP error because the Request was not well formed. Either the
way I defined the field. By the way s there another way of defining a
field beyond 64K? Appreciate any hints! Thanks!
References
1. mailto:johnny.tay@xxxxxx
------------------------------
Message: 5
Date: Fri, 03 May 2013 10:01:13 -0500
From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Fwd: HTTPAPI 64K Length Issue
Message-ID: <5183D139.8050008@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kim Tay,
Please post your code and an HTTPAPI debug/trace/log file so that we can
get a better understanding of what's happening in your program.
Thanks!
On 5/3/2013 9:41 AM, Scott Klement wrote:
This reply was sent to me privately.. please keep your conversations
on the mailing list so that everyone can participate and benefit from
them. Thanks!!
-------- Original Message --------
Subject: HTTPAPI 64K Length Issue
Date: Fri, 3 May 2013 06:39:36 -0700
From: Kim Tay [1]<johnny.tay@xxxxxx>
I was using HTTPAPI in v6r1 L00 and defined a field "REQDATA A
LEN(200000)", but it does not hold the string beyond 65535 and it does
not complained. The only error I got is went I sent the request and I
will get HTTP error because the Request was not well formed. Either the
way I defined the field. By the way s there another way of defining a
field beyond 64K? Appreciate any hints! Thanks!
------------------------------
Message: 6
Date: Fri, 3 May 2013 16:22:07 +0100
From: Nick Townsend <Nick.Townsend@xxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: Consuming a web service that requires certificate-based
authentication
Message-ID:
<C4FA6E678AA79E4C8AE7F2209C897C1936FE2BD324@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=WINDOWS-1252
Scott,
Just to verify: You are giving HTTPAPI an application ID via https_init(), and you have created/configured that appid in the digital certificate
manager to include a client-side certificate to be used for authentication. Correct?
Yes. The local-side cert details that appear in the logs are definitely from the new cert that I created for this app.
I don't understand the comment about "the answer seemed to be that
HTTPAPI didn't support it. " Doesn't support what? Client-side
certificates? HTTPAPI has always supported that. (It doesn't require any programming to support this -- it's just a configuration in the Digital
Certificate Manager.)
The thread that I found on the archive that looked as if it might possibly relate to the same subject is http://scottklement.com/archives/ftpapi/201104/msg00044.html.
The only difference between the request that worked and the one that didn't was that authentication had been switched on on the server, so obviously the server is responding differently. Unfortunately the PC developers don't seem to have any understanding of what is actually going on under the covers, all they know is that they change a setting in a config file to say that they want to authenticate using certificates.
I haven'tbeen able to find any GSKit-related APARs or PTFs that sound like the same thing, so it looks like running traces to see what's different is the next step. I'll keep you posted if I make any progress.
Nick
_______________________________
Nick Townsend
Technical Architect
Endsleigh Insurance Services Limited
Telephone: +44 (0)1242 866426
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: 02 May 2013 17:24
To: HTTPAPI and FTPAPI Projects
Subject: Re: Consuming a web service that requires certificate-based authentication
Nick,
Just to verify: You are giving HTTPAPI an application ID via https_init(), and you have created/configured that appid in the digital certificate manager to include a client-side certificate to be used for authentication. Correct?
If so, I believe that the "peer not recognized" is a bug in the IBM
GSKit code, it's not something you or I can fix. From your log, it's
clear that you are_are_ successfully connecting to the HTTP server, and
successfully negotiating SSL (handshake). So the GSKit has already
determined that the connection is okay. Then, part way through, it's
determining that the SSL message is corrupt... 410 =
GSK_ERROR_BAD_MESSAGE. As if what the server is sending is an invalid
message.
I would try googling GSK_ERROR_BAD_MESSAGE and see if you can find a PTF. If not, I'd say the problem is on IBM's end in this case. If it were occurring during the connection start (handshake) then I could see this possibly being a misconfiguration of some sort... but, it's not.
I don't understand the comment about "the answer seemed to be that
HTTPAPI didn't support it. " Doesn't support what? Client-side
certificates? HTTPAPI has always supported that. (It doesn't require any programming to support this -- it's just a configuration in the Digital Certificate Manager.)
On 5/1/2013 11:50 AM, Nick Townsend wrote:
Hi,
I am using HTTPAPI to consume a .net web service written by our PC
developers. I've done this before without any problems, but they now
want to use certificate-based authentication rather than basic HTTP
authentication which we have used before. I generated a new cert to
use for testing and provided the PC guys with it together with our
internal CA cert, both of which they say they have loaded at their
end. When I fire the web service with authentication switched off it
works fine, but when authentication is on everything appears OK in the
log until the response comes back from the web service, when GSKit
throws a 410 error. I've attached the logs with authentication on and
off, and the code of the test rig that I'm using.
I've searched the archive and some time ago someone did ask about using
certificates for authentication, but the answer seemed to be that
HTTPAPI didn't support it. I Googled a bit and the Wikipedia entry for
TLS has descriptions of the "Simple TLS handshake" and the
"Client-authenticated TLS handshake" which suggest that there are extra
exchanges that take place during the setup of an authenticated
conversation, but if that was the problem here I would have expected
the error to occur before things got as far as the sending of the
request.
I assume that GSKit must provide a way of doing whatever is required to
authenticate using certificates, but looking at the API documentation
has left me completely baffled. Can anyone see what I'm doing wrong or
point me in the right direction to get this working?
Thanks,
Nick
_______________________________
Nick Townsend
Technical Architect
Endsleigh Insurance Services Limited
Telephone: +44 (0)1242 866426
__________________________________________________________________
Information contained in this email is intended for the use of the
addressee only, and is confidential and may be the subject of legal
professional privilege. Any dissemination, distribution, copying or use
of this communication without prior permission of the addressee is
strictly prohibited. If you have received this email in error please
notify the Help Desk at Endsleigh on 01242 866866.
The contents of an attachment to this email may contain software
viruses, which could damage your computer system. While Endsleigh has
taken every reasonable precaution to minimise this risk, we cannot
accept liability for any damage, which you sustain as a result of
software viruses. You should carry out your own virus checks before
opening the attachment.
http://www.endsleigh.co.uk
Endsleigh Insurance Services Limited is authorised and regulated by the
Financial Services Authority. This can be checked on the FSA Register
by visiting its website at www.fsa.gov.uk/register/
Company number: 856706
Registered in England at Shurdington Road, Cheltenham Spa,
Gloucestershire GL51 4UE
----------------------------------------------------------------------
- This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
Information contained in this email is intended for the use of the addressee only, and is confidential and may be the subject of legal professional privilege. Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited. If you have received this email in error please notify the Help Desk at Endsleigh on 01242 866866.
The contents of an attachment to this email may contain software viruses, which could damage your computer system. While Endsleigh has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage, which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.
http://www.endsleigh.co.uk
Endsleigh Insurance Services Limited is authorised and regulated by the Financial Services Authority. This can be checked on the FSA Register by visiting its website at www.fsa.gov.uk/register/
Company number: 856706
Registered in England at Shurdington Road, Cheltenham Spa, Gloucestershire GL51 4UE
------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list digest. To unsubscribe, go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
End of Ftpapi Digest, Vol 79, Issue 4
*************************************