RE: HTTPAPI 1.9 pre3

[Marc <marc@xxxxxxxxxxxxxxxx>]

Sender: Marc <marc@xxxxxxxxxxxxxxxx>

At 02:21 PM 3/10/2004 -0600, you wrote:
> That was the original behavior in versions 1.7 and earlier of HTTPAPI.
> However, we had problems with data getting truncated with some servers --
> they'd close their sockets and their linger times were set low, so the
> data would get lost when they got closed.
>
> With the current method, that theoretically won't happen, because HTTPAPI
> initiates the closing instead of the web server.
>
> I wish I could figure out why HTTPAPI doesn't think that the document is
> complete?  But, of course, when I run it it works perfectly.  That makes
> it very difficult to troubleshoot.
>
> Unless someone who has the problem could give me access to their iSeries
> for me to test it out on?  I wonder if I loaded it on www.Netshare400.com
> if I could reproduce your problem there... hmm...


FWIW, I ran into a similar problem with a site that would hang without the 
close:

https://epayhipvar.paymentech.net/authorize

They require the following in their headers: (though if you omit them they 
have an XML response which says you have the wrong mime version)

MIME-Version: 1.0
Content-type: application/PTI21
Content-transfer-encoding: text
Request-number: 1
Document-type: Request

And sending <Request></Request> should be enough to trigger the error 
message (and the problem).

I've chalked it up to something strange on their side, as the amount of 
data reported as returned by them is different depending on whether I 
supply the close or not.  Anyway, just thought I'd mention it in case it 
might be related to this problem.

Rgds,

Marc


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