post command in 1.1.1 acting weird
dcragg at lacscentre.co.uk
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
>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
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