World: r3wp

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.

just wanted to drop by and say that I published alpha of my first 
mini cheyenne webapp and it is the most responsive app I ever made 
.. it is noted also when not on local comp and someone of 2 peps 
that tried it already wondered how come it loads so fast ...  this 
is minimal app so it looks more reasonable but I know a slightly 
bigger app that I am making behaves just as fast for now..  have 
to run.. will read this cookie discussion other time

Cheyenne's RSP uses browser session limited cookies. They are not 
written to disk and are lost when the browser is closed.

I don't see the point of encrypting session cookies, they are just 
random keys.

Janko, nice to know. Are you using the latest Cheyenne 0.9.19 with 
RSP compression support?

Encryption: I meant this to use for normal cookies.

Is HTTPS supported? If not, can I make use of lighttpd HTTPS support 
with this revers-proxy setup?

Cheyenne doesn't have built-in SSL support (Carl never enabled server-side 
SSL for ssl:// scheme). The "lighter" way to support that is to use 
a specific wrapper like stunnel. Lighttpd in reverse-proxy is ok 
too, but maybe overkill.

Cookies: I never store data in "normal" cookies, only keys that reference 
data stored on server.

I've used YUI with Cheyenne before ... but am now looking at a different 
Javascript library.

jQuery seems to have a lot of traction, and there is this great set 
of introductory videos on how to use it http://nettuts.com/articles/web-roundups/jquery-for-absolute-beginners-video-series/

Note that videos for days 8 and 9 don't work.

Just unpacked 19 again and ran it .. noticed this


16/2-16:33:37.109-# Warning in [RSP] : Include RSP failed: max inclusion 
level reached - file: %inc.rsp !

just running the demo testapp

Getting this when trying to load my login.rsp page in my webapp


16/2-16:46:24.353-## Error in [task-handler-49652] : Make object! 
[
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'protected-exec
    arg2: 'code
    arg3: [block! function!]

    near: [protected-exec/event request/parsed/file get in session/events]
    where: 'fire-event
] !

all I did was create a new webapp directory and renamed the webapp 
directorie to point to the new directory.

Warning message: that's normal and part of the RSP script I use for 
testing. Currently the internal request forwarding system has a hard 
limit (4) on the number of recursive calls. When the limit is reached, 
a warning message is logged.

Error message: it looks like there something wrong with one of the 
'on-* handler in %app-init.r

When you renamed the webapp, did you update all the config options 
in %httpd.cfg accordingly?

Webapps: What is this and how does it work?