[REBOL] Re: This is dumb (don't do it!)
Dixit [EMAIL PROTECTED] (18.29 30.01.2004): >Hi Hallvard, >[...] >I tried to find a foolproof way of doing this for something we needed or >REBOL.org. I failed. >[...] >If you find a better solution, please let me know! Well, I don't know if this will work, it's only an idea: You keep two CGI scripts, C1 and C2. C1 redirects to C2 with a 302 HTTP header. Now if C1 is unaffected by the browser suddenly giving up and passing on to somewhere else, it may quietly do its background task without anyone waiting. What the other end user will see is only what is written by C2. Does web servers somehow detect if requesting browsers no longer listen? And if so, do they kill CGI child processes? I wouldn't believe so. Just a thought HY Prætera censeo Carthaginem esse delendam -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: This is dumb (don't do it!)
Hi Hallvard, > OK, the reason I did this, is I wonder if I can have a CGI script close the > connection to user and then continue processing some data afterwards. So that > the web user wouldn't have to wait ages for the browser to tell him the page > has finished loading when actually it is. > > The following CGI script didn't do the trick. Anyone got an idea? I tried to find a foolproof way of doing this for something we needed or REBOL.org. I failed. Part of the problem is that you can't control when the server sends the data. If you only have a small amount of data (not enough to fill whatever is a block transmitted across the Internet) that probably won't be until your CGI quits. I tried various cunning schemes, like explicitly setting a Content-length header and then sending more data than that (to force a block transmit). They didn't work. In the end, in our case, as we only need to run some non-user background stuff occasionally, I added some rudimentary code to check that the request is not from a human being. So we only run the "background task" if the referrer is a bot. I don't mind keeping them waiting a couple of seconds once in a while. And the "background task" is self-limiting -- it'll stop after a couple of seconds, whether it's finished or not. The site is hit by bots hundreds of times a day -- so the background task never has to wait long to resume. This kludge works because the background processing we need to do is not related to the current message -- it's the equivalent of an occasional recycle to keep things current. Of course, we have to check that the background task isn't already running (if we get two bots that trigger it in the same second or so). If you find a better solution, please let me know! Sunanda. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: This is dumb (don't do it!)
OK, the reason I did this, is I wonder if I can have a CGI script close the connection to user and then continue processing some data afterwards. So that the web user wouldn't have to wait ages for the browser to tell him the page has finished loading when actually it is. The following CGI script didn't do the trick. Anyone got an idea? HY Script: #!/usr/local/bin/rebol -cs REBOL [] set-net [...] print "Content-Type: text/html^/" print [] probe system/options/cgi print reverse [] close system/ports/output wait 30 ; seconds print "HEHE" send [EMAIL PROTECTED] "done" Dixit Gregg Irwin (18.24 27.01.2004): >Hi Hallvard, > >HY> close system/ports/output > >HY> ...why does it make rebol crash? Shouldn't it simply hang or >HY> something? > >I think so. I'll log it as a bug for the View 1.3 project. > >-- Gregg > >-- >To unsubscribe from this list, just send an email to >[EMAIL PROTECTED] with unsubscribe as the subject. Prætera censeo Carthaginem esse delendam -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: This is dumb (don't do it!)
Hi Hallvard, HY> close system/ports/output HY> ...why does it make rebol crash? Shouldn't it simply hang or HY> something? I think so. I'll log it as a bug for the View 1.3 project. -- Gregg -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
