World: r3wp

Paul: FastCGI is implemented at low-level as an UniServe client protocol. 
It should be able to communicate with any FastCGI server like PHP.

Thanks Doc.

FYI : the new "Reset Workers" feature is not working well on UNIX, 
I'm working on it to fix it.

Cheyenne new test release delayed until tomorrow. Almost a dozen 
of fixes and useful improvements were added, mostly by Will (many 
thanks to him). So a little more time is required to run non-regression 
tests.

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)

Download links : 
- sources: : http://cheyenne-server.org/tmp/cheyenne-r0919.zip

- Windows test binary : http://cheyenne-server.org/tmp/cheyenne.zip
- Linux test binary : http://cheyenne-server.org/tmp/cheyenne.gz

Btw, the "Reset Workers" issue on UNIX has been solved in this release.

I've been asked to publish some stats for Cheyenne downloads, here 
they are (stats since 18 months) :

Source downloads : 978

Binaries downloads : 2372
   - Windows: 926  (39%)
   - Linux : 867  (37%)
   - OS X :  579  (24%)

Btw, here's some stats for cheyenne-server.org web site (online since 
jun-2008) :

Total page viewed : 48224

  - Static pages : 9824
  - Blog : 19179
  - Wiki : 19221

Doc, can RSP be used with other web-servers as well? I use lighttpd 
at the moment and would like to avoid changing my configuration on 
my production system.

Robert, one thing you can do for sure is reverse proxy rsp to cheyenne 
and serve static from lighthttpd 8)

Robert, write a few helper functions and use http://www.ross-gill.com/techniques/rsp/

that way you have overhead of launching/closing a process for every 
request

Maarten, thx. Didn't remember this one.


Will, well Rebol core is fast and it would be OK in the first place.

My code is scattered everywhere... it's a Darwinistic tactic

I'm using Cheyenne with Apache using the reverse proxy. Don't know 
it it's possible with lighthttpd. Let us know:)

Cheyenne's RSP with other web server : no. The reverse proxy technique 
works well.

Maarten, does your RSP version support things like session handling 
etc.? Is it updated to keep track with Cheyenne's version?

Of course not :-)

reverse proxy on apache2 with apache on one ip and cheyenne on another 
ip, put something like this in your virtualhost config:
	ProxyPass /00/core/ http://192.168.0.110/media/
	ProxyPassReverse /00/core/ /media/
	ProxyPassReverseCookiePath /media /00/core
of course you'll have different ip and path

this one is a little different and a bit more expensive on resources, 
if a request doesn't exist (no file match, no folder match) proxy 
reverse to cheyenne:
	DirectoryIndex default.html index.html
	RewriteEngine on
	RewriteCond /Volumes/data/web%{REQUEST_FILENAME} !-f
	RewriteCond /Volumes/data/web%{REQUEST_FILENAME} !-d
	RewriteRule ^(.*)$ http://cheyenne.com$1 [P]

one advantage of proxy reversing is you can gzip with apache, rebol 
doesn't do that natively

of course you'll have to enable the proper modules in apache and 
for the first example, you only need ProxyPassReverseCookiePath if 
path do not match 8)

Do you guys advise running cheyenne behind reverse proxy or direcly 
on web in general? (if I would use reverse proxv I would try nginx)

New Cheyenne v0.9.19 test release available at http://cheyenne-server.org/tmp/cheyenne-r0919.zip.
This should be the last one before making 0.9.19 the new official 
version. 

ChangeLog (diff from previous one) :


    o RSP: fix in request/query-string allowing processing parameters 
    values passed through 'validate filter.
	   

  o RSP: output of RSP scripts is now compressed (using deflate) if 
  the client supports it.
	   

  o Default static files memory cache now set to 4Mb accepting files 
  up to 64Kb.
	   

  o Mod-static: fixed a bug in Last-Modified date forming when seconds 
  = 0.

Proxy : I run all my Cheyenne servers directly on web. Adding a reverse 
proxy frontend like nginx might be usefull for heavy loaded sites 
(millions hits/day) or when you need load banlancing and fault tolerance.

aha, thanks, I will run it directly too then

Janko, Cheyenne is very fast (try benchmarking with siege or ab)! 
I have heavy loads and special configurations, it has been asked 
how to make it work with lighttpd, so the discussion.. 8)

Thank you Dock, I'll check new deflate asap 8)

Is there much overhead compressing pages before sending?  I know 
that most modern browsers support deflate...

The compression overhead is small compared to the time gained on 
the network transfert. Here's a study from intel on that question 
: http://software.intel.com/en-us/articles/http-compression-for-web-applications/

I just measured loading times on CC using pages with 200 tickets 
listed. On average, before compression ~700ms, after ~300ms. (40ms 
latency between my PC and the server).

Good to know, thanks!

Download links : 
- sources: : http://cheyenne-server.org/tmp/cheyenne-r0919.zip

- Windows test binary : http://cheyenne-server.org/tmp/cheyenne0919.zip
- Linux test binaries : 
	o Enpro : http://cheyenne-server.org/tmp/cheyenne0919-pro.gz
	o Enface : http://cheyenne-server.org/tmp/cheyenne0919-face.gz

Will: that is exactly what I did when I tried to use it and saw the 
workflow/api very nice, then I tested the req/sec and I astonished 
reported here :) (1 month or so back)

yes, it's very fast... still don't fully get it :)

I have some more questions:


1. Is it possible to use virtual hosting? I have a bunch of doamins. 
Lighttpd has a super-simpel and easy way to support virtual doamins.

2. I think that things like PHP etc. is supported as well, right?

1. yes   2. It has php support (I haven't tried it yet)

PHP needs to be patched first on UNIX before being usable by Cheyenne, 
see : http://www.cheyenne-server.org/blog.rsp?view=15

Why is there a patch necessary?

The behaviour of PHP in FastCGI mode is not consistent between Windows 
and UNIX. The way it works under Windows is the one that seems the 
closer to FastCGI specifications. It seems that the UNIX version 
has some hardcoded parts to support specific web servers handling 
of FastCGI. Cheyenne relies on the persistent feature of FastCGI 
connections, other web servers dropped that because it was too complicated 
to support and made them instable. So, the UNIX FastCGI PHP code 
was tweaked for them instead of following the specifications.


So it has the bad effect of closing the FastCGI connection if no 
request is sent just after the connection is opened. Cheyenne opens 
the FastCGI connection when started and maintain it opened as long 
as possible. The patch is here to prevent PHP closing immediatly 
the opened connection because it doesn't receive any request.


I should check the latest PHP 5.x release to see if this behaviour 
has changed.

Btw, the patch just consists in adding a " break; " at the right 
position in source code to avoid the other web server specific code 
on opening connection.

Ok.

Sounds like a quirk that took some time to find and fix...

You guess right ;-)

Another fine mess

Before setting-up the reverse-proxy config so that I can use cheyenne 
with all RSP features I have some questions:


1. Session handling: I understand that sessions can now be used via 
cookie, URL-parameter or POST data. How do I select which method 
to use? Can I start with Cookies and if this fails (can this be detected?) 
fall back to the other methods?

2.  SQLite: Is there a RSP compatible SQLite driver or is this not 
required? Meaning, I can just use the normal SQLite driver?

I want to write a shopping-cart module without any GUI stuff etc. 
Just a plain shopping cart where you can add, change, remove products 
and provide a lot of special parameters like handling-fees, etc.


Displaying the content of a specific shoppig-cart should work by 
calling a RSP page, that selects the correct shopping-cart through 
session ID and just generates a simple table etc. at the right place 
in a styled web-page.

1. When first accessed, a RSP web application will send you a session 
ID by cookie. You can send it back by cookie or included in GET or 
POST data. If you want your session ID passed inside the HTML page 
in all URLs, you have to add it in your RSP source using some code 
like : rejoin ["RSPSID=" session/id].