World: r3wp

I've tried a lot of different hand-crafted request to try to crash 
Cheyenne and reproduce your issue, but Cheyenne is keeping responding 
right.

apparently it's an older version, as I can't use the debug features.

(why do I always get duped by cheyenne version numbers...)

oh well, installed new version, so we'll see if it happens again.

curiously, now I have hanging worker processes, when I stop cheyenne.

Are you using a PHP engine through FastCGI?

no, pure REBOL. I found now that using READ inside app-init.r causes 
this hang for a worker process as well.

READ should behave the same wherever you use it, in app-init.r events 
or RSP scripts.

I'm getting a number of very strange things. DO doesn't work either.

aha, so errors are buried a bit deeper than I thought.

getting more random hangs...

If you upgraded from a really older version, you might get some issues 
with the libraries loading from app-init.r as DO behaviour was changed 
in more recent versions.

I rewrote app-init.r for this version.

By default, DO binds the code to the webapp execution context, to 
get the native DO (with binding to global context), you need to use 
DO/GLOBAL.

aha

You can quickly port all older code by just adding /GLOBAL to all 
DO calls (especially for global libraries loaded in app-init.r).

Also, you should also delete the .rsp-sessions file if present before 
starting Cheyenne (to avoid loading possible obsolete sessions structures 
in never Cheyenne version).

(dinner time, bbl)

delete the .rsp-sessions file if present before starting Cheyenne
 - Why does Cheyenne not do this on start?

btw: I yesterday used Ladislav's excellent!! closure with cheyenne 
and it didn't work. Then I found it's because of do which it uses 
.. It worked once I changed it to *do

Janko: DO/GLOBAL is the official way, *do is just for internal use.

Henrik: Cheyenne does delete it, but before that it loads it in memory. 
That's why I've said that you should manually delete it before Cheyenne 
is restarted, to avoid it being loaded back.

This file is used to save on disk sessions objects when Cheyenne 
is stopped.

but isn't that precisely what causes the problem?

It can cause some problem only when you're changing Cheyenne version 
or when you're upgrading your app and changing the data structure 
format stored in sessions. You can enable or disable it using the 
PERSIST config keyword described here: http://cheyenne-server.org/wiki/Config/Persist

The main point of making sessions persist on disk, is to allow Cheyenne 
to be restarted without loosing user's sessions (and force them to 
log in again).

Maybe this is interesting: Causing a DoS by reading server responses 
very slowly:


https://community.qualys.com/blogs/securitylabs/2012/01/05/slow-read

There is not much that can be done at HTTP level to protect against 
that, unless you get back to HTTP/1.0 and forbid keep-alive states. 
It is also worth mentioning that multithreaded servers (one client 
connection = one thread), will suffer much more from such attacks 
than event-based single threaded ones.

Does cheyenne websockets work with socket.io (http://socket.io/) 
or some other third party client library that allows websocketes 
to work on mobile and non websocket browsers?

As long as clients use the standard websockets protocol, they will 
work with Cheyenne.

sqlab Re: Win-Call


Have you tried using the full "command", I suspect that may be the 
problem you are facing:

>> do %call.r

Script: "Untitled" (none
)
>> win-call/output "cmd.exe /c dir" str: make string! 1024

== none
>> probe str

{ Volume in drive C has no label.^M
 Volume Serial Number is F4A6-6294
^M

^M
 Directory of c:\Red\quick-test^M

^M

09/11/2011  18:26    <DIR>          .^M

09/11/2011  18:26    <DIR>          ..^M

09/11/2011  06:16             6,148 .DS_Store^M
13/10/2011  18:16             8,545 call.r^M
etc.

thanks, this seems to work better

unfortunately not all is working. I still get back nothing or the 
error file for some operations, that work with call.

If you let me know which ones, I'll try them out on my machine .... 
but I won't be able to do so just now.

win-call/output  "plink.exe  -l user -pw password [checkall-:-host]  
df "  str: make string! 1024
tia

You can use SDK v2.7.6, it has no issues with Call on Windows, AFAIR.

The plink example didn't work for me. I got the following message:


>> win-call/output "plink.exe -l user -pw password [checkall-:-host] 
 df "  str: make stri
ng! 102

4
== {CreateProcess failed!: The system cannot find the file specified.}

Though I got a similar message from the console:

C:\Documents and Settings\Peter>plink.exe -l user -pw password [checkall-:-host] 
 df

'plink.exe' is not recognized as an internal or external command,
operable 
program or batch file.

plink is a ssh command line tool  of the putty package

maybe win-call uses a different home directory for the key file

I have a problem with cheyenne-r0920-cmd.exe on Windows, when I comment 
database section in my http.cfg it works, when I uncomment it gives 
the following error in chey-pid-9036.log file:


25/1-17:58:14.625-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: "/E/cheyenne/www/centrex//index.rsp"
    arg2: none
    arg3: none
    near: [info? new [
            req/in/target: form file 
            if ext: find/last req/in/target dot [
                req/in/ext: to word! ext 
                req/handler: select service/handlers req/in/ext
            ] 
            if not req/in/file [req/in/file: new] 
            if d?: declined? req [return false]
        ]]
    where: 'throw-on-error
] !


note that there is double slash before index.rsp I don't know why. 
Error happens before I use any do-sql or something. Web page doesn't 
work at all.

Oh when I moved database section from WebApp to globals section then 
it works!

Can you reproduce the same issue with latest revision from sources?

I will test tomorrow morning.

Doc: Same error with latest r173 version.

I just put the databases block into webap block, didn't change anything 
in the testapp,

	webapp [
		databases [
			cdr	odbc://sa:[qwe123-:-cdr]
		]
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp"
		;debug
	]
error is:
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: {/E/cheyenne-sources/Cheyenne/www/testapp//index.rsp}

Note that the double slash in arg1.

Chrome shows "No data received"

Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection 
without sending any data.

Thank you for the test, I'll will try to reproduce it here.

Doc: I found where the bug is:
It is in mod-fastcgi.r file line 65:
new: rejoin [cfg/root-dir req/in/path file]

cfg/root-dir: %www/testapp/
req/in/path: "/"
file: %index.rsp
new: %www/testapp//index.rsp

But it is not the only problem because if I replace // with / in 
"new" then it doesn't produce error but gives 404.

rejoin [cfg/root-dir req/in/path file] exists in mod-static.r file 
but it works well. So there should be something wrong in req/in/path 
IF there is databases section in webapp. I don't know how related 
they are.

Thanks for digging this up, I'll have a quick look on it later today.

I'm trying to send an email within an .rsp script. Is this not possible 
because I keep getting errors: 


** User Error : Server error: tcp 503 AUTH command used when not 
advertised 
** Where: none 
** Near:  [smtp-port: open [scheme: 'esmtp]