AltME groups: search

I wanted to make it easier for CGI coders to switch from Cheyenne<=>Apache. 
Using your solution would force users to add/remove the shebang line 
each time you change server (like debugging locally on Cheyenne and 
putting in production on Apache).

Always honoring shebang line would result in poor performance of 
REBOL CGI scripts under Cheyenne.

How is that? Under Apache, I do have to have both - shebang line 
plus REBOL header .... Yes, I understand why the precedence was set 
- because of fast-cgi mode precedence ...

Right, I thought that making REBOL CGI fast under Cheyenne was the 
least expected from a REBOL web server.

Yes, normally yes, because you don't normally care about using different 
interpreter for the task given. It could as well be easily solved 
by some setting/switch - use normal CGI, vs FastCGI ....

for all those years, I used normal CGI on my linux. I found out, 
that even PHP on my server, runs in normal CGI mode :-) But being 
faster is always handy ...

Part of REBOL oddities. REBOL only needs get-env for supporting CGI 
mode.

SVN r17 : big update, lot of code added mostly for the new embedded 
async Mail Transfer Agent (MTA)

FEAT: email async sending sub-system (MTA) added . 

FEAT: added two new functions for email support in RSP/CGI scripts: 
'send-email and 'email-info?
FEAT: added email sending demo form %www/email.rsp.

FEAT: Cheyenne's main process ID is now exported in /tmp/cheyenne.pid 
on start and deleted on quit. (All platforms except Windows).

FIX: fixed broken global words protection in RSP.r.
FIX: HTTP Date headers are now in UTC format.

FIX: "Reset Workers" menu wasn't working in service mode. Fixed now. 
(Thanks Will)

FIX: SVNr4 regression bug on system port for UNIX fixed. (Thanks 
Will)

FIX: multipart file uploading code refactored. Fixes many bugs in 
file uploading.

Btw, it doesn't accepting other mail clients than Cheyenne's CGI 
and RSP scripts.

because I use duplicate cgi names .. ie. from and file, they are 
turned into a block when processed

data: decode-cgi dehex read/binary %temp.tmp ....

Jarnal is an open source Java app that can ink on PDFs and save them 
back to the server by posting the PDF with the annotations to a cgi 
script.

mod-rsp is quite complex, it does a lot of things. You can start 
by mod-action (which handles CGI), it's like a stripped down version 
of mod-rsp (no session, no webapp, etc...) to get the basics of using 
an handler, then dive into mod-rsp to add higher level features.

doc - could bind or bind-extern be used to invoke CGI handler for 
.html files?

Pekr: it would not work that way, the CGI handler in worker process 
will try to DO the file.

Max - never mind. If I want to use only Cheyenne, it is not a problem. 
I was thinking around the lines of producing rebol aproach, which 
would be interchangable easily between Apache and Cheyenne, for those 
who can't afford to push their provider to run Cheyenne for them. 
So I thought that following Apache equivalent would be useful. But 
my request surely is not a priority ....

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi

This is what I'm looking to do.

- A client connects via websocket.

- Client sends message "a". The server runs the following

forever[
n: read http://cheyenne-server.org/blog.rsp
prin n
wait 1
]
 
- Client sends second message "b". The server runs the following

forever[
x: read http://rebol.com/cgi-bin/blog.r
prin n
wait 2
]

These loops should be non-blocking.

H: yes, it's a bit odd. I thought CGI was dead 8 years ago.... but 
then, NO.

I'd be quite interested in testing R3 Chat on Cheyenne. Right now, 
it must drive the rebol.net server crazy on CGI.

(It pipes all R3 Chat connections via a CGI proxy.)

CGI proxy? They still make that stuff ;)

Any clues on running R3 for cgi ?

R3 should work as CGI with Cheyenne as long as you provide a correct 
shebang line.

Doc, this lastest ws:// demo I've been working on is so killer, that 
I'm going to send you $100 to put towards Cheyenne/ websocket development.

All you need is a donation box.... https://www.paypal.com/cgi-bin/webscr?cmd=p/xcl/rec/donate-intro-outside

Graham,  I've used this code to obtain get/post data in Cheyenne:

REBOL [title: "sitebuilder" file: %sitebuilder.cgi]
print "content-type: text/html^/"
print [<HTML><HEAD><TITLE>"Sitebuilder"</TITLE></HEAD><BODY>]
either system/options/cgi/request-method = "POST" [
    submitted-bin: make string! input
] [
    submitted-bin: system/options/cgi/query-string
]
submitted: decode-cgi submitted-bin

That replaces this Apache CGI code:

#!./rebol276 -cs
REBOL []
print "content-type: text/html^/"
print [<HTML><HEAD><TITLE>"Sitebuilder"</TITLE></HEAD><BODY>]
read-cgi: func [/local data buffer][
    switch 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
            ]
        ]
        "GET" [data: system/options/cgi/query-string]
    ]
    data
]
submitted: decode-cgi submitted-bin: read-cgi

HTH :)

Hmm ... what do you mean? You normally run your CGI scripts, which 
can connect to SQL database, no? Dunno, how it is done in case of 
persisent connections ...

In addition to Henrik's answers, database access can be used in two 
ways, either "manually", opening and closing connection yourself 
from a CGI or RSP script (READ mysql:// prefered in that case), or 
by relying on the RSP webapp API to manage persistent connections 
(see DO-SQL function in RSP API doc).


In both cases, you need to load mysql-protocol.r. The best place 
for that is in the config file in GLOBALS section, just add :

worker-libs [
    %<path-to-mysql-file>/mysql-protocol.r
]


Usually, I define a %libs/ sub-folder in Cheyenne's folder and store 
there all the libraries used by all my RSP or CGI scripts.

I can write a CGI to do that, but it will be slower because it requires 
an extra CALL from cheyenne.

POST /cgi-bin/rebdev HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: host.rebol.net
User-Agent: REBOL
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 56


[0.4.0 "Graham" password  login]HTTP/1.1 500 Internal error in REBOL 
CGI Proxy
Date: Sun, 14 Feb 2010 02:05:45 GMT
Server: Apache/2.0.53 (Fedora)
Content-Type: text/plain; charset=UTF-8
Via: 1.1 bc7
Connection: close

Cannot connect (3)

Does Cheyenne support R3 CGI scripts?

I believe you should be able to run any CGI script with Cheyenne. 
If you search back in this topic, Dockimbel specifically mentioned 
something about running R3 CGI scripts.

Cheyenne's CGI handler reads the first 512 bytes of a CGI script, 
if it contains "REBOL" followed by a [, it loads the script and evaluates 
it. If header is not found, it reads the shebang line and run the 
script using CALL (so as a separate process). So, in order to run 
R3 scripts, you need to patch Cheyenne's CGI handler to run all scripts 
with CALL, or provide a R3 CGI script with shebang line and extra 
text (512 bytes) before the REBOL header (R3 should ignore the extra 
text).

I use something like this in my nginx config:
        location ~ \.(rsp|cgi)$ {
            proxy_pass   http://lucya.desajn.web:8080;
            
            proxy_set_header   X-Real-IP        $remote_addr;

            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_set_header   X-URI $request_uri;

            proxy_set_header   if-modified-since $http_if_modified_since;
            
			client_max_body_size       10m;
            client_body_buffer_size    128k;

            proxy_connect_timeout      90;
            proxy_send_timeout         90;
            proxy_read_timeout         90;

            proxy_buffer_size          4k;
            proxy_buffers              4 32k;
            proxy_busy_buffers_size    64k;
            proxy_temp_file_write_size 64k;
        }

Terry: you need to be more specific, "processing" is very vague. 
Also are you talking about running code in CGI/RSP or in Cheyenne's 
main process?

I presume Terry is using web sockets to communicate to cheyenne instead 
of using rsp or cgi

I can use cgi aswell but there is no way to detect if a player disconnected.

if you are doing cgi or rsp,, then just be mindfull that several 
domains share the same root.

ie. the cgi, rsp and rsp web app are not

I read the conversation. That is what I am looking for. Unfortunatelly, 
it was anandoned. Temple is not using Cheyenee but cgi.

still CGI though?

hum...I forget about the SDK licensing issue, you can't distribute 
encapped binaries that allow running arbitrary REBOL code (Cheyenne 
allows that through CGI and RSP scripts).

Doc - I think you guys might be wrong, no? IMO the restriction applies 
to app, directly exposing REBOL scripts. Does encapped Cheynne does 
so? Can we regard CGI being such an exposure? Is it identical to 
doing a script "normal way"?

Pekr, the definition : "(in other words, you allow users of your 
programs to write and execute REBOL scripts within your program)" 
seems broad enough to me to include CGI. But as I'm not a native 
english speaker, I might understand it wrongly.

It says on hover, listening on port 8000 and cgi/rsp/html work

I click on the run as service and it changes to "Cheyenne is running" 
with no port now specifed.  Html/rsp and cgi all now fail.

it sounds like it would slow it down to cgi ?

I'll have to do some more digging Doc, and maybe see what do* does 
since I haven't tried that. I'll actually read some source if need 
be. ;-) 


What I saw with your new change is something I also saw once with 
the previous approach. Plain CGI worked fine until an RSP was run, 
then the CGI failed, *then* both the test RSP and test RSP web app 
started returning with garbage at the top of the page. More garbage 
each time, like a buffer was being added to. Then the plain CGI worked 
again. Doing a reset on the workers solves the garbage problem.


My Cheyenne EXE is from 2009 so I'll check for a new one before doing 
anything else.

You've been running cgi ?

CGI is nicer on Cheyenne because it acts like FastCGI for R2. But 
if you want to write your scripts in R3, you'll still need slow CGI 
instead of RSP

slow CGI ?

Traditional CGI, where you start a new process for each request

Actually I wasn't aware that Cheyenne had a mechanism for external 
cgi .. but I guess it must

LNS server doing the cgi

anyway, what advantage would there to be use R3 over R2 for cgi ?

By the way, my Boron demos are running on Cheyenne in traditional 
slow CGI mode

I'm having problems with post data and Rebol CGI scripts under Cheyenne. 
I ran a simple test scipt to simply echo back the post data:

#!/usr/bin/rebol -cs



REBOL []


data: make string! 1020

buffer: make string! 16380

while [positive? read-io system/ports/input buffer 16380][

    append data buffer

    clear buffer
]


print "content-type: text/plain^/"

print data


The script echoes back the post data when run under Apache but prints 
an empty line under Cheyenne.


(Just to check I ran a similar Ruby script which successfully echoes 
back the post data in Ruby).

I'm running 0.9.20 encmd.

I think this would work if you would force Cheyenne to execute it 
as a real CGI script

But normally, Cheyenne recognises a REBOL script and executes it 
as Fast CGI, in the UniServe process itself

I think you can see this in the show.cgi example

I would prefer to force Cheyenne to execute the script as a real 
CGI Script as I am trying to run REBOL/Services as a CGI script under 
Cheyenne. Ideally, I don't want to have to change the REBOL/Services 
code. (I am migrating a REBOL/Services application away from its 
existing web server and hopefully to Cheyenne. In the longer term, 
it may be possible to convert it to a Cheyenne web app).


Any hints on how to force Cheyenne to run a .cgi file as a real CGI 
script?

Or does REBOL/Services have a CGI interface?

Is anybody running cgi scripts under Cheyenne on OS X? It seems that 
the environment variables are not getting set as the driver only 
seems to load the set-env librarires for .dll and .so

Is anybody running REBOL/Services as a cgi script under Cheyenne 
?

Tracing it. That's odd: the general binding is done in misc/macosx.r. 
I don't see why cgi.r should do it double

The CGI.r code is run in a separate process, it inherits OS bindings 
from misc/macosx.r only when encapped. It should have worked using 
the  /cmd binary, I need to look into it and patch the CGI code to 
not bind twice when encapped.

.. and am running CGI scripts not fastCGI scripts - I even checked 
that the env variables are getting set by running a trivial Ruby 
cgi,.

and am running CGI scripts not fastCGI scripts

 REBOL scripts are run directly by CGI.r, the CGI interface is emulated, 
 set-env is not used for REBOL scripts. I'll do some testing with 
 non-REBOL scripts on OS X today.

Doc - I am trying to test running REBOL/Services CGI under Cheyenne. 
It looks as though REBOL/Services will not run as fastcgi so we are 
running as an ordinary cgi.

You can also test it using the Perl CGI test scripts from the source 
archive in %www/perl (just change the shebang line to your local 
Perl interpreter path).

Btw, Cheyenne resets all CGI ENV variables after each CGI request 
for security concerns, so don't be surprise to not be able to see 
them from shell.

It's working fine, thanks - I can confirm that I can  access the 
env variables from a Ruby CGI.

SVN revision 110:

FEAT: default REBOL CGI scripts are now run as normal CGI.

FEAT: new config keyword: fast-rebol-cgi. Forces running REBOL CGI 
scripts in FastCGI mode.

FIX: (Windows) CGI handler rewritten to fix environment variables 
passing.

FIX: CGI 'set-env mapping code refactored, setup errors are now properly 
logged.
FIX: CGI scripts errors are now logged in %trace.log file.

Windows binaries are available for testing:
http://cheyenne-server.org/tmp/cheyenne-r110-pro.zip
http://cheyenne-server.org/tmp/cheyenne-r110-cmd.zip

Maybe i'm confuesed. Is the callback a function of the web server 
or is it just how I setup my cgi script?

What is Cheyenne using DLL interface for?
 

- UNIX: CGI support, running as user instead of root, management 
of external servers (like PHP)

- Windows: CGI support, external servers (PHP), Desktop detection 
(for hiding working files), NT Services support, mutiple instances 
support, systray menu

DLLs are generally not cross platform too, no?

DLL are not, but the mappings to the DLL can be written easily in 
REBOL code, no need to go down to C. I see that as a big advantage 
in simplicity and maintainability.

/shell is available, just less powerfull.
Cheyenne requires /info, /output, /input and /error.


/output is not there, but in such a case /wait is sufficient - you 
can redirect to file, and read it after the return from the call/wait

If you want to have the slowest CGI support in the world, that's 
a good way for sure!

Doc, I wonder, It should be not that hard to use R3 for the cgi part 
only, right ?

I guess that not harder than using Perl as CGI or PHP as FastCGI 
under Cheyenne.

That's standard CGI, but what would be needed to give R3 a Fast CGI 
interface?

UniServe worker processes don't support multiplexed requests (multiplexing 
is the right word used in FastCGI specs IIRC). The FastCGI multiplexing 
mode requires a form of multitasking support to be able to handle 
all the incoming requests in a multiplexed way. Without that, you'll 
end up with just multiprocessing, which is what UniServe+Taskmaster 
are doing for CGI and RSP scripts.

There's no need for session affinity internally in Cheyenne, the 
session context is carried with the request to any worker process.


CGI/RSP requests are dispatched to any available worker process. 
If all are busy, a new one is forked up to the maximum number (8 
by default). If the max number of workers is reached and all are 
busy, the request is queued (the queue is global). Once a worker 
becomes available, it gets a new request assigned at once.

Graham, if you're concerned about performances and scalability, I 
don't understand why you're considering a CGI-based solution? AFAICT, 
Cheyenne/RSP is the most scalable solution for running REBOL code 
on server-side. If a single Cheyenne instance is not enough, you 
can use a nginx front-end to server static content and dispatch the 
load over several Cheyenne instances.


Our biggest online web-app has ~800 users, with several hundreds 
logging in each day, accessing a 400MB RDBMS with millions of records 
served by a single Cheyenne instance, with 8 workers (each taking 
15 to 25MB of RAM) running on a 2.2Ghz DualCore CPU with 2GB of RAM. 
Average Cheyenne load is 2 req/s with peaks up to 100 req/s (usually 
caused by web scanners or attacks). The webapp is still performing 
well under these conditions, and we have plenty of space to improve 
performances when it will be required (with faster hw and more instances).


Also, a key factor is optimizing webapp's code, especially for the 
most used RSP pages. Btw, a profiler would be a good addition to 
Cheyenne/RSP framework.

For example: 
json data: 
{
  "foo": "The quick brown fox jumps over the lazy dog.",
  "bar": "ABCDEFG",
  "baz": [52, 97]
}

and the js script to fetch the data:

<script>$.getJSON('http://localhost.jsontest.cgi', function(data) 
{
      alert("JSON Data: " + data.foo);
});</script>

This doesn't look like a valid URL: 'http://localhost.jsontest.cgi'

should be http://localhost/jsontest.cgino ?

my local script: 
<!DOCTYPE html>
<html>
<head>
  <style>img{ height: 100px; float: left; }</style>
  <script src="http://code.jquery.com/jquery-latest.js"></script>
</head>
<body>
	

<script>$.getJSON("http://localhost/jsontest.cgi”, function(data) 
{
      alert("JSON Data: " + data.foo);
});</script>
</body>
</html>

my rebol cgi script:
#!/cgi-bin/rebol.exe -cs %s %s
REBOL [Title: "json test"]
Print {
<html>
<head>
<title></title>

<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">

</head>
<body>
{
  "foo": "The quick brown fox jumps over the lazy dog.",
  "bar": "ABCDEFG",
  "baz": [52, 97]
}
</body>
</html>
}

Alan, I'm logged in to AltME from Ubuntu - so many non-ascii characters 
get displayed incorrectly. In your script the closing double-quote 
after /jsontest.cgi doesn't display properly. Perhaps you could check 
that it really is a double-quote and not a "smart-quote" in the actual 
source.

Amacleod: Your CGI script headers looks very wrong:
- What are those "%s" on the shebang line?

- /cgi-bin/rebol.exe: this doesn't look like a valid filesystem path

- Why the Content-Type header isn't emitted as required by CGI specification?


Maybe you should read again documentation about REBOL CGI usage on 
rebol.com site and also have a look at CGI sample scripts provided 
with Cheyenne source package. Understanding what a shebang line is 
might also help: http://en.wikipedia.org/wiki/Shebang_(Unix)

When i go to the cgi script directly in the browser I get my json 
data displayed. the cgi seems to be working.

- Why the Content-Type header isn't emitted as required by CGI specification?

not sure what this means..

I can see the data when I url the cgi script directly so cgi is working...

bighousefdny.com/cgi-test/jsontest2.r

Cheyenne revision 126:


FIX: (Windows) issue with current OS path in source mode and REBOL 
v2.7.8.

FIX: (Windows) 'set-env function not redefined if already available 
as native.

FIX: (Windows) CGI now properly uses call.r instead of native CALL.


Windows binaries re-released on http://cheyenne-server.org/download.shtml

This new version was required to workaround the native CALL/OUTPUT 
corruption bug that was affecting CGI binary output in Cheyenne.

so I'm not using rsp, or cgi ... its my own handler.

I think I have found an issue with /Core 2.7.8 on OS X, the READ-CGI 
mezz is missing! That's making Cheyenne (rev 127) crash on any CGI 
script request.

This CGI issue on OS X crashes Cheyenne in source mode and the PRO 
binary (the CMD binary is unaffected).

sounds weired because i thought i was using it in cgi mode

bind-extern CGI to [.r .cgi]
        bind-extern RSP to [.j .rsp]

It crashes only if you call READ-CGI.

ah, ok, i see it in source read-cgi

I have included the READ-CGI mezz in CGI.r to make CGI work on /Core 
2.7.8 on OS X. Testing, will push it in a couple of minutes.

Changes commited to revision 128:

FEAT: added support for 'access-os native. Now Cheyenne can work 
with /Core on MacOS X.

FIX: READ-CGI mezzanine is missing in /Core 2.7.8 on MacOS X, Cheyenne 
is now supplying it in such case.