World: r3wp

I agree, I just need to figure out how to best integrate it.

Web-Apps Login: Is the login page always presented as first page 
if a user isn't yet logged in and tried to access an other page directly?


It depends, if you're using the AUTH keyword in the webapp config 
bloc, that's true. If AUTH is not used, you can access every webapp 
resource directly, it's up to each RSP to manage the access rights 
strategy. That's how CureCode webapp works. It uses a  common filter 
script called from 'on-page-start to control access.

BrianH: "I really need basic authentication though, with no cookies 
required. Either that or to be able to specify sessionids as get 
parameters, or maybe post sometimes."


Passing RSP session ID as GET or POST parameter is supported in latest 
release.

The only requirement I specified was that it be x86-compatible Linux. 
Someone else built it. Be sure to back up though, in case the instance 
goes away unannounced.

What is the parameter named?

Same as session cookie : RSPSID

That may be enough :)

:-) Anyway I'll add BA on my todo list.

Q does cheyenne support serving  https ?

I use Cheyenne behind https.

and stunnel.

DELETE: Is it hard to add? Adding HEAD too and Cheyenne would be 
a really nice REST application sever.

You have no idea .... Robert, we might want to talk one of these 
days. WInk wink.

;-)

I added all comments and information to the RSP Wiki page to save 
it.

HTTP Return Codes: Can I specify the return code myself in the response 
header? Or does CHE add it itself all the time?

Answer is here : http://cheyenne-server.org/docs/rsp-api.html#def-29

DELETE: it depends on what you mean by "add". If it's just allowing 
it to reach a RSP script, it's just a matter of adding it in a block. 
See my previous answer about DELETE. Btw, HEAD is already supported.

Yes, it just needs to go through to the RSP page.

BTW: Why not forward every request method to the RSP page? This would 
make it very flexible.

Because every web site running Cheyenne doesn't need RSP scripts. 
For example, softinnov.org is only using SSI (Server Side Includes).

Maybe only do it for RSP pages?

BTW: Is there any more information about SSI available? Or is it 
all straight forward?

If every request method were forwarded to RSP scripts, that would 
require that every RSP script provide a HTTP method handler sending 
a 405 return code for unsupported methods (to be HTTP compliant). 
Too much a burden for all RSP scripts.

SSI is supposed to be straight forward. You can have a look at Apache 
SSI online documentation. Cheyenne's SSI is currently just a small 
subset of Apache's SSI.

If I code a RSP script I know which methods to expect. So, the normal 
pages only use POST, GET. As soon as I create a site that uses other 
methods, I need to make XMLHttpRequest form the client. Than I know 
which methods to handle.

I don't see a problem here.

This is really a blocking point for me at the moment.

If I code a RSP script I know which methods to expect

 Ok, you know but Cheyenne doesn't know unless you told him. So if 
 you don't filter yourself (as you don't want it to be filtered by 
 Cheyenne), you'll most probably return broken pages to client using 
 HTTP methods you didn't expected.

I gave you a solution above to allow any method for your specific 
needs. It shouldn't take you more than 30s to fix it.

Ok, I will try. Even I don't fully undertand what to do.

Should be obvious when you see the code. ;-)

Re HTTPS: there's a ticket opened in RAMBO since October 2006 from 
Maarten asking for that : http://www.rebol.net/cgi-bin/rambo.r?id=4170&
. If Carl could fix it for 2.7.7, that would be a great new feature.

Perhaps it's not easily fixable?

At least Carl should tell us if it can be fixed within a few hours 
of work or needs several days.

What did Carl say when he was asked at the French Rebcon?

IIRC, he said that it was maybe just a flag to set to activate server 
mode, but he had to do some research about it first.

You have tp specifiy a certificate store and a server certificate 
as well. I'd LOVE to have this feature

well a couple of years research hasn't got far.  I wonder who else 
might help Carl enable this?  Is Holger around for a contract job?

I'll be sure to bring it up.

I use Cheyenne as a reverse proxy. I think in this setup the HTTPS 
things is handled by the primary web-server, communication to the 
revers proxy is non encrypted and hence this setup should make it 
possible to use Cheyenne's RSP with HTTPS. Not elegant but it should 
do the job.

yess this is how I have set it up before too... in a test I did with 
apache in front... the appache in revers dns also allows two distribute 
load on several machines, so it also allows to easily scale once 
you've got load.

Yep, that's the idea on it.

And at the moment I use VMs to distribute to other machines. So things 
can move around to different hardware.

DELETE: If I change mod-static/method-support I need to run cheyenne 
from source base. Is the SDK build method / script available as well?

Or should I send you a patch to add additional RSP-reachable methods 
via the httpd.cfg file?

To build a binary from Cheyenne source, just do : enpro (or enface) 
cheyenne.r

You can send me the patch by email.

and correct the include paths!

for your local environment.

SSI:Any examples available?