post command in 1.1.1 acting weird

Dave Cragg dcragg at
Sun May 4 05:10:01 CDT 2003

At 8:43 pm -0700 3/5/03, kee nethery wrote:
>I'm doing a post to an internal web site. Basically I post, it
>executes the CGI, I get back the results in XML, and I parse and
>This used to be 100% reliable, now it is way too unpredictable.
>It worked for me this afternoon and now several hours later, it is
>not returning results. When I hit the same web page with a browser
>from the machine running revolution, no problems, instant results
>every time.
>1. Did something change in 1.1.1 without a rev change and my version
>of revolution somehow was updated to the flakey code?


>2. Is there some kind of expected response time to a post and if the
>response is just a tad too slow, the post returns before it gets
>results? If so can I lengthen the wait time for a response from a

Judging from your description below, I don't think this is the issue.

>I'm running MacOS X, but another on Win NT has been seeing the same
>thing for several weeks.

Has anything changed on your network? Firewalls, proxy servers, etc?

>I've restarted Revolution, that seemed to have no effect.

A clue!!! (See below)

>I'm looking at
>      postURL y,x
>and when it gets to the statement where it checks
>      if lvBlockingUrl is empty or lvBlockBypass is true then
>and at that moment lvBlockingUrl contains a URL and lvBlockBypass is
>empty so it skips that whole section and goes to
>      else ##blocked by previous request
>which causes it to reply with empty

If lvBlockingUrl is not empty then it means a previous request has 
not completed (you should see  a message to this effect if you check 
the result of the failed post request).

Prior to the post url statement, does your script make any other url 
request? Or, is there any chance the post url statement gets called 

>How do I clear a previous request when I know I no longer care about
>it's results? How do I know if there is an unfinished request?

Restarting Rev will clear everything, so it looks like the unfinished 
request was made prior to the post request.

You can also "clear everything" by calling libUrlResetAll. But this 
is an "ejector seat" last resort and should be avoided if possible. 
(It will close *all* open sockets, and clear out any cached urls.)

>URLstatus appears to only apply to FTP transfers. But even if it
>worked for what I need, I don;t see a command for clearing any
>existing requests.

urlStatus works for urls called with "load" commands (non-blocking requests).

>I kind of think the requests are actually completed but the flags
>that say otherwise were caused by the debugging environment
>continuing to execute when it needed to be immediately halted.

Instead of using the debugging environment, try setting a field to 
log what libUrl is doing:

    libUrlSetLogField the long id of field "myLog"

It will show the request and reply headers of any http requests and 
may give a hint to what is happening.

You could also try updating to the latest libUrl version.


(Note that version shipping with the current Rev 2.0 beta is slightly 
more recent than the version posted here.)


More information about the use-livecode mailing list