World: r3wp

Ah, yes, I guess I was lucky.

SVN r104: 

- FIX: port-id's relocation for multiple Cheyenne instances support, 
wasn't working correctly.


Do not use r103 binaries to run multiple instances of Cheyenne. I'll 
update the binaries asap.

Doing a little catch up here...

I'm having a little fun trying to set far future expiry dates from 
Cheyenne.


There seems to be some conflict between the httpd.cfg and the script 
as to whether the anem is expire or expires.

Having changed expire to expires, I get the follioing messages when 
I start up Cheyenne:


29/10-11:48:27.025934-## Error in [uniserve] : Cannot open server 
RConsole on port 9801 !

 29/10-11:48:27.053752-## Error in [uniserve] : Cannot open server 
 Logger on port 9802 !

 29/10-11:48:27.060870-## Error in [uniserve] : Cannot open server 
 MTA on port 9803 !

 29/10-11:48:27.061148-## Error in [uniserve] : Cannot open server 
 HTTPd on port 8000 
!

29/10-11:48:27.061893-## Error in [uniserve] : Cannot open server 
task-master on port 9799 !

anem -> name

Using RebCmd 0.9.20 with mod-expire.r from 0.9.19

Peter: the error you get is caused by trying to run multiple sessions 
of Cheyenne at the same time, see my post at Thu 19:04 about that.

About mod-expire, I'm not sure to see where precisely the conflict 
you're mentioning happens?

Thanks  Doc. I must have forgotten to stop a previous session before 
starting a new one.

I ferlt the conflict with mod-expires was:

htttpd.cfg

modujles [
   expires   ;; initially commented out
]

%mods/mod-expire.r

I'll check again.

I have mod-expire(s) working now - I changed the script name to mod-expires.r

I also have it working with by using expire in the list of modules 
with the script named mod-expire.r

I guess you had an old version, from SVN repo, it's "expire" in httpd.cfg.

Maybe I mistakenly added the s - not too worry, it's working fine 
now. 

Thanks for your help.

For Cheyenne fans, finally some logos to spread everywhere. ;-) 
http://cheyenne-server.org/blog.rsp?view=22

Nice.

Yes, nice ones

I'm having problems with post data and Rebol CGI scripts under Cheyenne. 
I ran a simple test scipt to simply echo back the post data:

#!/usr/bin/rebol -cs



REBOL []


data: make string! 1020

buffer: make string! 16380

while [positive? read-io system/ports/input buffer 16380][

    append data buffer

    clear buffer
]


print "content-type: text/plain^/"

print data


The script echoes back the post data when run under Apache but prints 
an empty line under Cheyenne.


(Just to check I ran a similar Ruby script which successfully echoes 
back the post data in Ruby).

I'm running 0.9.20 encmd.

I think this would work if you would force Cheyenne to execute it 
as a real CGI script

But normally, Cheyenne recognises a REBOL script and executes it 
as Fast CGI, in the UniServe process itself

Cheyenne has then already read the post data, and makes it available 
in the word INPUT

I think you can see this in the show.cgi example

Thanks Kaj. I'll take a look at it.

I would prefer to force Cheyenne to execute the script as a real 
CGI Script as I am trying to run REBOL/Services as a CGI script under 
Cheyenne. Ideally, I don't want to have to change the REBOL/Services 
code. (I am migrating a REBOL/Services application away from its 
existing web server and hopefully to Cheyenne. In the longer term, 
it may be possible to convert it to a Cheyenne web app).


Any hints on how to force Cheyenne to run a .cgi file as a real CGI 
script?

But why? It's a lot slower

Are there conflicts between REBOL/Services and Cheyenne?

REBOL/Services uses POST data and I'd prefer not to have to change 
the actual REBOL/Services code.

Or does REBOL/Services have a CGI interface?

Ah, then IIRC you have to add at least 256 bytes of junk before the 
REBOL header

Thanks, I remember now - I'll give that a try.

That works. I'll now try it with REBOL/Services.

Is it possible to disable debuging per page?

hm.. maybe it's not needed. Forget that.

But I've found a bug in the current version:
5/11-10:57:51.468-## Error in [mod-static] : Make object! [
    code: 500
    type: 'access
    id: 'cannot-open

    arg1: {/F/SVN/cheyenne-server/Cheyenne/log/h-arch.desajn.web:8080-access.log}
    arg2: none
    arg3: none

    near: [write/append join log-dir [req/vhost #"-" log-file] second]
    where: 'do-handler
] !
The #":" is not a valid char for a file name.

Is it possible to disable debuging per page?

Yes, that's a new feature of revision 103, use debug/off (see Changelog.txt).

Thanks for the bug report, I'll fix it before publishing the new 
revision.

SVN r105

FEAT: debug mode can now be restricted to a given client IP address: 
debug/options [ip: 1.2.3.4]
FIX: debug menu now inserted only in pages with HTML content-type

FIX: (regression) debug menu and RSP errors now displayed even if 
response/buffer is empty

FIX: inlined colors for debug trace window (to avoid CSS overloading)

FIX: bad log filename generation when using a virtual host definition 
that includes a port-id
FIX: Cheyenne logo updated for default test pages

I'll do some more testing tonight before releasing new binaries.

Revision 107 binaries now available: http://cheyenne-server.org/blog.rsp?view=23

Thanks

WOW.. I've been away for a while and cheyenne moves years ahead!! 
very cool!

Is anybody running cgi scripts under Cheyenne on OS X? It seems that 
the environment variables are not getting set as the driver only 
seems to load the set-env librarires for .dll and .so

Is anybody running REBOL/Services as a cgi script under Cheyenne 
?

What set-env libraries?

Do you mean the binding to the set-env function in the C library?

Is the REBOL Library component available and being loaded in the 
version of REBOL you're using?

Yes the binding to the set-env function in the C libary. I'm using 
the encapped REBOL/cmd version.