World: r3wp

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

2. This one http://www.rebol.org/view-script.r?script=sqlite3-protocol.r
should work with RSP's DO-SQL, but untested. You still have the option 
to bypass RSP's DB layer to use any driver you like as you would 
in a normal script. Just remember that your code will be executed 
in several processes, so you can't rely on global words, nor assume 
that opening the connection just once will be enough...


Btw, doesn't SQLite have issues with write accesses from multiple 
processes? I've read that each process has to synchronize with others 
for write operations because SQLite don't provide such layer. Is 
this still true with recent SQLite version?  (Maybe I've just misunderstood, 
I have no experience using SQLite).

For storing shopping carts, do you really need a full database engine, 
REBOL blocks serialized should be enough, no?

1. "You can send it back by cookie or included in GET or POST data." 
Well, my understanding is that the YOU here refers to the delivered 
page. So, the page needs to be prepared a priori to delivering with 
either the session-id etc.

But if I do this, I won't need a cookie at all.


So, I first need to check if cookies work? Is there a simple test 
function in RSP like: COOKIES-AVAILABLE?

2. I think the new version 3.x can handle this case with different 
LOCK strategies. But such things are always dangerous :-)

3. Blocks: That's the way I want to go. Using the session ID to store 
shopping-carts. And than a clean-out run after several days or so.


The problem with the session-ID not being a cookie is, that the session 
is lost if the user closes the browser and later returns. Right?

1. Good point. You need to use the session/active? to test if a session 
has been automatically created, if not, that means no cookie support 
(require to serve a RSP page first, then check on the next call to 
a RSP page, an HTTP redirection might help you do so). Then, you 
can use session/start to manually start the session and send back 
the SID.

3. Session ID are lost when the browser window is closed. If you're 
on a LAN with Windows clients, you can try getting their Windows 
login ID.

1. Just to be sure I undestand:

First I call a simple RSP page which implicitly will create a session 
of possible.


If on the next call to an RSP page session/active? is FALSE, I create 
one manually. Take the SID and use either the URL or POST option 
to transport SID back and forth?

httpd.cfg: Any "documentation" for the options? What does PERSIST 
do?

1. Exactly

No doc at all for config options now (anyone willing to document 
that on Cheyenne's wiki?). Ask here for info, I, Will or other experienced 
Cheyenne user can anwser your questions. 


PERSIST will allow RSP sessions to survive to a Cheyenne reboot (by 
saving them temporary on disk).

Give me a login and hack it away.

Persist: Ok.

3. Ok. So, if the browser window is closed, the session cookie will 
be deleted? Or will the session survive a window close if the client 
accepts cookies?

Robert - dunno Cheyenne, but generally there is several types of 
cookies. Time limited, session limited (deleted by browser closure), 
and infinite ... IIRC (long time I last looked at the topic)

Yes, that's my understanding as well. That's why I want to cross-check 
what kind the session-ID cookie in Cheyenne is.

The cookie setter can specify a deletion date, in which case the 
cookie will be removed on that date. If the cookie setter does not 
specify a date, the cookie is removed once the user quits his or 
her browser.

So either lost or survive until a given date.

Are Cheyenne cookies encrypted? Would be nice IMO.