World: r3wp

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

thanks for the info. But I will also check stunnel.

No way yet of encapping a webapp with Cheyenne?

That requires a virtual filesystem and deep patching Cheyenne to 
use it. I've tried to make one a few months ago, but hadn't enough 
time to finish it. It's a feature I need too (but low pri currently).

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.

A few words about the new MTA and email capabilities :


- Emails are written to disk before sending in async mode. Upper 
email size limit is 2GB. Concurrent emails sending supported (limited 
only by machine resources).

- Only the higher priority MX is used (fallback on others MX should 
be added soon).

- The MTA currently supports only 8BITMIME compliant SMTP servers 
(fallback to 7bit mode will be added if it still make sense to support 
it).

- MTA will  try to send an email once. If the server is busy, it 
will report a failure. Deferred retries will be added using the scheduler 
module (if MX fallback is not enough).

- Emails queue saving should be added in next update (the queue will 
survive to server restart, but not server crash).

- Automatic failure reports are sent back to emitter (From: field).
- Reports can be fully customized.

- Still needs a lot of testing for tracking small errors or issues 
that can trigger antispam filters (e.g. gmail is very picky about 
correct emails format).


You can test it using the provided test script : http://localhost/email.rsp

In addition :

- custom charset can also be set (default to ISO-8859-1").
- attached files are supported.

SVN r18: 

DOC: added quick syntax overview for email API in %www/email.rsp

Btw, in order to forge emails to be sent, I've tried to rely on REBOL's 
builtin email support functions (big mistake!). You should know that 
they *are not* RFC compliant, the biggest issues being :


- emails produces by REBOL are using LF as EOL instead of CRLF (RFC 
2822). See http://cr.yp.to/docs/smtplf.html

- headers are not encoded for non ASCII-7bits characters (RFC 2047)


So, I've deeply patched the builtin code at runtime to workaround 
this, but, I should have better rewrote it all from scratch (that's 
what I intend to do when I'll have enough free time).

Write up your patches and we can see about getting them integrated 
into the next version of R2 :)

I didn't though that Carl would still support R2 by providing new 
versions...(surprising but) good news. :-)

We need it for R3 too, so it would be wonderful if they could be 
written simultanoeusly.

nice on the mta ... maybe I should get back to work on my mail server

I'd probably use Amazon for email.

stick the email in a SQS queue ... and remove from the queue when 
the send is successful.

so that way the cheyenne mta can keep trying over 4 days to send 
the mail.

If my cheyenne server goes down .. I can resume from another instance.

Cheyenne can be configured to work that way too, but is it desirable? 
I remember the way email was handled 15 years ago, when having failure 
reports after one or 2 days wasn't bothering anyone, but today, we're 
in a world of fast communication (often realtime). When I send a 
mail from gmail, if there's an issue, I get a report in less than 
a minute or two.

I had an email that took 2 days to get a report back from gmail that 
it could not be delivered.