Dave
As you are getting back data (even if truncated), I'm guessing that
Rev (libUrl) isn't seeing any error. But just to confirm, are you
checking "the result" after each post? The normal "result" for this
kind of problem is "socket closed before end of file".
It might be useful to check that it isn't a basic problem on the
server side such as setting a wrong Content-length header. You could
do this by either using libUrlSetLogField to log all requests/
responses, or if you can detect programmatically when a problem has
occurred, use libUrlLastRHHeaders() to get the response from the
server. (You'd need to do this before the next post command)
As a start, it would let us know whether the server is using Content-
length, or chunked transfer encoding, or neither. (It sounds like
neither)
To answer your very original question, there is no limit imposed on
the amount of data returned by a post command.
Cheers
Dave
On 13 Nov 2008, at 11:19, Dave wrote:
Hi,
I read records from a database, format them, and add them to a block
of data. There is a blocking factor variable, it is set to 200, so I
read 200 records from the database, block them into one big block
and send it to the server via a "post" command. The Server then
sends a response which can be variable in length, the response is in
XML format. This process works well 99% of the time, but sometimes,
(and this can be reproduced if the right data (or the wrong data in
this case!) is present in the database). When this happens the
response from the server is truncated in the middle of an XML node.
As far as I can tell the difference is that by chance, a group of
200 records has caused the response to be over a certain size.
If I set the BlockingFactor to 50, the problem goes away, but this
causes a major slowdown.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
