World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
| older newer | first last |
| Graham 9-Aug-2009 [5381x2] | well, for the moment I have fixed the issue by hardcoding the value into the rsp pages. |
If I used the session object i still have to fetch the value from somewhere | |
| Dockimbel 9-Aug-2009 [5383] | Looking in my RSP engine code, I see that it will run on-application-start handler at least once per process to ensure that words defined there would be defined in the other processes (forgot about that). Anyway, modifications will stay local to the process, so there are unsafe. |
| Will 9-Aug-2009 [5384] | I use a uniserve tcp caching service when I need synchronized data across task-handlers |
| Will 10-Aug-2009 [5385x3] | Janko: comment out this line in RSP.r |
if find request/config 'debug [debug-banner/active?: yes] | |
you'll have errors reported and no debug bar | |
| Dockimbel 10-Aug-2009 [5388] | Good option :-) |
| Graham 12-Aug-2009 [5389] | What would cause a browser to complain about a RSP page ... asking what to do with it? As long as Cheyenne is sending the correct content header .. there should be no issues, right? |
| Janko 12-Aug-2009 [5390] | If error happens on compressed page browser (FF) complains about wrong compression .. at least in my version |
| Graham 12-Aug-2009 [5391] | Oh yeah ... seen that. Just wondering what causes a browser not to recognise a RSP page ... perhaps an error in the contents? |
| Dockimbel 12-Aug-2009 [5392] | Do you have a page online that produces such error so I can test? |
| Graham 12-Aug-2009 [5393x2] | No, it's a user of mine that is reporting these issues. I don't see them :( |
I'm going to use teamviewer next week to see what's going on. | |
| Dockimbel 12-Aug-2009 [5395] | There's a high chance that's related to compression. |
| Graham 12-Aug-2009 [5396x2] | How to turn off compression? |
to see if it fixes the issue? | |
| Janko 12-Aug-2009 [5398] | response/no-compress |
| Graham 12-Aug-2009 [5399] | ok |
| Graham 14-Aug-2009 [5400] | If anyone needs it, this is the latest windows binary for cheyenne http://accessories.s3.amazonaws.com/cheyenne.exeusing command view |
| Janko 15-Aug-2009 [5401] | just to say that another cheyenne webapp got public beta release yesterday .. it's in my lang. url is http://www.cebelca.biz(thanks to Doc for makign cheyenne so good!) |
| Dockimbel 15-Aug-2009 [5402] | Nice bee. :-) |
| Janko 15-Aug-2009 [5403] | it's from iStockPhoto |
| Graham 17-Aug-2009 [5404x3] | I was debugging some rsp code last night, and determined that the cause of my problems was that I was using some unitialized variables ... but this wasn''t obvious because these variables had taken values from some one else's rsp session and web app. To prevent this, apart from making sure I initialize my variables correctly, should I wrap my code inside an anonymous context ? |
I don't know if it makes any difference but it was inside a Rebol script that I had executed using *do | |
Just wondering how easy it would be if when a user requests a resource, but their session has timed out, to redirect them to the login page, and then forward them onto the resource they were after? | |
| Dockimbel 17-Aug-2009 [5407x3] | *do means "bind to the global context", but even the wrapper DO wouldn't help you there. As a rule of thumb, *always* initialize your global variables in your RSP script (or at least put them in some local context). Never expect that a variable would be available in another RSP script unless you put it in session object. |
I sometimes use the following safe construct to avoid reloading some longer code on each RSP script call : <% if not value? 'my-object [ my-object: context [ ;--loaded on each new worker process only once, then available in global context ... ] ] %> | |
Session timeout: you have to save the resource URL somewhere, then retrieve it after login and redirect the client there (using a client redirect or server-side forward). I don't remember right now the implementation detail. BrianH told me once a method that looked good to me, but I can't find it right now. | |
| Graham 17-Aug-2009 [5410x2] | The resource url would have to be saved by the cheyenne api .. a web app can't save it. |
Good point about not reloading if it's already available to the worker process. | |
| Will 17-Aug-2009 [5412x3] | actually the resource url is already saved when a session timeout, this is the code in mod-rsp.r: req/out/code: 302 sessions/set-cookie sess req h-store req/out/headers 'Location url h-store req/out/headers 'Last-Modified none repend sess/vars ['from req/in/url] throw true ; redirects to login page |
so the url should be available in session/content/from | |
I use it this way, after checking for valid user/pass : any[all[session/exists? 'from t: session/content/from session/remove 'from t <> "/admin/" t] rejoin [%/admin/ user/prefs/home %.t] | |
| Graham 17-Aug-2009 [5415] | ok. thanks. |
| Dockimbel 18-Aug-2009 [5416] | Will, thanks, I forgot about 'from being included in mod-rsp. |
| Graham 18-Aug-2009 [5417] | Sometimes I think that Chyenne is disrupting the fabric of reality. I can comment out lines of code, and they still execute ... for a while and then they stop. As though somewhere code is being cached somehow. |
| Robert 18-Aug-2009 [5418] | Can you all please "document" those finding in the Cheyenne Wiki? This should build a collection of tipps & tricks over time. |
| Dockimbel 18-Aug-2009 [5419] | Graham: the sample code above is a way of caching code in memory. It won't change unless you restart the process. |
| Graham 18-Aug-2009 [5420] | I'm not doing that for this particular problematic code .. it's just being executed off the drive |
| Dockimbel 18-Aug-2009 [5421x2] | Btw, running Cheyenne with the -w 0 option is a good way to avoid code caching effects. |
(for debugging only) | |
| Robert 18-Aug-2009 [5423x5] | I have a strange error message I don't have a clue where it is coming from. |
10/7-15:13:14.250992-[RSP] ##RSP Script Error:
URL = yogalinks.rsp?rest=addtocart
File = /var/www/cheyenne/yogalinks.rsp
** Script Error : Invalid argument: o
** Where: to-integer
** Near: [to integer!
:value]
Request = make object! [
headers:
[Host "www.yogalinks.eu" User-Agent {Mozilla/5.0 (Macintosh; U; Intel
Mac OS X 10_5_7; de-de) AppleWebKit/525.28.3 (KHTML, like Gecko)
Ve
status-line: #{
504F535420796F67616C696E6B732E7273703F726573743D616464746F636172
7420485454502F312E300D0A
}
method: 'POST
url: "yogalinks.rsp?rest=addtocart"
content: #{
70726F647563745F69643D596F67616D617425323045636F25323050726F2671
75616E746974793D6F26636F6C6F723D626F72646561757825324667726175
}
path: "/"
target: "yogalinks.rsp"
arg: "rest=addtocart"
ext: '.rsp
version: none
file: %/var/www/cheyenne/yogalinks.rsp
script-name: none
]
| |
From trace.log | |
It seems cheyenne got somehow stucked after a longer running period. Restarting did solve the problem. | |
Could be something where sessions/ session variables are not reset in all cases. | |
| Graham 18-Aug-2009 [5428] | why is cheyenne inside your www directory? |
| Dockimbel 18-Aug-2009 [5429x2] | About your error, it's caused by an invalid argument passed in POST data : quantity=o (o instead of 0). Are you validating parameters sent by client using RSP 'validate function or your own one? |
Somehow stucked : I need more details to give you a diagnosis (Does the server respond to static requests? Does it generates any useful info in logs files,...). I have several Cheyenne instances with heavy RSP webapps running for months without any need for restarting. | |
| older newer | first last |