Post Command Problem
dave.cragg at lacscentre.co.uk
Thu Nov 13 07:18:51 EST 2008
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
To answer your very original question, there is no limit imposed on
the amount of data returned by a post command.
On 13 Nov 2008, at 11:19, Dave wrote:
> 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.
More information about the use-livecode