AltME groups: search

http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=lds-local.r

Selma had her off days too:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlHFFB
Or, as Graham suggests, it's RT's mail server

my message reached the list at http://mail.rebol.net/cgi-bin/mail-list.r
but didn't get out again back to me.

I've questioned this a few times over the years now.. 

If we have a CGI script that uses the mysql protocol, is it necessary 
to load this protocol with every cgi request?  Wouldn't that add 
some burden to the server?

forinstance, in Zope, I have a single sql connection which is used 
by all the "cgi" requests.

But if you want to access a mysql server, the cgi script loads each 
time, right?

can you give me an example of a cgi script that access a db, and 
doesn't load the protocol each time?

any Zope cgi script that access a database does that.

if I have a rebol daemon running that has a connection to a odbc 
database, then my rebol cgi script an interact with that.

Gabriele, I would like to raise the importance of 
http://www.rebol.net/cgi-bin/rambo.r?id=3571&


I patch functions quite often, and then I usually need to bind to 
the function context. If the original function was not written by 
me (or even if it was), then it's tricky to find a good technique 
to find a suitable word local to the function context. I have to 
look in the function body for a local word and write code to select 
it, which usually looks like spaghetti. I do my best, but if the 
function body changes for whatever reason, then my patch code is 
probably also broken. None of us likes to write code that is so brittle.

http://www.rebol.net/cgi-bin/rambo.r?id=3532&

it's already fixed: http://www.rebol.net/cgi-bin/rambo.r?id=4039&

Regarding #3867 "feel/detect event/face should be target face, not 
face" 
http://www.rebol.net/cgi-bin/rambo.r?id=3867

A guess: the web site is probably running a /core version -- /view 
versions used to not work well in CGI environments (though that may 
have changed).
/core has no draw ability.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlPSTK
<--- I can't find this old bug in RAMBO, and it still crashes REBOL.

Gabriele,
Can you please take a look at these 2 submissions:

http://www.rebol.net/cgi-bin/rambo.r?id=4274&
http://www.rebol.net/cgi-bin/rambo.r?id=4161&


I am desperate because center and left aligned text can not be edited.

Ca you please help?

I convinced myself and 2 others to go REBOL with a small but important 
app I need, but simple stuff like this kills the idea.

On windows platforms, you'll get the infamous DOS window flashing 
when executing an external CGI ! It's just a matter of 1 flag to 
correctly set in 'call C source code, if you're really annoyed by 
that, ask RT to fix it asap (for 2.7.6 that would be good)! ;-) I 
may reimplement completely call command in REBOL, but it would be 
a big waste of time and energy...it should be a 10 minutes fix for 
RT. Addind a time limit to 'call would be a good thing too, it would 
also avoid me the reimplementation of 'call to add such feature....
 - DocKimbel

Anx chance of getting above fixed? Should we rambo it?

Re my trim question of a week or so ago....
Thanks for the responses.
From RAMBO it seems this is deliberate (if unexpected) behavior:
http://www.rebol.net/cgi-bin/rambo.r?id=3681

This is intentional and not a bug. TRIM was designed that way to 
work well for trimming LINES of text. 
 [my emphasis of lineS, plural]

I verified this same bug today http://www.rebol.net/cgi-bin/rambo.r?id=3357&
 The workaround is to use /binary and then the limit is gone.

Anybody knows what's this about?

http://www.rebol.net/cgi-bin/rambo.r?id=-4786&

Found a couple RAMBO tickets dated back to 13-May-2006 related to 
the double evaluation of lit-words:
http://www.rebol.net/cgi-bin/rambo.r?id=4100&
http://www.rebol.net/cgi-bin/rambo.r?id=4101&


The tickets suggest, USE might be the problem, but isn't it SAME? 
that's the problem here? See the following R2 code:

>> a: first ['word]
== 'word
>> b: 'word
== word
>> strict-equal? a b
== true
>> strict-equal? :a :b
== false
>> same? a b
== true
>> same? :a :b
== true


I would expect all 4 to return false, but with double evaluation 
of lit-words, the last should still be false.

Anybody can alert the actual developer here?

http://www.rebol.net/cgi-bin/rambo.r?id=-4803&

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

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

http://www.rebol.net/cgi-bin/rambo.r?sort=1&limit=1&cmd=Search&id=&pattern=forall

See http://www.rebol.net/cgi-bin/rambo.r?id=3925&

what is the problem with post? as for cgi, I use read-cgi as in newer 
cores ... works so far ...

where do you put read-cgi in the forever loop?

read-cgi ...

more trouble comes with licensing of the server, if he want to encap 
it, and yet he wants to provide kind of cgi (plug-ins) to run rebol 
scripts - then he violates the license imo ...

read-cgi: func [/local data len] [
    either system/options/cgi/request-method = "POST" [

        set-modes system/ports/input [lines: false binary: true no-wait: 
        false]
        len: to-integer system/options/cgi/content-length
        data: to-string copy/part system/ports/input len
    ] [
        data: system/options/cgi/query-string
    ]
    data
 ]

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=webserv.r

I patched it a bit to be more verbose: http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=volkswebserv.r

But that one has bugs after a few calls. Don't know about webserv.r 
itself, i guess it is more stable.

Is there a reason for the syllable group not to be [web-public]?
If it were [web-public], then non-Altme users could read it here:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/aga-groups-index.r?world=r3wp

And you (or anyone) could refer to a previous post via a persistent 
URL.

I don't think it's an imposition! It'd be a service.
It's my script

Latest post......

The format of the URL is: .....posts=worldnameNNNxMMM  NNN=group-id, 
MMM=post-id. 
Use MMM=0 to mean latest *page* of posts for that group, eg:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/aga-display-posts.r?post=r3wp152x0

Some posts are there already!

http://www.rebol.org/cgi-bin/cgiwrap/rebol/aga-display-posts.r?post=r3wp225x1

my rebelBB.cgi script has stopped working

http://www.digicamsoft.com/cgi-bin/rebelBB.cgiis the script

http://www.compkarori.co.nz:9000/cgi-bin/rebelBB.cgi

And use cgi only as proxy.

Not really in RAMBO, closest is: http://www.rebol.net/cgi-bin/rambo.r?id=3853&

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/197938
-- looks like the Ruby approach to Unicode will be to use UTF-8/16 
as the internal string representation and convert from legacy encodings 
on read(/write?).

good news about the STACK function: http://www.rebol.net/cgi-bin/r3blog.r?view=0075

read about it here, http://www.rebol.net/cgi-bin/r3blog.r?view=0078#comments

Chris, you should test using http://localhost/show.cgiscript it 
will display all CGI data. 'script-name should give you what you 
need.

Let's say I need some functions available for all CGI scripts, where 
is the best place to init them?

(if I don't want to init them in all cgi scripts)

CGI environment is not supposed to be persistent, so there's no other 
ways than to manually add libs loading code to %CGI.r script. If 
you're encapping Cheyenne, you can add your libs to %cheyenne.r (and 
don't forget to LOAD them too). If you need a persistent environment, 
use RSP instead.

You can look at modules/CGI.r for an example.

Cheyenne needs at least 2.7.5. It should work on 2.5 I guess if you 
backport some mezzanines (like EXTRACT) and emulate some natives 
(like UNLESS). You also need CALL or LAUNCH in order to support RSP 
and CGI scripts.

hi doc, where can I find the syntax for the alias modul? (I wan't 
create a directory - cgi - alias)

thx doc, but what if I want to access cgi's in a directory 'outside' 
the document root?

But nothing stops you to use wrapper CGI to execute REBOL code outside 
of the document root (using do %...) if it's really required.

Btw, why bother with CGI scripts when you can use RSP script which 
are far more powerful ?

Other option (more powerful, but more complex), write a specific 
mod-rest module and if required, a background task handler. Not easy 
to do but could be done by copy/pasting code from mod-action/CGI 
or  mod-rsp/RSP and adapting to your needs.

OTOH, you could also make a more simpler mod-rest acting as a REST 
wrapper and just rewriting the URL to point to a simple ressource 
(CGI or RSP) and saving the REST url inside a custom HTTP header. 
That way, you could easily redirect a REST call to a RSP dispatcher. 
If you go that way, I would recommend to write a module with a single 
callback early in the Cheyenne's request processing pipeline.

stdin: try launching rebol with --cgi

Scope issue (my Rebol is rusty)... what I did was copy the content 
->  qstr: make object! decode-cgi to-string req/in/content
and make my own object . Im guessing this is not ideal

here's my default function.. 

  default: func [req params svc][
    raw-input: trim req/in/target
	if raw-input = ""[raw-input: "index.html"]
	qstr: make object! decode-cgi to-string req/in/content 
	bout: copy ""
	requesttype: "http"
	commander
	bout		 		
  ]
]

I want to pass the params to the commander function

static pages ( index.html ) work .. but cgi and rsp don't.

Just a crash involving cgi and rsp.  Static pages are still okay.

It seems that the issue is caused by helper processes being stuck 
in "busy" mode and 'pool-count reaching the max value (8 in v0.9.18), 
so that any new CGI or RSP request coming won't find a free helper 
process. I still don't see why helper processes would remain stuck 
in "busy" mode. I'll run a few tests tomorrow to investigate that 
more deeply.

Henrik, are you running RSP, or CGI ?

I guess that RebelBB is running as a CGI app ? If it's using READ-IO, 
your issue might be caused by some limitations of my READ-IO emulation 
code. If you can send me or point me to the code, it should help 
me improve Cheyenne's CGI support.

The code is the one of RebelBB here : http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?code=1

Okay, my READ-IO emulation has been removed in the last version. 
I've replaced it with a safe 'cgi-read-io function. I plan to put 
it back soon, I think I know how to make it work reliably now.

OK
You said "15-november" :

Okay, my READ-IO emulation has been removed in the last version. 
I've replaced it with a safe 'cgi-read-io function. I plan to put 
it back soon, I think I know how to make it work reliably now.


I need a cheyenne.exe with this done. Is there one somewhere or do 
you need to build it ?

Did you tried by just replacing the READ-IO occurences in your CGI 
with CGI-READ-IO to see if that fixes the problem ?

Ah, didn't understand that it was me that must put CGI-READ-IO in 
my script !

That was one of the options, the other is me writing a good READ-IO 
emulation for CGI (that won't happen soon...lack of time).

Either use an older REBOL core or apply the following patch to Cheyenne 
: http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=<9May2008113928682359200>

We were getting tormented by spam at http://guitarz.org/pappgmembers/index.cgi
.  At one point I needed an immediate bandaid, so temporarily added 
a several-line cgi that just told the user to type "pappg" as the 
password, and then checked that they entered it correctly.  We've 
never had another problem since :)  Makes me think that a catchpa 
would handle a lot of grief.

having fast-cgi would be fine. But - fast-cgi does not have sense 
for Cheyenne, no? Hmm, maybe it does, when you use e.g. php ...

New Cheyenne 0.9.19 beta version available for testing at : http://cheyenne-server.org/tmp/cheyenne-r0919.zip


Tested only on Windows  (my Linux image network has currently some 
issues).

ChangeLog (diff-ed from last test version) :


 o RSP: an HTTP redirection in 'on-page-start won't evaluate the page 
 script anymore.
	

 o CGI: mezz function READ-CGI now patched to be compatible with Cheyenne. 
 That's
	  the right way of reading POST data in REBOL CGI scripts.
	  
	o RSP: fixed a bug in session/add when setting a block! value.
	

 o Task-handler: fixed a network error on first packet read (high 
 load + fast hardware).
	

 o Task-handler: TCP keepalive mode activated (test workaround half-closed 
 connections).
	
	o Task-master: 
			o 'no-delay mode removed and replaced by 'keep-alive mode

   o now forks a new process as soon as one dies (not waiting for a 
   new request)

   o fix a long standing bug in queued job module name mismatching (can 
   happen under extreme load)
			o minor code cleanup
	

 o Uniserve: 'no-delay TCP network mode now switched off for all connections. 
 Fixes a

   stability issue on Vista and probably on UNIX with very high load.


 o RSP: fix a bug in 'decode-multipart when there's no file received.
	

 o UniServe: new logger service. Now all info or error logs, and debug 
 messages from

   CGI/RSP scripts are written in %trace.log. Additionnaly, you can 
   now log messages
	  using :
	  
	  		- debug/print msg 	; msg [string!]
	  		- debug/probe value 	; any mold-able value
	  		- ?? word		; works like REBOL's '?? function
	  		- ? msg		; alias for debug/print
	  

 o RSP: in debug mode, page generation time and SQL queries stats 
 now added at bottom
	  of pages.
	  
	o RSP: error in events from %app-init.r now logged.
	

 o RSP: fix a rare RSP freezing issue when an error occurs in %RSP.r 
 (for example, by
	  a user script that breaks RSP sandbox).
	  

 o RSP: sanboxing now protects from Exit/Return/Break calls made outside 
 of a
	  function context.
	  
	o RSP: %misc/rsp-init.r file removed.
	

 o RSP/CGI: New config keyword added in global sections : 'worker-libs. 
 It lists the

   librairies to load when a worker process is started. An optional 
   'on-quit section can

   be added to call cleanup code when the process quits. Examples :
	  
	  		worker-libs [
				%libs/mysql-protocols.r
				...
			]
		or	
			worker-libs [
				%libs/mysql-protocols.r
				...
				on-quit [
					%/libs/free-resources.r
				]
			]
	

 o Task-master: now you can reset all worker processes without stopping 
 Cheyenne. This

   is usefull when you need to force non-RSP/CGI files reload (helper 
   scripts, 3rd party
	  librairies,...). 
	  
	  	Usage:
	
			Windows : tray icon -> Reset Workers
		

   UNIX : kill -s USR1 <pid>	(<pid> is Cheyenne's main process ID)
	 
	 

  o Added a -w command line option to set the worker processes number. 
	 
	   	Usage:
	   
	  		$ cheyenne -w <n>		(n [integer!] : CGI/RSP process number)
	   

    Use -w 0 to help debug CGI/RSP code by resetting worker processes 
    after each request.
	   (it's like calling "Reset workers" after each request).

How is fast-cgi implemented via Cheyenne?

New Cheyenne test release 0.9.19 available. Please report any bug 
or regresson here.

Changelog (diff from previous one) :


  o RSP: fixed a security issue allowing access to /webapp/private/ 
  sub-folders content.
	 

  o RSP/CGI: fix for HTTP 'Date header not being returned in some cases.(Will)
	 

  o RSP Sessions: fixed an issue with init flag when saving sessions 
  on disk.(Will)
	 
	 o RSP: now you can declare folders as valid login URL.(Will)
	 
	 	Ex: auth "/admin/login/"
	 	

  o RSP: a new session word 'from has been added. It's set to the referring 
  URL on login.

    After login, you can now redirect to the referring page (in case 
    of session timeouts
	   for example).(Will)
	   

  o RSP: a webapp can now be called without the ending slash.(Will)
	 

  o RSP: the root "/" webapp can now be declared (needs testing).(Will)
	 	 

  o RSP: new 'SID-domain config keyword added allowing to share sessions 
  between
	   sub-domains.(Will)
	 

  o RSP: now session ID can be passed as URL or POST data in addition 
  to cookie.(Will)
	 

  o New 'charset config keyword added. It allows to define specific 
  charset sent through
	   HTTP headers for 'text/htlm resources.(Will)
	   

  o RSP: Added a new function no-log in Response object. Use it to 
  avoid writing
	   log info to disk for the current request.(Will)
	   
	   		Ex: response/no-log


  o New 'mod-expire module for HTTPd. Allow configuring 'Expires HTTP 
  header. 
	   See %Cheyenne/mods/mod-expire.r for more info.(Will)

I see I reported other issues with launch

http://www.rebol.net/cgi-bin/rambo.r?id=4205&
That one is makred TBD

Oldes: Graham is using CALL from RSP scripts to do image processing 
IIRC. I never used CALL from RSP myself, so I can't tell. It seems 
to me that it would be faster/safer to wrap an image processing DLL 
than launching a new process for each new request. Using CALL from 
a RSP is like dropping to CGI, you're loosing most of RSP speed benefits.

We can't expect people to change their existing web-server. We can't 
expect them to install Rebol interpreter, create new CGI setup etc.


But we can expect people to install something on their system, add 
a little config stuff to the existing setup and have a cool web-app 
up& running.

Very interesting idea. My easy-cgi tries to serve as a "package", 
which can be just copied to any cgi-enabled site. I am at very beginning, 
not really trying to do more than simple cgi stuff, sqlite, sessions 
....

What you describe would mean, than you can only do one CGI request 
at the time. Cheyenne will launch new CGI process at each request, 
hence your file operations could collide. I like SQLite very much, 
but they don't provide server level functionality. They are able 
to work at file-lock level, but dunno how solid it is ...

Cheyenne serves static resources from the main process (UniServe 
process), but CGI and RSP are executed by pre-forked worker processes. 
So yes, writing to the same file from RSP script can be an issue 
if you don't have a mean to ensure that write accesses are serialized. 
I had that issue recently for RSP log/debug file, I had to build 
a small logger service in the main process to be able to serialize 
 write access (after stress testing different file locking solutions 
from REBOL, no one seemed reliable enough to me). 


I thought about adding a synchronization service in Cheyenne that 
could be used to (but not only) address the write file sync issue. 
That could work for low sync needs (like writing to a file once every 
few seconds), but for massive sync needs (dozens or hundreds of sync 
req/s), I'm afraid that the TCP port overhead would be too costly...(maybe 
a separate sync server process with persistent TCP connections could 
be good enough even for heavy uses?)

Let's clarify a few things :


- Request/content is working OK in your example, there's no issue 
with that.


- Using variables in PARSE rules without initializing them is a bad 
programming practice in my book. You *should* initialize them before 
using them (unless wrapped in a function which will do the work for 
you). If your parse rule fails, your code may error out (or you may 
get an unexpected value) when trying to print 'phone because it hasn't 
been initialized. 


- You seem to expect that RSP script will be evaluated in a fresh 
REBOL session each time. This is not the way RSP works. RSP uses 
persistent pre-forked processes for performances. If you expect a 
fresh REBOL session each time, then this is the CGI model which is 
an order of magnitude slower than RSP. 


- Even if RSP processes are persistent, they can be restarted or 
killed and you can't control which process will executed your script, 
so, just as a warning, you can't expect that a "global" variable 
will be still there for the next RSP script evaluation. If you need 
value persistency, use a session variable or write it to disk.

That's the main feature making Cheyenne/RSP a much faster solution 
than Apache/CGI for server-side REBOL code.

I can implement a clean-up routine for RSP variables declared in 
a webapp context, but this would be a partial solution (won't clean 
up global space), and in all cases, you *should* initialized all 
variables before using them either by declaring them in a function! 
as local words or by explicitely setting them to a default value. 
Such clean-up routine could be usefull to enhance security by avoiding 
to reveal other user data in case of a RSP script programming error.


Btw, you can already detect uninitialized variables in your RSP code 
by running Cheyenne with the -w 0 command line option. This would 
tell Cheyenne to use a single RSP worker process that will be restarted 
after each request (CGI like beahaviour). An uninitialized variable 
will likely error out in that case.

I normally do this, but for some reaason I was thinking cgi instead 
of rsp, and so thought I didn't need to do that.

rsp and not cgi

mercurial in particular works fine as a simple CGI if you want to 
give read access to the repository

and with some configuration for the auth part, you can also use the 
CGI for write access.

you can use the embedded web server, or use the CGI with an existing 
web server

Cheyenne process script files declared in %httpd.cfg config file. 
In the default config file, you have :
	bind-extern CGI to [.cgi .r]

which means that both .cgi and .r are treated as CGI scripts and 
executed.

Re HTTPS: there's a ticket opened in RAMBO since October 2006 from 
Maarten asking for that : http://www.rebol.net/cgi-bin/rambo.r?id=4170&
. If Carl could fix it for 2.7.7, that would be a great new feature.

as Henrik said.. cheyenne was certanly rebol "web-window" for me. 
The day I tested and saw it can handle 300req/sec I switched to rebol 
for webdev.. there is no way I would use ordinary CGI to make webapps 
at this time.

Just remember one important thing : mods live in the main process 
(the one running UniServe), so you have to keep mod handlers fast 
enough to not slow down the whole server. That's why Task-master 
service and it's helper process are here, to handle the load for 
the main process. See mod-action as an example of unloading the main 
process from the burden of running CGI scripts.

You can't. Mods are part of Cheyenne's kernel and the priority of 
each mod's callback is determined relatively to the other mods during 
Cheyenne boot (kind of competition for higher priority for each phase). 
Reloading a mod would required reloading all the mods, breaking most 
of the active connections (CGI, RSP, FastCGI,...). So the answer 
is : kill and reload Cheyenne.

The handler name declare in BIND or BIND-EXTERN have to match a mod 
ID or a background handler name.
Examples:

 bind SSI to .shtml => processed by mod-ssi.r (SSI is used as a matching 
 key in the mod)

 bind-extern CGI to .cgi => processed by mod-action.r (bind-extern's 
 dispatcher), then by CGI.r external handler in a worker process.

I've scrapped the previous remark system in favor building remark 
v3 right away.  this will actually help me build the mod much faster 
and will provide 100% dataflow engine from its first release.  every 
single programmable entity within mod-remark is now based on a plug. 
 the architecture I have now is becoming very orthogonal... instead 
of building up different objects for each level of config, I think 
I'll be able to reduce it to ONE.


these models will serve as references for the !compilator to create 
persistent  !documents... note that !documents are multi-leveled... 
you build documents by linking up document together.... so if only 
part of a !document is dynamic, only that part will cause processing... 
and by dynamic, I don't mean that its cgi... I mean it has actually 
changed.  down to a single HTML element.   that's what I am aiming 
in any case.


!documents can be stored at any level... from server down to specific 
page and single session. caching is embeded in liquid so it should 
be pretty fast, and inter document data sharing should allow us to 
make it very RAM efficient too.

in the http.cfg file its assigned as a cgi script:

bind-extern CGI to [.cgi .r]

and the CGI handler will execute it.

Well, there's just a local dependency on config file to remove first 
(in my todo list) to allow remote worker process (for RSP, CGI,...). 
But you need a also a remote process manager to handle the launching 
of worker processes. Anyway, I think that using a front load balancer 
(supporting session affinity) with several servers is a simple and 
efficient solution.

amacleod: I'm planning to work in the next weeks on integrating an 
async Mail Transfer Agent in Cheyenne, so sending emails will not 
blocks CGI or RSP scripts.