AltME groups: search

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.

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?

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.

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

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.

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&

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

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

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'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)

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

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[]

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.

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?)

What I'm thinking about is a webpage with several interconnected 
hierarchies ... e.g.

Germany
     Hassia
         Wiesbaden
         Frankfurt
     Bavaria
    .....

Music
   strings
        viola
        guitar
   ....


so you could search for Music in Bavaria, or strings in Germany, 
or ...

Do you mean a CMS written in REBOL?

REBOL CMSes? Not sure there are any as such. It'd be good to have 
a generally available and scalable Rebol CMS.


As an example of what is possible, have a play with the various indexes 
here (topic, date, author, subject)
http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-index.r
That's 50+meg of data, 42500 messages. All handled in pure REBOL.

Yes, a CMS written in Rebol would really be nice, so that I understand 
it. (unless it's written by one of the Rebol magicians ;-)

I'll have a look at the index pages.

Hi, for those interested, a modified and slightly improved version 
of Magic! for FastCGI is available on www.rebolgique.net....

The Rebol Directory Project (www.rebolgique.net/rdir/) is an exemple 
of application developped with FastCGI and Rebol/Command. This application 
is in its early stage, but is intended to become a database with 
as much inforamtion as possible about the members of the rebol community...

Looks good.

The problem with having a list of titles is you'll *never* think 
of them all [Ambassador, Brother, Comrade :-)] A type-in field would 
be more flexible.

I will add a tab 'Projets' with sub-tabs 'All', 'Rebol', 'Non rebol' 
where a reboler can describe projects he/she made are intend to make...

post code in the UK -- a convoluted combination of letters and digits 
with a space in the middle.

Postal Code is a common generic term in UIs.

This is what we do at REBOL.org:
 print "Content-Type: text/plain"
 print "Content-Disposition: attachment; filename=sqd.r"
You can see that one in action with this URL:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=sqd.r

Yes, I actually moved over a script I know worked (from the rebol 
viewpoint).

I'll backtrack to see what had happened. Me thinks it has to do with 
the my script "do"ing a library script. Maybe something was wrong 
with that.

Btw, I just got one of those virtual dedicated servers and so there 
are a lot of little things I have to do which I didn't owrry about 
before.

Good idea. I just went back and recreated a 2nd test and it worked 
fine as well. Hmmmm.

thats another trap :) i always ls the rights after a change now..

After all Carl decided to do rebol when he set up a linux-server..

< "Premature end of script headers">

 Usual cause: wrong line terminations....Maybe you uploaded a test 
 file from/to UNIX/MAC/Win without checking the "asciii" box to get 
 automatic CRLF/CR/LF conversions.

Hello everyone..
I have a CGI problem/question.


I have a Win-apache-rebol server that isn't propagting the cgi info 
properly..
Upon posting.. the query-string is empty.
I am not sure what I am missing..

Details:

page1.rcgi
========================
#!c:\rebol\rebol.exe -cs
rebol []
print "content-type: text/html^/"
print "<html><body>"
print "  <form action='page2.rcgi' method='POST'>"

print "    <input type='text' name='var01' size='16' value='test'>"
print "    <input type='submit' name='go' value='Lookup'>"
print "  </form>"
print "</body></html>"


page2.rcgi
========================
#!c:\rebol\rebol.exe -cs
REBOL [ ]
print "content-type: text/html^/"
print "<html><body>"
print mold system/options/cgi
print "<hr>"
print "</body></html>"



if I .. ( decode-cgi system/options/cgi/query-string ), my vars are 
all undefined.

Also, looking at the 'print mold system/options/cgi' shows   query-string=""

if I change page1 form-action to ... "action='page2.rcgi?x=123"

then the query-string on page2 gets populated with x=123 and the 
value 123 gets assigned to 'x'
when I 'decode-cgi'.

However, my form fields NEVER get populated.
Does anyone have any advice?

John.

I prefer to use get for variables that are part of a logical location, 
like a page viewer, search variables and such. I use post if the 
data being submitted causes changes (other than logging and such). 
Anything you want to be bookmarked you pass with get.

Get is also repeatable....useful if you have a convoluted script 
or need to re-read the variables (eg in an error handler to log what 
triggered the problem).
Whereas post reads from a port and exhausts its input.

Is there an example for temple somewhere? Was quite surprised google 
found nothing, and i got the source finally through detective. Now 
i need to get the cgi started and a simple demo.

3) I have older version of rebcmd from linux sdk I bought. But it 
did not used 'read-cgi at that time (well, here we are with SDK coming 
late ;-) My question is - I uploaded rebol core into cgi-bin directory:
a) is it desirable aproach or should it be avoided?

b) how do I assure, that if I ftp rebol executable to cgi-bin dir, 
to have sufficient right of the target directory, so that it could 
be run?

1) should be secure. decode-cgi should put only strings in the data, 
nothing executable. (i use a lot "should" when it comes to security 
and i did not double-check).
But why do you do that? simply 
 mold decode-cgi
should give the same.

Can you just use a checklist item? maybe post them in this format:
	Title: Disable xyz.
	Description:
		<long description>
		Priority: <1-4>
		Benefits (what we gain): 
		Tradeoffs (what we lose):
		Why it's worth it:

And don't forget those of us who want to use the browser as a delivery 
mechanism for fully empowered un-castrated Rebol applications.

Right. It will be on the list, but may not make it until REBOL 3.0. 
That seems a little tougher to do. TBD.

1. User right-clicks existing plugin in browser window for context 
menu, chooses "Check for newer version of Rebol Plugin"
2. Plugin checks for newer version

3. if newer version -> "Would you like to install newer version ?" 
4. if "yes", download and install.

5. "Would you like to remove the older version (you probably don't 
need it now) ?"


When there are multiple versions installed there could a menu option 
to activate one of them.


!!Updater should not close the browser. It should suggest to the 
user to close and reopen.

The newer version make break older code that the user may be relying 
on. "Thanks a lot, updater!!"

A minor security "fix" can also break older code.

Veerry interesting. Not a bad idea. Probably can do it.

Well here's a side-by-side problem scenario. Grandpa doesn't know 
anything about anything, other than how to check his e-mail. He comes 
to web site 1 which auto-installs (with his permission) REBOL 1.3.2. 
Then he goes to web site 2, which needs REBOL 3.0, and it auto-installs 
side-by-side. Then he comes to a third site, which tells him it requires 
the REBOL/Plugin. How does he know which plugin it needs?

Actually, Java isn't a good example. Their updater sucks. Better 
example, like .NET.

Sure, I understand that makes sense for developers, but I can see 
real confusion. Since when does a web site tell you that it requires 
Flash version 3.0? All Flash scripts run in the latest version of 
Flash, so if you have Flash 8, you're all set on any Flash web site 
(I think...someone correct me if I'm wrong).

My plan above is easy to implement for now. It's good for us developers 
in the near term.  Later we can add a complex auto-update scheme 
which can be manually switched on by a right-click menu.

Especially since, with a new release,  we may need new features in 
the plugin *itself*, and not just in viewdll.

That's a complicated issue.

I like the API being able to wrap a one dll from each generation, 
and then update that dll for security fixes.

Anton, your side-by-side idea is a good one. The problem is that 
I'm not sure it's automatic enough the average user.

Our original thinking with the plugin was as follows: Web site is 
responsible for everything. If web site requires new version of plugin, 
it specifies a new CLSID and forces the user to download it. The 
problem is, then you have 5 "REBOL/Plugin" objects in Downloaded 
Program FIles. Thoughts on that approach?

It's a simple "proto-form", good for development while we think and 
argue about a good update mechanism.

Website out on the web should have *no* control over decision making 
- only suggestions.  Website on a corporate trusted LAN should have 
heaps of control.

(I just know the version checking is going to cause subtle problems. 
There's nothing simpler than a old-version < new-version test)

I want to sleep on this. Good ideas. We still need to think of a 
good UI....I originally thought a popup "An update is available for 
REBOL/Plugin for Internet Explorer.  Would you like to update now"?

They should be able to figure out a right-click menu.

What about a little bubble down by the clock? Of course that would 
only work on Windows, maybe 2000 or later.

I think a prompt is better, particulary for security updates.

perhaps there should be a standard whereby the plugin application 
displays the notice.

Could we enforce a minimum window size ? Think of the minimum window 
size we have here on WinXP. Never bothered me before.

Do you think a minimum window size would be good ?

Running a REBOL/Services client in a webbug and having it control 
the browser through the DOM could be useful though.

Why would it be worried about showing a small window, though ?

What's a minimum though, when you could just as easily color the 
applet the same color as the background?

A legitimate webbug wouldn't be worried about showing a security 
update. An illegitimate one would be directly interested in hiding 
one since it may be depending on the security hole for exploit code.

So, we have a few different scenarios (using the numbering from above):

 1. In this case, the activex system in IE will force the download 
 of the (digitally signed) CAB found in the htm, which will come from 
 RT, and contain the Plugin version that works with this system. Nothing 
 new is required, this is how it works now.

 2. Here we need to enhance REBOL somehow to check for a security 
 update, prompt the user, and download an updater EXE. This is where 
 I think I will work next.

What  method for plugin update checking does firefox recommend? I 
already have a number of plugins that prompt me when a newer version 
is available, so I assume they is a standard method for it.

Does Firefox check for updates to its plugins? I thought it just 
checked for updates to its themes and extensions but let the plugins 
update themselves. It does seem to provide a plugin registry though.

Assuming the plugin will become wildly successful, maybe there should 
be a way to have the initial plugin download and subsequent updates 
come from a site other than rebol.com so that any outage there wouldn't 
affect users hitting a page calling for the plugin. I wonder how 
high load is handled for the Flash plugin?

That's a good question. I'm also curious about how Firefox's plugin 
registry works, how to get a plugin there.

Does the current plugin have the ability to "pop-out" the browser 
window and create a self-standing application window like a Java 
applet?

So that you wouldn't be limited by a restrictive client area.

Well, that's a good question. I'd prefer the "wild web" version of 
the plugin to be restricted to the browser client area. (popups are 
evil). But the question is, is it possible to resize the client area 
in the browser ?

For that matter, is it possible to specify the size of the client 
area relative to the page size, have it resize with the page, and 
have the REBOL layout inside handle the resize as if a View window 
had been resized by the user?

Aha! A good reason to post this crazy video:

That's a great video - was totally amazed the first time I saw it

Yeah, it just creates another browser window to pop up in - thought 
I remembered it creating a system window.

Will there be any way to control the browser so that it opens inside 
a rebol window?

To much here to keep up, just picking " The problem is, then you 
have 5 "REBOL/Plugin" objects in Downloaded Program FIles. Thoughts 
on that approach?":

AFAIK with COM, a CLSID is not bound to a file. You can "serve" multiple 
clasids from the same file.  The idea is, that interfaces are frozen, 
if you need more functions you add another interface. which may include 
the same functions as the old one. So instead of using multiple files, 
you can have  the newest one implementing the old interfaces too. 
But then you have to be exactly compatible when using the old interfaces, 
at least thats the  idea. As firefox clones COM, i guess they have 
a similar feature.

Volker, that is true. But the problem here is not COM interface/version 
compatibility. The problem here is: "Which REBOL binary to load?" 
Very simply put, if a web site relies upon plugin version 1.3.2, 
we must make sure that 1.3.2 -- or a later version backwards-compatible 
with 1.3.2 -- loads on their computer. At the same time, we need 
to deliver critical security updates and other non-breaking updates 
to users in a seamless manner.

I'd like to focus the discussion around one unanswered question regarding 
installation: do we inform the user -- in any way -- of a major REBOL 
+ plugin update (i.e. REBOL 3.0)?

Yes, you have to, it is the only way to track bugs, and yey, with 
a popup.

I think there's no need to inform the user, unless a web page needs 
it.

If there is a problem after an update to a plugin, and you do not 
notify the user that there was a problem, there is no way for them 
to know what caused the problem, and they will waste thier time trying 
to hunt it down.  If you simply notify them when things are updated, 
they can connect the problem to the closest issue.

Wasn't the plugin going to run REBOL 1.3.* and 3.0 in parallel, depending 
on which generation the script requested? If that is the case, whi 
would a user of a 1.3.* script need 3.0? Soon enough they will be 
running scripts that need 3.0 - we can tell them then.


On the other hand, the plugin itself will need updates too, and maybe 
we can install 3.0 then for future reference.

Anton, that's a good question. My first thought was to ask before 
starting the download, then ask again after the download is complete 
and we are ready to install.

Yes, but the problem is: five versions means  five different entries 
in the user's "Downloaded Program Files", which is hardly a seamless, 
clear experience. That actually was our original thinking, and it's 
how we implemented the betas 2 years ago.