[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ftpapi Digest, Vol 79, Issue 6
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@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
>>> *************************************
>>
>>
>>
>> -----------------------------------------------------------------------
>> 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. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------