World: r3wp

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.

The code in the Cheyenne cgi.r handler will only create the library 
binding for Windows and Linux.

I could patch cgi.r if I was certain that I should use /usr/lib/libc.dylib 
in place of /lib/libc.so.6 or .5

So do you have the Library component on OS X? That's what's needed 
to do it

Yes it has the Library component:

Is OS X detection missing in Cheyenne, then?

This is the code is cgi.r that creates the binding;

any [
				all [
					system/version/4 = 3			; Windows
					libc: load/library %kernel32.dll
					_setenv: make routine! [
						name	[string!]
						value	[string!]
						return: [integer!]
					] libc "SetEnvironmentVariableA"
					body: [_setenv name value]
				]
				all [								; UNIX
					any [
						exists? libc: %/lib/libc.so.6
						exists? libc: %/lib/libc.so.5
					]
					libc: load/library libc
					_setenv: make routine! [
						name	[string!]
						value	[string!]
						return: [integer!]
					] libc "setenv"
					body: [_setenv name value 1]
				]
			]

As you can see it is missing OS x

Detection is in misc/os.r. It's very simple, so I think it should 
work

It's not the detection that's missing, it's the binding to the correctly 
named lib that is missing.

Tracing it. That's odd: the general binding is done in misc/macosx.r. 
I don't see why cgi.r should do it double

You can copy the relevant code from macosx.r to cgi.r

Thanks, Kaj  - I'll try to check that out later.

Tracing it. That's odd: the general binding is done in misc/macosx.r. 
I don't see why cgi.r should do it double

The CGI.r code is run in a separate process, it inherits OS bindings 
from misc/macosx.r only when encapped. It should have worked using 
the  /cmd binary, I need to look into it and patch the CGI code to 
not bind twice when encapped.

Just to confirm that I am running the /cmd binary.

.. and am running CGI scripts not fastCGI scripts - I even checked 
that the env variables are getting set by running a trivial Ruby 
cgi,.

.. and they are not getting set.

and am running CGI scripts not fastCGI scripts

 REBOL scripts are run directly by CGI.r, the CGI interface is emulated, 
 set-env is not used for REBOL scripts. I'll do some testing with 
 non-REBOL scripts on OS X today.