World: r3wp

view layout [b: box 200x100 navy image help.gif feel [engage: func 
[face action event][if find [over down] action [b/text: mold pick 
face/image event/offset show b]]]]

aha, I meant CGI/HTML imagemap, rather than native View

ah ok.. sorry

I ´d like to have a CGI script to filter my emails at server. My 
ISP uses Cpanel that gives the possibility of use this to send emails 
to file:  |/home/user/cgi-bin/myfilter.cgi. The thing all I get is 
the whole content of each email appended to the CGI script. Anyone 
could help me?

I found a critical bug: when rebol is configured to work as cgi engine 
with SELinux (Security Enhanced Linux), it generates a Segmentation 
Fault. I uses Fedora Core 3 with SELinux to secure the httpd daemon. 
For now, if you want to use rebol as a cgi engine, you must disable 
SELinux. See RAMBO Ticket #-376

Hi, I have some trouble to configure apache to use fastcgi with Rebol/Cmd.

The documentation on rebol.com is really not clear and/or complete. 
Has anyone been successfull withj fastcgi?

I am using apache 2 with module fastcgi

Hello, I finally get FastCGI with rebol/cmd with Lite Speed Web Server, 
but not with Apache.

Anyway, it works, but I still have a problem: in system/options/cgi, 
both 'path-info and 'path-translated are set to none, which prevents 
Magic! to wrks properly as it can not find the requested file (usually 
a *.rhtml) file. In normal CGI, it works well. Is this a bug? In 
that case, I will put it into rambo. Note that I have configure FastCGI 
in compatibility mode.

It looks like the problem does not come from the past-translated, 
but from the 'request-method: with CGI, the values are "GET" or "POST", 
but with FastCGI, the values are "GET^@^@^@^@" or "POST^@^@^@". But 
with lighttpd, no problem. So to make FastCGI rebol scripts work 
with LiteSpeed, we have to update the exemple http://www.rebol.com/docs/words/wread-io.html
as:

read-cgi: func [
        "Read CGI form data from GET or POST."
        /local data buf
    ][

        if found? find/any system/options/cgi/request-method "POST*" [
            data: make string! 1020
            buffer: make string! 16380

            while [positive? read-io system/ports/input buffer 16380][
                append data buffer
                clear buffer
            ]
            return data
        ]

        if found? find/any system/options/cgi/request-method "GET*" [
            return system/options/cgi/query-string
        ]
        test-data ; if in test mode
    ]

LiteSpeed and lighttpd are both amazingly easy to install and configure 
and works fine with Rebol/Cmd in FastCGI (both in compatibility and 
external modes). Furthermore, those web servers are much faster and 
reponsive than Apache 2.0 (2 to 6 times faster!!)

Nice research and summary -- It'd be a good idea to drop that change 
request to RAMBO. That way, it won't get lost
http://www.rebol.net/cgi-bin/rambo.r

Done. I put this as a new issue : http://www.rebol.net/cgi-bin/rambo.r?id=-392&

Reviewed RAMBO Ticket #3862

Well, looks like there is a problem with system/options/cgi

With Apache 2.x (normal CGI), we have: make object! [ 
	server-software: "Apache/2.0.54 (Fedora)" 
	server-name: "localhost" 
	gateway-interface: "CGI/1.1" 
	server-protocol: "HTTP/1.1" 
	server-port: "80" 
	request-method: "GET" 
	path-info: "/sample01.rhtml" 
	path-translated: "/var/www/html/sample01.rhtml" 
	script-name: "/cgi-bin/magic.cgi" 
	query-string: "" 
	remote-host: none 
	remote-addr: "127.0.0.1" 
	auth-type: none 
	remote-user: none 
	remote-ident: none 
	Content-Type: none 
	content-length: none 
	other-headers: [
		"HTTP_HOST" "localhost" 

  "HTTP_USER_AGENT" {Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) 
  Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6} 

  "HTTP_ACCEPT" {text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5} 
		"HTTP_ACCEPT_LANGUAGE" "en-us,en;q=0.5" 
		"HTTP_ACCEPT_ENCODING" "gzip,deflate" 
		"HTTP_ACCEPT_CHARSET" "ISO-8859-1,utf-8;q=0.7,*;q=0.7" 
		"HTTP_KEEP_ALIVE" "300" 
		"HTTP_CONNECTION" "keep-alive" 
		"HTTP_COOKIE" "PHPSESSID=7f84fd7766f23e1462fed550ecbbfda4"
	] 
]

With LiteServer and lighttpd (normal CCI and FastCGI) i have: 
make object! [
	...
	path-info: "" 
	path-translated: none 
	script-name: "/sample01.rhtml"
	...
]

And with lighttpd: 
make object! [
	...
	path-info: none 
	path-translated: none 
	script-name: "/sample01.rhtml"
	...
]

With lighttpd and LiteServer, both path-info and path-translated 
are missing, while 'script-name is the name of the originator html 
file instead of the name of the cgi script (magic.cgi).

So, the question is: is that a bug with rebol?

Rambo ticket submitted

Can anyone help me to configure apache 2.0.x and rebol for FastCGI 
under Windows XP?

yes, although I did it long time ago ....

You should note, that Rebol fastCGI is incomplete (=crippled!), and 
so you can run FastCGI in External mode only, and I regard it being 
a BIG limitation. Pity DocKimbel did not release his FastCGI for 
Uniserve yet ....

I will try to find my config .conf and send it to you by email ...

Hi Pekr, Rebol/Cmd works fine with lighttpd and LiteSpeed Web Servers. 
I configure succesfully those web servers to work with rebol/cmd 
as static server (i did not try as external server but this sould 
work too). But I did not succeed with Apache!

Static is not good, I want dynamic ones ...

I do not remember, what "static" means, but imo only External mode 
works with Windows ...

By static I mean the Web Server takes care to create as many VM instances 
as needed within the min and max nb of instances allowed by the web 
master.

that is dynamic, no?

by what you mean by static does not work with apache on windows anyway 
...

You are right. So i will try on Apache Linux. It shoud work as I 
succeeded with both lighttpd and litespeed. By the way, these two 
web server are very good and so easy to configure (specially LiteSpeed)...

I'd like to let my cgi script to be easy portable. I already moved 
them twice on tree different unix-like OS successfully, but I had 
always the problem of the first row. If in the first row I wrote 
#!/usr/local/rebol/rebol -c I need, in the new hosting OS, to have 
Rebol installed in thet dir. But this is not always true (or simple 
to set up). So I'd like to use a "portable syntax". Now, I did various 
tests but I couldn't find a solution. I already tryed:

1) #!/scripttorebol, where  "scripttorebol" is a script containing 
#!/usr/local/rebol/rebol -c on the first row. But it doesn't work 
because the rebol code is even interpreted by the OS shell

2) #!/bin/bash and in the second row 'exec /usr/local/rebol/rebol 
-c "$0" "$@" '. Rebol starts correctly but it raise an error because 
the script does not have  a rebol[] header (that is on the following 
lines)

Is there any unix guru who can help me? Thank you

How about an symbolic link.

(ln -s <src-file> <target-file>)

(#!/link-to-rebol -c)  where link-to-rebol is a link where the actual 
location of the rebol interpreter.

prepare your upload with rebol and replace some things server-specific.

  write %dst/cgi/script.r join "#!/here/is/rebol^/" read src/script.r

2) should work too, you need a header, but you can put as many lines 
before it
!/bin/bash
exec /usr/local/rebol/rebol -c "$0" "$@" 
rebol[]

about 2, if you know what to put after exec, you should know what 
to put in the shebang too, no?

Ok I simply choosen a complicated way.

Gabriele: I meant to put after the exec the path to a script file. 
It didn't work because I wrote it in the wrong way. Now I modified 
it and it work.

Volker: What you suggested could be a solution but I should write 
a migration utility, not so simple in a complex environment.

Jaime: Probably it is the best solution. I was trying to reach the 
same result thru a script file but the result is the same and create 
a link is the fasted method.

Thank you all.

Does anyone have exoerience with CMS's with Rebol cgi? How do they 
scale compared to the usual suspects? (the three "P"s Perl/Python/Php) 
(Maybe that's the biggest hurdle to worldwide Rebol adoption: it 
doesn't start with a "P" so can't easily replace any of the aforementioned 
languages in the LAMP acronym ... Any chances of renaming Rebol to 
Pebol?)