World: r3wp

What OS are you using on EC2?

I went with a web app for the database connection management and 
authentication, but now I find out I need to support stateless clients. 
So, no persistent cookies. Help?

18th March "No builtin support for basic auth. You need to provide 
your own code. 'on-page-start would be a good place to put that kind 
of filter."

Thanks for digging up that post. :-)

Darn. I'll figure it out tomorrow then. Any problems with creating 
a throw-away session every five minutes?

Just shows I wasn't the only one wanting ( not necessarily needing 
though ) ba.

:)

Brian: It shouldn't be a problem. Sessions block is hashed, so session 
access time is constant and the only impact is on memory usage.

Graham: I suspected a hidden message ;-).

Was I so transparent ??

Brian.. are there any special requirements to run cheyenne on EC2 
or is that like any other vps?

Taking the time to read all messages back to 18h March to dig it 
up was most probably driven by another goal than just saving me from 
re-typing it. :-)

ummm.... see the magnifying glass top right?  It's called a search 
tool :)

hm.. I need to figure out one day how those EC2 prices "$0.10 per 
instance hour" translate or compare to some small VPS

Damn, that's the first time I'm noticing that feature in AltMe!

much more expensive

If you run your EC2 instance 24/7 ... probably 3x the cost or more

I run 2 cheyenne webites (site-assistant and qwikitodo) and 2 apache 
solr servers and a bunch of rebol bots on 180MB RAM VPS for 12EUR/month.. 
and pages load in a snap (unless I add sqlite update/delete/insert 
to the pageload)

All kidding aside, BA would be useful .. it's also needed for mod-rest.r

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. ;-)