[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: HTTPAPI 64K Length Issue (Kim Tay)
Hi Guys,
I resolved the issue! It looks like we cannot mixed the Field with 64K
limitation and Field that is > 64K.
The problem I was having was due to populating the Sender Request Field
that is declared to be 1,000,000 bytes.
The previous code was ...
0111.00 D reqdata S 1000000A varying(4)
0112.00 D reqHeader S 2000A
0113.00 D reqClaimDATA S 1000000A varying(4)
0114.00 D reqLineDATA S 1000000A varying(4)
0857.00
0858.00 // PIECE THE HEADER, BODY AND FOOTER INTO REQUEST
0859.00 reqData = %trim(reqHeader)
0860.00 + %trim(reqClaimData)
0861.00 + %trim(reqLineData)
0862.00 + %trim(reqFooter);
0863.00 http_debug(*ON);
0864.00
Mixing the field reqheader (<64K) and other field (>64K) may have
caused it to be 64K limitation! So I changed it to
1216.00
1217.00 // PIECE THE HEADER, BODY AND FOOTER INTO REQUEST
1218.00 reqData = %trim(reqHeader);
1219.00 reqData = %trim(reqData) + %trim(reqClaimData);
1220.00 reqData = %trim(reqData) + %trim(reqLineData);
1221.00 reqData = %trim(reqData) + %trim(reqFooter);
1222.00
and it worked! Thank you everyone!
But now I have issue on the Incoming Data which I declared the field >
64k. The codes are
0052.00 D Incoming PR
0053.00 D respData 1000000A varying(4)
0054.00 D depth 10I 0 value
0055.00 D name 1024A varying const
0056.00 D path 24576A varying const
0057.00 D value 1000000A varying(4)
0058.00 D attrs * dim(1000000)
0059.00 D const options(*varsize)
0060.00 D*
1231.00 rc = http_url_post_xml(ccURL
1232.00 : %addr(reqData:*DATA)
1233.00 : %len(%trim(reqData))
1234.00 : *NULL
1235.00 : %paddr(Incoming)
1236.00 : %addr(respData)
1237.00 : HTTP_TIMEOUT
1238.00 : HTTP_USERAGENT
1239.00 : 'text/xml; charset=utf-8'
1240.00 :
'[1]http://tempuri.org/McKessonAudit/Claim/Audit');
2163.00
2164.00 P Incoming B
2165.00 D Incoming PI
2166.00 D respdata 1000000A varying(4)
2167.00 D depth 10I 0 value
2168.00 D name 1024A varying const
2169.00 D path 24576A varying const
2170.00 D value 1000000A varying(4)
2171.00 D attrs * dim(1000000)
2172.00 D const options(*varsize)
2173.00
2174.00 D atof PR 8F extproc('atof')
2175.00 D string * value options(*string)
2176.00
2177.00 /free
2178.00 //if %trim(value) <> *BLANK;
2179.00 respData = %trim(respData) + %trim(value);
2180.00 //endif;
2181.00 /end-free
and I got the following message ... All I wanted to do is to receive
the return XML into the variable respDATA.
"Length of varying length variable is out of range. " which is
pointing to either value or respData
Program: HUT4954 Library: JHHJTAY Module: HU
2175 D string * value options
2176
2177 /free
2178 //if %trim(value) <> *BLANK;
2179 respData = %trim(respData) + %trim(value); <<<
Error >>>>
2180 //endif;
2181 /end-free
2182 P E
Thanks!
On May 6, 2013, at 9:09 AM, [2]ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
wrote:
Send Ftpapi mailing list submissions to
[3]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: Fwd: HTTPAPI 64K Length Issue (Kim Tay)
2. RE: Fwd: HTTPAPI 64K Length Issue (Mike Krebs)
--------------------------------------------------------------------
--
Message: 1
Date: Sun, 5 May 2013 10:48:54 -0700
From: Kim Tay <johnny.tay@xxxxxx>
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Fwd: HTTPAPI 64K Length Issue
Message-ID: <A3F80212-5A07-466A-9938-7129A43FB316@xxxxxx>
Content-Type: text/plain; charset=us-ascii
All,
I change the statement to
0111.00 D reqdata S 200000A varying(4)
0112.00 D reqHeader S 2000A
0113.00 D reqClaimDATA S 200000A varying(4)
0114.00 D reqLineDATA S 200000A varying(4)
0115.00 D reqFooter S 200A
rc = http_url_post_xml(ccURL
: %addr(reqData:*DATA)
: %len(reqData)
: *NULL
: %paddr(Incoming)
: %addr(respData)
: HTTP_TIMEOUT
: HTTP_USERAGENT
: 'text/xml; charset=utf-8'
: 'http://tempuri.org/McKessonAudit/Claim/Audit');
and I got the error ...
The call to HTTP_URL_P ended in error (C G D F).
Length of varying length variable is out of range.
Any help is appreciated! Thanks!
On May 5, 2013, at 10:00 AM, ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
wrote:
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: Ftpapi Digest, Vol 79, Issue 6 (Kim Tay)
--------------------------------------------------------------------
--
Message: 1
Date: Sat, 4 May 2013 10:15:42 -0700
From: Kim Tay <johnny.tay@xxxxxx>
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Ftpapi Digest, Vol 79, Issue 6
Message-ID: <F193215A-9C74-4A60-951C-9DEC6067A4BB@xxxxxx>
Content-Type: text/plain; charset=us-ascii
Thomas,
Thanks! But when I did the strdbg all I can see the content of
reqData up to 65535 and nothing more than that. I also write to a
streamfile to make sure that it can support beyond 65535 and it
still cut off at 65535. Hav e encountered any issue like this. I
checked the RPG compiler and it showed v6r1.
Thanks!
On May 4, 2013, at 10:00 AM, ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
wrote:
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: Ftpapi Digest, Vol 79, Issue 4 (Thomas Raddatz)
--------------------------------------------------------------------
--
Message: 1
Date: Sat, 04 May 2013 17:38:23 +0200
From: Thomas Raddatz <thomas.raddatz@xxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Ftpapi Digest, Vol 79, Issue 4
Message-ID: <51852B6F.4090307@xxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kim,
For characters fields larger than 64k, you need to add 4 (instead of
2) to
the base address of the field, when you pass it to
http_url_post_xml().
But since you are on V6R1 or higher you even better use
%addr(reqData:
*DATA) to pass the field to http_url_post_xml():
http_url_post_xml(ccURL
: %addr(reqData: *DATA)
: %len(reqData)
...
);
Thomas.
Am 04.05.2013 03:13, schrieb Kim Tay:
2. HTTPAPI - Field Length greater than 65535 (Kim Tay)
The Error Message is "HTTP/1.1 400 Bad Request"
I defined the send request field as " D reqdata S A
LEN(200000) VARYING(4).
Populate reqdata with more than 65535 but it seems to take more than
65535!
On May 3, 2013, at 10:00 AM, ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
wrote:
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@xxxxxxxxxxxxxxxxxxxxxxxx
.uk>
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
*************************************
--------------------------------------------------------------------
---
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
------------------------------
--------------------------------------------------------------------
---
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 6
*************************************
------------------------------
--------------------------------------------------------------------
---
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 7
*************************************
------------------------------
Message: 2
Date: Mon, 6 May 2013 11:09:15 -0500
From: Mike Krebs <mkrebs@xxxxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: Fwd: HTTPAPI 64K Length Issue
Message-ID:
<3DF08BA25872B644A1421B9F085B18299F48B1EF27@xxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
What version of HTTPAPI are you using?
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kim Tay
Sent: Sunday, May 05, 2013 12:49 PM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Fwd: HTTPAPI 64K Length Issue
All,
I change the statement to
0111.00 D reqdata S 200000A varying(4)
0112.00 D reqHeader S 2000A
0113.00 D reqClaimDATA S 200000A varying(4)
0114.00 D reqLineDATA S 200000A varying(4)
0115.00 D reqFooter S 200A
rc = http_url_post_xml(ccURL
: %addr(reqData:*DATA)
: %len(reqData)
: *NULL
: %paddr(Incoming)
: %addr(respData)
: HTTP_TIMEOUT
: HTTP_USERAGENT
: 'text/xml; charset=utf-8'
: 'http://tempuri.org/McKessonAudit/Claim/Audit');
and I got the error ...
The call to HTTP_URL_P ended in error (C G D F).
Length of varying length variable is out of range.
Any help is appreciated! Thanks!
On May 5, 2013, at 10:00 AM, ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
wrote:
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: Ftpapi Digest, Vol 79, Issue 6 (Kim Tay)
--------------------------------------------------------------------
--
Message: 1
Date: Sat, 4 May 2013 10:15:42 -0700
From: Kim Tay <johnny.tay@xxxxxx>
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Ftpapi Digest, Vol 79, Issue 6
Message-ID: <F193215A-9C74-4A60-951C-9DEC6067A4BB@xxxxxx>
Content-Type: text/plain; charset=us-ascii
Thomas,
Thanks! But when I did the strdbg all I can see the content of
reqData up to 65535 and nothing more than that. I also write to a
streamfile to make sure that it can support beyond 65535 and it
still cut off at 65535. Hav e encountered any issue like this. I
checked the RPG compiler and it showed v6r1.
Thanks!
On May 4, 2013, at 10:00 AM, ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
wrote:
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: Ftpapi Digest, Vol 79, Issue 4 (Thomas Raddatz)
--------------------------------------------------------------------
--
Message: 1
Date: Sat, 04 May 2013 17:38:23 +0200
From: Thomas Raddatz <thomas.raddatz@xxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Ftpapi Digest, Vol 79, Issue 4
Message-ID: <51852B6F.4090307@xxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kim,
For characters fields larger than 64k, you need to add 4 (instead of
2) to
the base address of the field, when you pass it to
http_url_post_xml().
But since you are on V6R1 or higher you even better use
%addr(reqData:
*DATA) to pass the field to http_url_post_xml():
http_url_post_xml(ccURL
: %addr(reqData: *DATA)
: %len(reqData)
...
);
Thomas.
Am 04.05.2013 03:13, schrieb Kim Tay:
2. HTTPAPI - Field Length greater than 65535 (Kim Tay)
The Error Message is "HTTP/1.1 400 Bad Request"
I defined the send request field as " D reqdata S A
LEN(200000) VARYING(4).
Populate reqdata with more than 65535 but it seems to take more than
65535!
On May 3, 2013, at 10:00 AM, ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
wrote:
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@xxxxxxxxxxx.endsleigh.
co.uk>
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
*************************************
--------------------------------------------------------------------
---
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
------------------------------
--------------------------------------------------------------------
---
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 6
*************************************
------------------------------
--------------------------------------------------------------------
---
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 7
*************************************
--------------------------------------------------------------------
---
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
------------------------------
--------------------------------------------------------------------
---
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 8
*************************************
References
1. http://tempuri.org/McKessonAudit/Claim/Audit'
2. mailto:ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
3. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------