World: r3wp

To support R3, you have to either hack CGI.r source code to force 
REBOL script to use the general strategy (simple to do, but probably 
poor performances) or implement a mod-R3 extension to setup a custom 
R3 persistent server (more work but faster result).

if you remove REBOL header, will R3 accept to run the script?

hmm, but then I get - ** Syntax Error: Script is missing a REBOL 
header ** Near: do/args script system/script/args

:-)

that is - for R2. I changed REBOL [] to REEBOL in order to get sheband 
line active. The strategy could be simplified, but the 'either code 
would have to be reordered ...

Simply put - if sheband line is there, us it, easy as that. I don't 
understand why normal REBOL header takes precedence ... putting sheband 
line into action is problematic, if you somehow need to use rebol 
script, without REBOL header ...

Hacking CGI.r seems easier. Just patch it to avoid REBOL header detection 
like this: 

script: none		; <= add this line to force classic CGI 
either all [
	string? script
	not empty? script
][

yes ... that is patch for incorrect logic, but easy one :-)

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 ...

I chosed the simplier and most efficient solution for the user. Having 
to support REBOL scripts using same  header than R2 but with a R2-non-compatible 
kernel was not something planned.

interesting that we've got get-env, but not set-env function in REBOL. 
Either R2 nor R3 do have it ...

btw - it seems that Carl's beta plan might be a bit larger, if he 
is about to accept many additional user requests. There are still 
important things missing, and without them it imo does not make sense 
to call R3 a beta ...

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

In my book "beta stage" is reached when the product is (mostly) feature-complete 
and all the known bugs are fixed.

re bugs - I am more forgiving - look at Mozilla or KDE - they would 
never release, if all bugs were supposed being fixed :-) Re bug-fixing, 
we are imo OK last 6-8 months - 100 tickets a month is not all that 
bad. But missing stuff ppl mentioned in reaction to blog, I really 
wonder how Carl decides about it ....

Answering in !REBOL3

note to self: Always start Cheyenne with sudo...

Or ... better yet, use NAT to reroute port 80 to something above 
1024 and run Cheyenne from user space listening on the non-priv'ed 
port??  Safer (I think) if anyone ever assumes control of your server 
internals.  Or do you need root powers for something other than listening 
on port 80?

Hmm... generated VID Extension Kit docs on the fly for website in 
0.009 seconds. Looks like there are things to optimize. :-)

I used response/set-status/msg to get appropriate error messages, 
but I always got just the standard message.

It works here : 
<%response/set-status/msg 201 "Test"%>

15/9-08:46:50.9-[HTTPd] Response=>
HTTP/1.1 201 Test
Server: Cheyenne/0.9.20

<%response/set-status/msg 404 "Test"%>

15/9-08:48:28.118-[HTTPd] Response=>
HTTP/1.1 404 Test
Server: Cheyenne/0.9.20

Do you have a short example script showing the issue?

This is the relevant part in a failure block 
<%
..     [
	response/reset
	response/set-header 'Content-Type "text/html"
	response/set-status/msg  404 "Person not found"
	response/end
 ]
%>

Thanks, testing that.

I get the following response, looks OK :

15/9-11:07:53.546-[HTTPd] Response=>
HTTP/1.1 404 Person not found
Server: Cheyenne/0.9.20
Date: Tue, 15 Sep 2009 09:07:53 GMT
Content-Length: 53
Content-Type: text/html
Connection: Keep-Alive

strange, 
neither in a browser nor im Rebol  with trace/net I see that.

it seems they all rewrite the answer they present to the user.(

by the way, what's the status of ssl?

What is the best way to make domain.com to www.domain.com redirection 
in Cheyenne .. (seo guy advised me that).. in apache you use mod_rewrite:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.site-assitant\.com$ [NC]

RewriteRule ^.*$ http://www.site-assitant\.com%{REQUEST_URI} [R=301,L]

are you sure it's not a cached version you're seeing?

i.e put some traces in the failure block

No SSL unless you use stunnel or similar

sqlab... I used nginx in front of cheyenne to have SSL  .. here http://www.cebelca.biz

it was quite simple , I just joined two examples from their tutorials 
.. the SSL and the reverse proxy one .. I can give you the config 
file

(using the above test RSP script)

>> read http://localhost/set-msg.rsp
connecting to: localhost

** User Error: Error.  Target url: http://localhost/set-msg.rspcould 
not be retrieved.  Server
 response: HTTP/1.1 404 Person not found
** Near: read http://localhost/set-msg.rsp

SSL: It can only be supported by using a third-party front-end like 
stunnel or nginx.

Janko, can you post your config etc

Best way to redirect domain.com to www.domain.com: correctly setup 
the DNS records.
Best way to do it in Cheyenne: (untested)

domain.com [
	root-dir %/...
	redirect 301 "/*" "http://www.domain.com"
]

www.domain.com [
	root-dir ...
]

An alternative way could be to defined a default /index.rsp script 
with <% response/redirect/last http://www.domain.com%> (use /last 
refinement only with v0.9.20+)

For my web sites, I always achieve domain aliasing using CNAME DNS 
records.

ok, clear now.

In httpd.cfg was the default on-status-code 404 activated. I had 
just removed the custom error page.

I will give nginx a try

nginx+cheyenne is a great combination! 8)

how I use it: nginx get all the requests, if a file is not found 
it will proxy-reverse the request to cheyenne wich is configured 
with a on-status-code [404 trap.r] . trap.r check the url request 
and either load and respond with an rsp or send a 404

nginx has nice things like you can pre gzip your static content so 
it wont have to compress for each request