World: r3wp

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.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Wed, 19 Aug 2009 07:41:04 GMT
Expires: Wed, 19 Aug 2009 07:41:04 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
Server: GFE/2.0
Via: 1.1 bc3
Content-Length: 0
Connection: Keep-Alive
Set-Cookie: cookies here ... 

Set-Cookie: user=; Expires=Tue, 18-Aug-2009 07:41:04 GMT; Path=/; 
HttpOnly

Set-Cookie: login=; Expires=Tue, 18-Aug-2009 07:41:04 GMT; Path=/; 
HttpOnly

Reading about etags now ...

It's not the document that needs to send back the etag as it never 
even gets that far.

So, perhaps I need to set the etag in the page that lists links?

why do u have Content-Length: 0 ?
this is not valid Set-Cookie: cookies here ...

I scrubbed the cookies from the response

this is returned by googledocs

are u reverse proxying ?

no proxies

made the etag settings ... not helping so going to do a wireshark 
trace to see if I am setting it

what if you add
response/set-header 'Expires "-1"

it's caching the whole page ... so it won't see the etags

headers you pasted are not coming from cheyenne but from google server, 
you can't control them

just to understand, you generate a file and u upload to googledocs, 
then requests it from google server?

frustrating .. can't get a trace

Yes, that's correct.

but chrome is not executing the rsp script ... as far as I can see.

I think I'll just stick with putting a time stamp on each request 
to foil the cache

Or just stick with FF / IE.

then this has nothing to do with cheyenne, add something like
join %? checksum form now/precise ad the end of requested url

if it is the rsp script that doesnt get executed , please paste headers 
from rsp response

?t= url-encode form now/time/precise

which rsp response?

you said "but chrome is not executing the rsp script ... as far as 
I can see."

yes, I put a ?? in the script and it doesn't log.

so that is the rsp you request that generate the file and upload 
it to google

yes

I'd like to see the response headers of that request , not those 
from requesting the uploaded file

thi sis the link http://gchiu.no-ip.biz:8000/md/creategoogledoc.rsp?gdoc=simple-letter.rtf&patientid=2832&encounter=none

but the page does not get executed

I can't go past http://gchiu.no-ip.biz:8000/md/login.rsp  8)

When I click on that link ... it supposed to execute a script when 
then sets the response/redirect

so there is no response from cheyenne .. only from google