World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
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. |
older newer | first last |