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

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.
amacleod
11-Jan-2012
[11129]
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?
Dockimbel
11-Jan-2012
[11130]
As long as clients use the standard websockets protocol, they will 
work with Cheyenne.
PeterWood
13-Jan-2012
[11131]
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.
sqlab
13-Jan-2012
[11132x2]
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.
PeterWood
13-Jan-2012
[11134]
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.
sqlab
13-Jan-2012
[11135]
win-call/output  "plink.exe  -l user -pw password [checkall-:-host]  
df "  str: make string! 1024
tia
Dockimbel
13-Jan-2012
[11136]
You can use SDK v2.7.6, it has no issues with Call on Windows, AFAIR.
PeterWood
14-Jan-2012
[11137]
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.
sqlab
15-Jan-2012
[11138x2]
plink is a ssh command line tool  of the putty package
maybe win-call uses a different home directory for the key file
Endo
25-Jan-2012
[11140x2]
I have a problem with cheyenne-r0920-cmd.exe on Windows, when I comment 
database section in my http.cfg it works, when I uncomment it gives 
the following error in chey-pid-9036.log file:


25/1-17:58:14.625-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: "/E/cheyenne/www/centrex//index.rsp"
    arg2: none
    arg3: none
    near: [info? new [
            req/in/target: form file 
            if ext: find/last req/in/target dot [
                req/in/ext: to word! ext 
                req/handler: select service/handlers req/in/ext
            ] 
            if not req/in/file [req/in/file: new] 
            if d?: declined? req [return false]
        ]]
    where: 'throw-on-error
] !


note that there is double slash before index.rsp I don't know why. 
Error happens before I use any do-sql or something. Web page doesn't 
work at all.
Oh when I moved database section from WebApp to globals section then 
it works!
Dockimbel
25-Jan-2012
[11142]
Can you reproduce the same issue with latest revision from sources?
Endo
25-Jan-2012
[11143]
I will test tomorrow morning.
Endo
26-Jan-2012
[11144x2]
Doc: Same error with latest r173 version.

I just put the databases block into webap block, didn't change anything 
in the testapp,

	webapp [
		databases [
			cdr	odbc://sa:[qwe123-:-cdr]
		]
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp"
		;debug
	]
error is:
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: {/E/cheyenne-sources/Cheyenne/www/testapp//index.rsp}

Note that the double slash in arg1.
Chrome shows "No data received"

Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection 
without sending any data.
Dockimbel
26-Jan-2012
[11146]
Thank you for the test, I'll will try to reproduce it here.
Endo
26-Jan-2012
[11147x2]
Doc: I found where the bug is:
It is in mod-fastcgi.r file line 65:
new: rejoin [cfg/root-dir req/in/path file]

cfg/root-dir: %www/testapp/
req/in/path: "/"
file: %index.rsp
new: %www/testapp//index.rsp
But it is not the only problem because if I replace // with / in 
"new" then it doesn't produce error but gives 404.

rejoin [cfg/root-dir req/in/path file] exists in mod-static.r file 
but it works well. So there should be something wrong in req/in/path 
IF there is databases section in webapp. I don't know how related 
they are.
Dockimbel
26-Jan-2012
[11149]
Thanks for digging this up, I'll have a quick look on it later today.
amacleod
7-Feb-2012
[11150]
I'm trying to send an email within an .rsp script. Is this not possible 
because I keep getting errors: 


** User Error : Server error: tcp 503 AUTH command used when not 
advertised 
** Where: none 
** Near:  [smtp-port: open [scheme: 'esmtp]
Dockimbel
7-Feb-2012
[11151]
Looks like a ESMTP scheme issue. Is it working from console (using 
same REBOL version)?
amacleod
7-Feb-2012
[11152]
Code works on same machine in rebol console but I'm using exe version 
of cheyenne. Does that make a diff?
GrahamC
7-Feb-2012
[11153]
Alan, you do know Cheyenne has a built in mail server ?
amacleod
7-Feb-2012
[11154x2]
No
How's it configed? I don't see it in the docs
GrahamC
7-Feb-2012
[11156x3]
You can use that to send email instead of using 'send
Check the mail demo that is included in the distribution
ie. www/email.rsp
amacleod
7-Feb-2012
[11159]
will do...thanks again
Dockimbel
7-Feb-2012
[11160]
What exe version of Cheyenne are you using?
amacleod
8-Feb-2012
[11161x2]
I was using an older version (not sure which) so I upgraded to newest 
version and email works! but now I have some .rsp scripts failing 
: #[object! [ code: 311 type: script id: invalid-path arg1: MTA arg2: 
#[none] arg3: #[none] near: [port-id: any [ all [ value? 'servers-port 
block? servers-port servers-port/MTA ] 9803 ]] where: context ]]
I'm using the same httpd.cfg . Any configs that are diff that may 
need to be changed?
GrahamC
8-Feb-2012
[11163]
only path in that error is servers-port/MTA .. have you probed this?
amacleod
8-Feb-2012
[11164x2]
Got it mostly working. Most scripts seem to be ok but one script 
keeps giving following error:
#[object! [ code: 303 type: script id: expect-arg arg1: copy arg2: 
range arg3: [#[datatype! number!] #[datatype! series!] #[datatype! 
port!] #[datatype! pair!]] near: [cmd: copy/part skip header 2] where: 
on-task-received ]]