World: r3wp

-w as REBOL option (to not confuse with Cheyenne's -w option).

sure

Here is the SDK documentation about encap headers: http://www.rebol.com/docs/sdk/encap.html#section-8

which means im not supposed to hack cheyenne (easily) unless i buy 
the SDK and learn encap?

because in turn that's what it means not to include this specific 
"trick" into cheyenne's documentation

and since im running it with the plain rebol/core, i wouldn't have 
thought that encap header might be relevant

You can hack Cheyenne as much as you want. The SDK is only required 
if you want to build a binary version of Cheyenne, which is not mandatory 
for using Cheyenne, even in production.

The encap header is only revelant if you build a binary, it is ignored 
if run from sources.

aahha... i was using the -w as usual, that's why i didn't see any 
output when i was starting cheyenne from source.

normally i use -w, otherwise pipeing the output doesn't work properly.
okay, everything makes more sense now.

Good. :-)

The binary is mandatory for using Library

command/core has library

Most people don't have Command/Core

nowadays, I think command is only available via the sdk, no?

should the hosts be configured via IP addresses?   it seems php has 
issues using localhost as a domain name.

## Error in [conf-parser] : Error in conf file at: !

was caused by writing a debug word outside of a vhost definition...

should = "should it be possible to configure host via IP addresses" 
?

u mean vhost? the docs says it is possible. but u can't listen on 
a specific address only -- it's a rebol limitation

yeah, but it seems php prefers using 127.0.0.1 instead of localhost, 
but my client is reporting cheyenne errors (I haven't tested it yet)... 
just want to know if its possible first.

Declaring a vhost using an IP address: yes and it is documented in 
the wiki.

onetom: thanks for reporting the cause, I will test that locally 
and see if I can improve the error message for such cases.

doc: it's not a big problem. red is a higher priority :)

Sure, but I can multiplex with small Cheyenne fixes as long as it 
doesn't take me too much time.

thx

hmm... cheyenne binary and the source works differently w the same 
configfile.
$ cheyenne --version
0.9.20.129
WORKS
latest source doesn't work with the following config:

modules [ internal extapp static action rsp alias ]
globals [ listen [8080]    bind RSP to [ .r ] ]
guan-huat [ debug root-dir %./ alias "/docs" %jsondb/to-json.r ]

im testing w $ curl http://guan-huat:8080/docs/test/1

bind-extern makes no difference

oh, the problem is im getting a 404 if i run the source version of 
cheyenne

Are you using sources v0.9.20.129 too?

Hmm, shouldn't make much differences between revision 129 and latest 
135...

You should search in the Cheyenne console logs for "[HTTPd] Translated 
file:" to see what file Cheyenne is trying to read. That should give 
you a clue about what is causing the difference.

no, v0.9.20.129 is binary

Translated file: %./jsondb/to-json.r
in case of the source version; so there is no differnece there.

http://piratepad.net/KkvkZ9AtME
i put the correct and the incorrect logs here

i pasted the command lines too

it works if i copy over my stuff into cheyenne's dir and start cheyenne.r 
from there

I guess Cheyenne should be able to figure out where are his own files 
if launched from another folder. I need to setup a test configuration 
on my linux box to investigate such case.

But tomorrow, too late now here. ;-)

Got you email, thanks.

i thank u.

it's 6:34 here, but i slept most of the day coz im close to having 
pneumonia again...

hmm... sessions are not persisted anywhere?

anyone wrote some memcached or tmp file storage for sessions?

They are persisted on disk if you specify in globals section of config 
file:

    persist [sessions]

noted here: http://cheyenne-server.org/wiki/Config/Persist
is it ok, or there is a better place for it?

That is the right place, thanks!

how can i implement a login form without sending the password in 
clear text?

should i ask for digest authorization?

switch to HTTPS.

i can't find the "switch" :) ... i hate this cert and crl based pki 
crap...

any drawback of using http digest, beside not being able to provide 
a nice login page?

Not AFAIK.