RE:

["Ian Patterson" <ian@xxxxxxxxxxxxxxxxxxxx>]

Sender: "Ian Patterson" <ian@xxxxxxxxxxxxxxxxxxxx>

OK, we have found where our problem lies (but not the solution).

First of all, can I clarify how we are using the HTTPAPIR4 to put Scott's
mind at rest.
We are testing methods, not writing an application. We are still unsure if
the AS/400 can actually do what we want, prior to launching into serious
coding. As a result we have kept the original HTTPAPIR4 to one side and
stuffed our modified version with all sorts of debug code and other things
trying to get connections to a secure server with peculiar habits. Scott is
absolutely right in stating that modifying the HTTPAPIR4 is a bad idea. If
we eventually get the comms sessions to work (& understand Scotts API at the
same time) them the 'real' project would use unmodified code from the API.

So, here is what we found:
We have a client on the AS/400 trying to retrieve data from an external very
secure (SSL 128 bit) server (not AS/400) - call it Server A
Small amounts of all data types could be received OK
Large amounts of ascii (e.g. XML) data could be received OK
Larger binary files (in our case PKZips) were being truncated (to about 4K)

We then used our same client to download the same binary file from another
server (SSL 128bit) - Server B
This time everything OK

We then compared the HTTP headers of the two servers: (relevant bits only)
Server A : HTTP/1.1, Server:Apache, Connection: close,
host:testserver.co.uk, Transfer-Encoding:chunked, Content Type: archive/zip
Server B : HTTP/1.1, Server:Apache, Connection: close, Content Type:
application/zip

Note - there was chunked encoding on Server A, where we get the truncated
files problem.

So we then commented out the chunked encoding in HTTPAPIR4 (sorry Scott -
just testing :-) ) and it worked OK, no truncation
We have to assume that Server A is handling the HTTP session OK because (1)
its the main banking e-commerce server in the UK, and (2) our PC program
client doing exactly the same works OK.

Therefore our problem is to do with the chunked encoding. Is there anything
we are doing wrong in the implementation of the API - i.e. are there other
parameters that may need to be set for this to work ?

I am now out of the Office until Monday. I would be happy to do any tests
required on Monday to help resolve the problem (if it is a problem..).
Regards

Ian Patterson
Grange Management Consultants
tel 01947 880458
www.grange-systems.co.uk




-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx]On
Behalf Of Scott Klement
Sent: 27 August 2003 22:10
To: ftpapi@xxxxxxxxxxxxx
Subject: RE:


Sender: Scott Klement <klemscot@xxxxxxxxxxxx>


Modifying http_url_get() or http_url_post() in order to write to your
main program is a really bad idea.   HTTPAPI is designed to be easy to
upgrade -- you can just delete the old library and install the new one
and then everything should work.

When you modify http_url_** in this manner, you lose this capability.  It
also means that I cannot provide fixes to the problems you encounter,
even if they are problems with my code, since the fixes are supplied
in the form of an upgrade.

The point behind the various "raw" routines in HTTPAPI and FTPAPI is to
allow you to integrate your own programs WITHOUT having to modify the
main source or break upgradability.  The EXAMPLE5 member in HTTPAPI
provides a sample program where http_url_post_raw() is used to post data
to a web server, and retrieve the response into a variable called
"retdata".

On occasions where you do need to modify HTTPAPIR4 itself, it should be
with a change that can be contributed back to the project for everyone
to use, and be a new feature of the project.   That way, it'll also be
included when you need to upgrade.


On Wed, 27 Aug 2003, Ian Patterson wrote:
>
> We modified the http_url_** routines to bypass the IFS, as we wanted the
> data straight into our main program for processing.
> However.... we are not competant yet with RPG4 and could have made the
usual
> daft mistakes in our coding, hence my reticence in suggesting a reason for
> the apparent probems. But that does not explain why we get different
results
> from different servers. Hence a look at the headers tomorrow.
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------