World: r3wp

Just something to keep in mind when working on websockets: the transer 
mode used by Cheyenne to reply to clients is "text" mode. This mode 
requires UTF-8 encoding and IIRC, the browser is allowed to reject 
your response and close the connection if the response is wrongly 
encoded.

Is it UTF-8 in your chat example? Cheyenne converts text to UTF-8?
Text mode is ok to me.


By the way, I tested ws.html in Cheyenne sources on my XP/Home yesterday 
with Chrome, it closes the connection immediately.
But it works here now, on XP/Pro with Chrome.

Chat demo: no conversion, it's UTF-8 as long as everyone talks in 
english. ;-)

ws.html: same Chrome version on both machines?

yep I just downloaded yesterday.

But actulally the donwloaded program downloads another one, so it 
may be different for Home and Pro.

Chat demo: in fact, it should work ok in all cases, because the UTF-8 
encoding is done by the browser and the chat back-end just broadcast 
it as is to others.

I'll try again tonight.

I got "9/12-13:54:40.187-# Warning in [boot] : Premature exit from 
event loop !" if I close the browser. Is it ok?

I'm running latest Cheyenne from its source.

I think it because of on-timer event. When I remove it from ws.-test.app.r 
no warning appear anymore.

Right, it's a side-effect of on-timer, I should fix it somehow to 
avoid that message.

It looks like I can use on-timer event to do my async polling and 
then sending the results for each client.

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.

Need to go, be back later.

Ok thank you. Bye!

One last thing: in ws.html there is a button to close the connection:

<button onClick=" alert('button closed');conn.close();"> Disconnect 
</button>


But I never get onClose event and don't see a connection close on 
server logs:
conn.onclose = function(evt) { alert("Conn closed"); }

And "tick"s appear even if I click on Disconnect.

And one more thing: I think I found the reason of "Warning in [boot] 
: Premature exit from event loop" message in on-timer event, and 
fixed:

client removed AFTER the on-disconnect event, so CLIENTS are not 
EMPTY? while the last client disconnecting.

I changed the 43. line on ws-test-app.r file from:
  if empty? clients [
to 
if 1 = length? clients [

And problem solved.

I tested ws.html in Cheyenne sources on my XP/Home yesterday with 
Chrome, it closes the connection immediately. But it works here now, 
on XP/Pro with Chrome.

I just tested on XP/Home it works well. I think it was not the latest 
version I've tested yesterday.

When I remove AUTH line from WEBAPP section in httpd.cfg file, the 
browser always returns :ERR_EMPTY_RESPONSE error.
Here is my part of httpd.cfg
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
;		auth "/testapp/login.rsp"
		;debug
	]


in %testapp/  I have test.html and test.rsp they both very simple 
files, I have app-init.r also. But I can never access those files.
In Cheyenne log file I see following error:


10/12-3:11:39.3120-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'second
    arg2: 'series

    arg3: [series! pair! event! money! date! object! port! time! tuple! 
    any-function! struct! event!]
    near: [either url: second pos: find]
    where: 'process-webapp
] !


As a work around I put auth line to a rsp file that just do session/content/login?: 
yes and redirect. 
Do you have any idea? I tested with 0920 and r164.

Yes, it's probably related to my last modifications in Cheyenne on 
AUTH handling. I will see if I can find time to fix that this weekend.

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.