World: r3wp

The shebang is necessary so the webserver can find the right program 
to execute.

(Unless you have set up an appropriate file association between the 
file type and rebol.exe then you may not need it under some operating 
systems and webservers)


The shebang line is treated as a comment by REBOL.exe  -- as is everything 
before the REBOL [...] header

That's what I thought, but I'm having bizarre issues with the shebang 
and rebol scripts today.

I know the feeling.....I've had that at times too.

But all my solutions have already been suggested by Allen or Volker.
Good luck!

Well, I don't have it working on my home machine, but I've got it 
on coolnamehere.com. So I can work on CGI stuff, and figure out what's 
wrong on my machine at my own leisure :-)

I think maybe I am the next one going down this path, and somehow 
I stumbled... :-\

I am trying to sort out what the POST data should look like coming 
to a Rebol web server from a browser after someone hits submit.

It's fairly straigt-foward (I think!).


.......If you have no multi-part data, then just used the "standard" 
read-cgi  -- but remember that on some platforms no input returns 
"" while on others it returns none
http://www.rebol.com/docs/words/wread-io.html


.....If you have multi-part data (say an uploaded file), then use 
Andreas' decode-multipart-form script:

 http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlKVSQ


.....If the form could have both or neither (ie there may or may 
not be a file uploaded), then each of the above solutions will fail 
(Carl's when there is. and Andreas's when there isn't)....So wrap 
the full code in a few attempts to handle that.

I would like to be able to look at exactly what the browser submits, 
so I can compare that to what I read in.  There must be some way 
to catch what the browser is sending (or maybe I just have to look 
with ethereal at the packets)

Stick a proxy in the middle and check the data stream?

aha, that is interesting...one more level of program to run simultaneously, 
but I hadn't thought of doing that.

To see what REBOL receives, just:
   read-io system/ports/input buffer  
Though that may already have been too massaged for your purposes.

Steve, If it is a small number of fields, you can change the html 
submit action from a 'Post to a 'Get then you will see the fields 
in the URL when submitted.   Just take a copy of the HTML page if 
it is not yours and look for the Action word in the Form to change 
then run it yourself.

(AFAIK:) The browser submits what read-cgi reads. Post means: give 
script all data in stdin (system/ports/input). Thats for lots of 
data, when you post something. Get means, give data in url. Thats 
for getting data, the query is only short (and typable in urlbar). 
So read-cgi write that in a file and read it in an editor.

Andreas script does the same (thanks for link sunanda ;) 

You find there a 'read-post-data, thats read-cgi with another name. 
and that is used in 'decode-multipart-form-data.

A second source of information are the environment-vars passed by 
the server. They are in system/options/cgi.  'decode-multipart-form 
needs system/options/cgi/content-type. There youself can look what 
the datas are too. if it is "multipart/form-data", use 'decode-multipart-form. 
i don't know the other types, just send a script a form and dump 
it.

Steve, now i read your question again, you are writing a complete 
web-server? Why not looking at one available? Patch %webserv.r to 
probe a bit. It also splits the stuff into system/options/cgi, so 
you can study how to do that. Only problem is with post-data, its 
system/ports/input works a bit different to a real webserver. You 
need to look in /content-length and use a copy/part instead of carls 
loop. and sometimes to set the right port-modes by hand IIRC.

you mean Cal's loop, right, Volker?

I have looked through that some, and I had read the comments in here 
earlier.

I was able to see some packets in ethereal (as a comms guy, I always 
dig through the communications messages to understand what happens, 
so starting to narrow that down.

Anyone know a good resource on CHMOD and web folder permissions? 
 Covering eg. what world-executable rights on a folder allows?

it allows the directory to be entered/traversed by people who are 
not the owner  of the dir or in the group the directory belongs in

that is a directory may be "readable" but you still need to be able 
to open it to read it

if a dir is readable but not "executable", you can list its contents 
but not access files in it.

if x but not r you can access files in it but not list its contents

if both, you can access files in it and list its contents.

any good imagemap examples  in REBOL?

for what purpose ?

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