World: r3wp

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.

Cheyenne is very powerful and very stable. It is also very sensible, 
so you have to take care much of what you do, I have also many instances 
serving millions hits per month, no problem at all 8)

RSP scripts requires carefull coding pratices, that's the (small) 
price to pay for performances. That's why user feedback is important, 
to be able to improve RSP engine resistance to user's (sometimes 
bad) practices.

Good documentation would be also a good help, I'm not a great documentation 
writer, but gathering the hints, tips and info from here to fill 
the wiki is the way to go.

how is the web based configuration page going?

No progress since a year at least, due to other priorities. But I 
still plan to make one before the end of this year.

alright. will attempt to upgrade to the latest cheyenne soon, so 
I can get back to some much needed web work.

Henrik ....it's just a svn checkout.  takes a few mins.

doc "improve RSP engine resistance to user's (sometimes bad) practices." 
... I think that means me!

hmm.. is there an easy way to check which version I'm running, for 
example through RSP?

figured it out, however it would be nice to see which one it is.

How ?

Doc has a web control panel on the back burner ... so maybe that 
information will be there.

I've updated my cheyenne.exe binary to use my prot-http.r so that 
you can do PUT, DELETE, GET with read/custom etc.

Graham, not only you, but that's a good thing. :-) Cheyenne would 
have never become as solid as it is today without your and others 
help.

Henrik: on Windows, you have a help message when the mouse pointer 
is over Cheyenne's tray icon. From RSP script, just use :

>> p: open http://localhost
>> p/locals/headers/server
== "Cheyenne/0.9.20"

ok, thanks

Will, are you familiar with how to use Cheyenne's logging functions 
from within a rsp script?

not sure what you mean, rsp-log which is deprecated in latest version?

found it .. can use ?? to log to the trace.log

This is really really strange.

I have a rsp page called creategoogledoc.rsp ... I click on it once, 
and the I get my document created.

Click on it again and the rsp script is not executed ( looking from 
the trace ) but I still get taken to the googledoc page where I previousl 
y created the document.

It's as though the browser is caching my request and executing it 
locally without hitting the server

Arrrggg.... it's all caused by Chrome.  Switching to FF and the problem 
goes away!

And here I was looking for  some type of caching occuring in Cheyenne 
or my RSP pages

I wonder if there is anything on the cheyenne side that can stop 
this behaviour?

rsp pages should not be cached by default by any browser. Do you 
have firebug in FF can you look at the header fo the response an 
see if there is any difference between the two requests? wireshark 
or tcpflow can be used to look at headers as well

I was having similar cashing problems with Chrome...I could not getr 
it to display a changed/updated rsp page. I had to close out.

interesting

If this only occurs with Chrome and RSP ... maybe there is something 
that can be done.

Google Chrome has some badly broken logic when it comes to obeying 
cache-control headers.

Got a link to this ?

Here's someone else banging their head against chrome's caching logic:

http://stackoverflow.com/questions/559984/getting-confused-about-expires-headers-when-testing-in-chrome

That appears to be saying that Chrome is not caching ....

here the problem appears to be that Chrome is heavily caching.

Lots of other people seeing overheavy  Chrome caching, eg:

http://www.google.com/support/forum/p/Chrome/thread?tid=77a9194da602bc00&hl=en

I've created a youtube video showing what is happening http://www.youtube.com/watch?v=ANgSrOuDncE

I'm using BB FlashBack Express 2 because it can upload directly to 
youtube ..and it seems to be free :)

Good idea there .. I'll try an incognito window to see if that helps.

Sadly no .. it does actually create the document the first time, 
but then brings up the same document again the second time.   So, 
basically the same behavior as cognito

I think I may be able to get around this issue by tagging the request 
with a dummy time parameter.

That way chrome will not think it's the same idempotent request

My server traces show that Chrome is not actually visiting the pages 
...

Try by setting a different ETag header for each document: response/set-header 
'Etag checksum document

You can use a timestamp or doc ID for the ETag value, it just has 
to be unique for each resource.

in the url??

Nope, in the RSP script.

http://en.wikipedia.org/wiki/HTTP_ETag

Graham, can you paste here the response headers of the first request 
please

well changing the url by putting a timestamp fixes the problem partially.