Post Command Problem

Dave Cragg dave.cragg at lacscentre.co.uk
Thu Nov 13 07:18:51 EST 2008


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.
>



More information about the use-livecode mailing list