World: r3wp

That could explain the "none-access.log" file, if the request doesn't 
have a Host field defined.

Does it warrant some type of garbage filter? Obviously something 
like this should be ignored.

It also could be a regression in Cheyenne for HTTP/1.0 support, I 
would need to check that. The huge number of log entries suggests 
that Cheyenne is trying to interpret incoming data as pipelined requests, 
instead of just dropping it down.

There are some filters in HTTPd decapsulation routine in Cheyenne 
that should prevent invalid requests to pass, but this one seems 
to have passed through.

I find it also interesting that the first line is truncated at the 
beginning.

(that is not a paste error)

My guess is that some HTTP/1.0 request with data but without Host 
or Content-length field might trigger this bad behaviour from Cheyenne.

Truncation: that could be caused by a bug in the HTTP access log 
batch writing, the log cache seems to have been desynchronized by 
the request.

I have a working session on Cheyenne planned tomorrow, I will have 
a look at the issue more closely.

ok, thanks.

perhaps we need some kind of test server set up, which we can throw 
garbage and flood requests at? it could be useful for testing such 
things.

Why not, I will study that option tomorrow.

Henrik: what revision of Cheyenne are you using?

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.