r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

amacleod
23-Dec-2011
[11079]
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?
Dockimbel
23-Dec-2011
[11080]
See "Parameters" section from Cheyenne's wiki: http://cheyenne-server.org/wiki/Rsp/Basis
Kaj
23-Dec-2011
[11081x3]
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
Henrik
25-Dec-2011
[11084]
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?
Dockimbel
25-Dec-2011
[11085]
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.
Henrik
25-Dec-2011
[11086]
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
Dockimbel
25-Dec-2011
[11087x2]
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.
Henrik
25-Dec-2011
[11089]
Does it warrant some type of garbage filter? Obviously something 
like this should be ignored.
Dockimbel
25-Dec-2011
[11090x2]
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.
Henrik
25-Dec-2011
[11092x2]
I find it also interesting that the first line is truncated at the 
beginning.
(that is not a paste error)
Dockimbel
25-Dec-2011
[11094x3]
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.
Henrik
25-Dec-2011
[11097x2]
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.
Dockimbel
25-Dec-2011
[11099]
Why not, I will study that option tomorrow.
Dockimbel
27-Dec-2011
[11100x2]
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.
Henrik
27-Dec-2011
[11102x4]
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.
Dockimbel
27-Dec-2011
[11106]
Are you using a PHP engine through FastCGI?
Henrik
27-Dec-2011
[11107]
no, pure REBOL. I found now that using READ inside app-init.r causes 
this hang for a worker process as well.
Dockimbel
27-Dec-2011
[11108]
READ should behave the same wherever you use it, in app-init.r events 
or RSP scripts.
Henrik
27-Dec-2011
[11109x3]
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...
Dockimbel
27-Dec-2011
[11112]
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.
Henrik
27-Dec-2011
[11113]
I rewrote app-init.r for this version.
Dockimbel
27-Dec-2011
[11114]
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.
Henrik
27-Dec-2011
[11115]
aha
Dockimbel
27-Dec-2011
[11116x3]
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)
Henrik
27-Dec-2011
[11119]
delete the .rsp-sessions file if present before starting Cheyenne
 - Why does Cheyenne not do this on start?
Janko
27-Dec-2011
[11120]
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
Dockimbel
27-Dec-2011
[11121x3]
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.
Henrik
27-Dec-2011
[11124]
but isn't that precisely what causes the problem?
Dockimbel
27-Dec-2011
[11125x2]
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).
Henrik
7-Jan-2012
[11127]
Maybe this is interesting: Causing a DoS by reading server responses 
very slowly:


https://community.qualys.com/blogs/securitylabs/2012/01/05/slow-read
Dockimbel
7-Jan-2012
[11128]
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.