World: r3wp

Doc: "You can just pass a block! value as a job to the scheduler 
and call your code from there, it would be cleaner than hacking in 
on-timer."

How do I interact with "clients" connected via ws inside a "job" 
block?

I have "clients" block in on-timer event and I able to send messages 
to them. Is it possible from jobs?

2) in ws-test-app.r file it says do-task/on-done takes an argument 
that can be anything.

But when call do-task/on-done with any non-string argument I get 
an error, am I doing something wrong?

I tried with a port (connected ws client) and a integer, both failed:


11/12-6:17:04.1090-## Error in [mod-socket] : On-timer call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'do-task
    arg2: 'data
    arg3: [string!]
    near: [do-task/on-done 5 func [client data] [
            send client join "Job end: " reform [now/time tab i]
        ]]
    where: :action
] !

Interact with ws clients from job: it's possible only if you pass 
the clients list in the block.

Re 2): I should reformulate it, you can pass serialized values only.

I will be busy or offline in the next days until 14/12, I won't have 
time to make the changes/fixes to ws before that.

Handling of websockets disconnection event has been fixed in the 
latest revision.

Also, the ws-test-app test application has been fixed too and now 
works correctly (in Chrome at least, I should add support for FF 
too).

Ok, it's now supporting FF too.

AUTH regression (error when not used in a webapp): fixed in last 
revision.

It's a not big issue, but I noticed, that the include function does 
not removes BOM from the files. Do you think it's worth to improving 
it or let people to maintain it manually in the files which are being 
included?

Browsers like Chrome or Firefox are fine if find a BOM inside html, 
but for example IE6 had a problem - at least in my case. So far I 
just resaved my source, but I can imagine that it will reappear in 
a future again (as UTF8 with BOM is default).

Sounds like a good idea (making INCLUDE remove UTF-8 BOM, if found).

I'm trying to generate an .rsp page based on a query string the way 
a cgi page does using 'decode-cgi system/options/cgi/query-string'

but it does not seem to be working. How is this sort of thing done 
with .rsp?

See "Parameters" section from Cheyenne's wiki: http://cheyenne-server.org/wiki/Rsp/Basis

Here's a function I use to remove BOMs I got from Windows files:

read-lines: func ["Read text lines from a file."
	file [file! url!]
	/local line
][
	if all [not empty? file: read/lines file
		find/match line: first file  "^(EF)^(BB)^(BF)"
	][
		remove/part line 3  ; Remove BOM
	]
	file
]

I don't know if this handles the full spec, though

Two things:

1. what is the mechanism that determines the name of a log file?
2. would it be a bug, if I saw a log file named none-access.log?

1. Depends on which log file you're thinking of, I guess it's for 
HTTP access logs. It's composed by virtual host name followed by 
"-access.log".


2. It could be an internal bug or a misconfiguration issue, anyway, 
Cheyenne should not produce such files.

OK. I saw it as a REBOL process was suddenly racing at 100% CPU. 
Someone accessed my site, which posted an entry in the default-access.log 
with an HTTP 1.0 request:


74.52.168.98 - - [25/Dec/2011:10:30:29 +0100] "GET / HTTP/1.0" 200 
9


Then 5 minutes later, the none-access.log appears and I'm flooded 
with requests until that log is 45 MB in size.

The file starts like this:

.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
.... 45 MB of this

Hmm, intriguing...Seems that you received a request with garbage, 
either an attack or flooding attempt. The HTTP/1.0 suggests that 
the request is not coming from a web browser (all are using HTTP/1.1 
now).

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).