World: r3wp

:)

The session cookie problem is related to incorrect timezone calculation 
in cookies expire time. I'm making a fix for Cheyenne, but due to 
a REBOL bug on Windows (http://www.rebol.net/cgi-bin/upnews.r?view=0005), 
I can't find an easy solution for that platform...

So I guess that I'll add a config option for setting the correct 
timezone for Windows users manually and for /Pro users, I'll support 
the GetTimeZoneInformation() win32 function for automatic setting.

Cheyenne release v0.9.12 beta. Download at http://softinnov.org/tmp/cheyenne-r0912.zip

Changelog :


 o do-sql function improved to support RT's DB drivers. /flat refinement 
 is 
	  supported now too. ODBC insert error fixed too.
	
	o RConsole prompt changed to "Server>"
	
	o CGI's 'path-info now returns the request URL.
	

 o Fixed a bug in RSP session destruction potentially corrupting the 
 internal 
	  session list and giving weird results or behaviour.
	  

 o Fixed a timezone computation bug that was setting incorrect expire 
 times for 

   session cookies, resulting in unstable behaviour. All platforms except 
   Windows.
	  

 o Small patch to parse-request-line func in HTTPd.r to be more 'mod-rewrite 
	  friendly.

Great .. and we can get to test while you sleep :)

global and per domain rewrite rules,  http://reboot.ch/mod-rewrite.r
or http://reboot.ch/mod-rewrite.r.zipalpha quality, whatch out ;-)

Doc!  You da Man!  Thanks muchly.

I'm still not having any luck runing php scripts.  test.php does 
not produce a result...jst a blank page.

never mind...it appears the test script is missing the "php" after 
the <?

doesnt need it

There's some tips I posted earlier in this group

Nenad, proably not necessary to have a method to restart modules 
after modifying... simplly dumped the code into an external file, 
and 'do that instead.

do you 'do them at each request ?

um.. i 'do a script to handle my url-to-filename phase

Im intercepting 404s.. and processing them through a main script 
that handles the DB, generates responses etc.

One problem i just realized is passing  arguments (just started this 
10 mins ago)

I'll probably load the main handler into the module.

or load the functions when I boot cheyenne... this build function, 
reboot server, test thing is annoying

good thing it's not compiled ;)

Im catching the 404s nicely now.. loading up the mootools JS library, 
and pushing dynamic JS back to the page via Ajax.

I'm glad you're having fun with Cheyenne :-)

Actually, using..  do load %myfile  in my url-to-filename phase.. 
it's loading the functions each time, but I'll move them into main 
boot script when they're stable

only a true geek has fun with this stuff.

( I guess that makes me a geek ;)

So, what are your near future plans for cheyenne?

reach v1.0 ;-)

add all the missing features planned for v1.0 (see the cheyenne's 
web page for more info)

I might be able to help with  this.. 
Customizable HTTP error pages.

What did you have in mind?

RE: "How does Cheyenne's performance and security stack up against 
the other indians (Apache, Cherrokee, Hiawatha, ...)?"


Speed: close to Apache2.x for static files (tested a year ago, so 
new tests need to be conducted).


Security: not chroot-ed and no special protection against ddos attacks 
like Hiawatha, no bandwidth throttling (could be added), no CGI time 
limit (could be added), passes Nikto generic security tests flawlessly 
(last time check : few months ago)

Customizable HTTP error pages: server-side redirection on 4xx and 
5xx errors to any pages, user-defined in config file.

I think a biggy will be SSL support

Have you looked at openSSL ?

Well, I have SSL running in Cheyenne.. it's not pretty, but was quick

I suppose one issue will be connecting to the library.. would require 
view/pro?  Can call the binary, but it's a less elegant solution

Why is it not pretty?

This method is for windows.. and runs a shell

stunnel ?

If you want to try this method for windows.. here's what you do.. 


1) download the windows binary from openssl.. ->   http://www.slproweb.com/products/Win32OpenSSL.html

2) Unzip.. and pull out the openssl.exe file from the bin folder.. 
. drop that file into your cheyenne www folder
3) Create a self-signed cert....
3a) run openssl.exe

3b) enter this line: req -x509 -nodes -days 365 -newkey rsa:1024 
-keyout localhost.pem -out localhost.pem
(localhost is the cert name)

3c) answer the questions... when asked 'who are you?' enter your 
domain,  or 'localhost' as I did 

This will generate the cert in your www folder (this is just a demo... 
the openssl server uses it's location as root www folder)

4) Start up the server... enter this line into openssl:  s_server 
-accept 443 -cert localhost.pem -WWW


Now open any file in your Cheyenne www folder using the https:// 
 protocol

you only need the openssl.exe file for this demo

If you acess Cheynne as https://localhost/myfile.htmlyou won't 
get the second cert warning

Stunnel would work

Wonder what Carl has in mind for library access with R3?

Can always call, but lib access would be nicer.

http://www.compkarori.co.nz:8080/wiki/index.php/HowTos:Stunnel

no go for me

well, I didn't try it ..just documented it!

ok.. working now

So, the howto is correct?

i missed the comment  in front of ;https[] in config

yeah