World: r3wp

timestamp also for the rsp url

http://www.compkarori.co.nz:8000
userid/pass Guest/Guest

You won't be able to create a googledoc though as it requires that 
your google credentials are stored!

My reported problem: Doc, I'm not using VALIDATE nor do I check the 
parameters. Do I have to? I thought Cheyenne does this implicit.

I expect the problem with the parameter to force the seen side-effects. 
So before going into deeper analysis I want to fix the parameter 
problem. Any guide how to handle parameters correctly?

Robert, how can Cheyenne know that "quantity" must be an integer! 
value if you don't tell it? Cheyenne can't validate that implicitly, 
you have to either use VALIDATE (see API doc) or make your own checking 
routines. By default, all your GET or POST  parameters are treated 
as string! value. If you need to check for their presence or need 
to convert them to another datatype, you have to validate the format 
so that it doesn't error out (or worth, let an hostile request pass).

I've created a dummy google account so that people can try this out

pm me if you want to try ...

ok here is the answer from Cheyenne:
HTTP/1.1 301 Moved Permanently
Server: Cheyenne/0.9.20
Date: Thu, 20 Aug 2009 09:43:23 GMT
Connection: close

Location: http://docs.google.com/Doc?docid=0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu&hl=en
Set-Cookie: RSPSID=OTWARJZIFLZYABVJOACFFTZY; path=/md; HttpOnly

answer from the redirection:
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Wed, 19 Aug 2009 21:43:58 GMT

Set-Cookie: WRITELY_UID=001dfpwvx2b|928b9de9e7bf56448b665282fc69988b; 
Path=/; HttpOnly

Set-Cookie: GDS_PREF=hl=en;Expires=Sat, 17-Aug-2019 21:43:58 GMT;HttpOnly

Set-Cookie: SID=DQAAAHcAAAB0kldc4zZSC_0FoiL6efkWE11k9SQkAIn-N3WfAzIOVe1cM-remnLUtV3Z4M-BFRf5eknz7hr_U3YzW94nECo0-aDnpxrLGiBglWGN4VkfLr5Hh7t2XNyRCA3VWd005SfCmZ9D8-1MUltjRI8X56VLde5Wy8HD92gh-8YkJBJxQA;Domain=.google.com;Path=/;Expires=Sat, 
17-Aug-2019 21:43:58 GMT

Location: https://www.google.com/accounts/ServiceLogin?service=writely&passive=true&nui=1&continue=http%3A%2F%2Fdocs.google.com%2FDoc%3Fdocid%3D0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu%26amp%3Bhl%3Den&followup=http%3A%2F%2Fdocs.google.com%2FDoc%3Fdocid%3D0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu%26amp%3Bhl%3Den&ltmpl=homepage&rm=false
Content-Encoding: gzip
X-Content-Type-Options: nosniff
Content-Length: 325
Server: GFE/2.0

more redirection:
HTTP/1.1 302 Moved Temporarily

Set-Cookie: WRITELY_SID=DQAAAHoAAADh80lBIw7e5Hg06TLEBgCY33XQGJ1aUH5OrCF_ir1xLwffKNaCqNdUL6qYfvgjNppDBI4lTNBSTjJWMG_Ze0_qJnveBCAtihBDFwBlOb-H7RlkfgJwM7pBbyKV7bm4M3mqUivD1emtpxgl32vG8CEP1poQ2479HQXrlobsp7Egzw;Domain=docs.google.com;Path=/;Expires=Thu, 
03-Sep-2009 21:43:59 GMT

Location: http://docs.google.com/Doc?docid=0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu&amp%3Bhl=en&pli=1
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Date: Wed, 19 Aug 2009 21:43:59 GMT
Expires: Wed, 19 Aug 2009 21:43:59 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
Content-Length: 232
Server: GFE/2.0

and the the target page:
HTTP/1.1 200 OK

Set-Cookie: WRITELY_SID=DQAAAHoAAADh80lBIw7e5Hg06TLEBgCY33XQGJ1aUH5OrCF_ir1xLwffKNaCqNdUL6qYfvgjNppDBI4lTNBSTjJWMG_Ze0_qJnveBCAtihBDFwBlOb-H7RlkfgJwM7pBbyKV7bm4M3mqUivD1emtpxgl32vG8CEP1poQ2479HQXrlobsp7Egzw;Domain=docs.google.com;Path=/;Expires=Thu, 
03-Sep-2009 21:43:59 GMT

Set-Cookie: GDS_PREF=hl=en;Expires=Sat, 17-Aug-2019 21:43:59 GMT;HttpOnly

Set-Cookie: user=; Expires=Tue, 18-Aug-2009 21:43:59 GMT; Path=/; 
HttpOnly

Set-Cookie: login=; Expires=Tue, 18-Aug-2009 21:43:59 GMT; Path=/; 
HttpOnly
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Wed, 19 Aug 2009 21:43:59 GMT
Content-Encoding: gzip
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Server: GFE/2.0

Conclusion, as you can see above google response for redirection 
include no caching, expires, etc,, headers, Cheyenne don't. I suppose 
that is why you don't see the second hit on your Cheyenne instance, 
Chrome is caching the Cheyenne redirection.

in the rsp that send the the 301 redirect, add this lines:

response/set-header 'Cache-Control "private, max-age=0"
response/set-header 'Expires "-1"

if that is not enough, try with this:


response/set-header 'Cache-Control "no-cache, no-store, max-age=0, 
must-revalidate"
response/set-header 'Pragma "no-cache"
response/set-header 'Expires "-1"

now try that and tell us if you see hitting your server at every 
requests

Nenad, should a redirect send no caching headers by default?

Maybe yes for a 301 and no for a 302? Personally I like it as it 
is, I can always add them when needed.

That first redirection is an authentication request from google so 
it looks like you might not have been logged in to gmail at the time. 
 I used your second suggestion and that seems to work fixing the 
caching issue.  Good work!

No wonder I wasn't seeing the response from my script ...

Anyone see why this doesn't work 

grab-cookie: func [  login-url [url!] username password
    /target web-app-url [url!]
    /local page auth cookie err
][
    if error? set/any 'err try [
        page: open login-url
        cookie: page/locals/headers/set-cookie
        close page
        auth: rejoin [ "login=" username "&pass=" password ]

        page: read/custom login-url compose/deep [ POST (auth) [ cookie: 
        (cookie)]]
        either target [

            page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]]
            return page
        ][ return cookie  ]
    ][
        mold disarm err
    ]
]   


I can see it sending the cookie after authentication to get a page 
in a web-app, but I get redirected to the login age

I was logged in, otherwise I would have been redirected to the login 
page.. Good that it fixed your issue, did you try solution one, if 
not, could you please? thx

That is just how the google's auth framework works..

Response/redirect returns a code 301 by default (means "Moved Permanently"), 
that may be the cause of the unexpected caching by the browser. Could 
you try using response/redirect/temp instead?

Grab-cookie: does your 'username or 'password values contain any 
special character that would need to be URL-encoded?

no .. I guess I'll have to do a wireshark trace to see why it doesn't 
work.

and ... it's because I'm not doing the captcha challenge :(

response/redirect/temp seems to work .. after I removed the response 
setting changes.

Thanks, that confirms what I was thinking, response/redirect should 
return a 302 by default instead of 301 to avoid browser caching issues.

This is the proposed change to RESPONSE/REDIRECT : 


response/redirect => 303			; HTTP1.1 moved temporary (POST=>303=>GET)

response/redirect/temp => 302		; HTTP1.0 compatible moved temporary

response/redirect/thru => 307		; HTTP1.1 moved temporary with same 
method (POST=>307=>POST)
reponse/redirect/last => 301			; HTTP1.0&1.1 moved permanently


If there's no objections or better propositions for the refinements, 
I'll commit these changes tonight.

SVN update to revision 8 :

	o RSP: response/redirect improve (see above)
		  
	o RSP/CGI: default no caching headers changed to:
	
		Pragma: no-cache

     Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Thank you 8)

a noter (ds les headers poste ds group Cheyenne) le premier redirect 
envoie:
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
le deuxieme:
Expires: Wed, 19 Aug 2009 21:43:59 GMT
Cache-Control: private, max-age=0
a noter aussi, le premier envoie aussi:
Content-Type: text/html; charset=UTF-8
mais pas de Content-Length
le deuxieme envoie:
Content-Encoding: gzip
Content-Length: 232
et pas de Content-Type

.. un vrai mess.. normalment j'ai confiance en google, ils sont tres 
peeki mais la je comprends pas

wrong channel..

Is there anything info on net on how to use cheyenne with 3rd party 
ssl app to get https? I googled but didn't find anything.. I found 
Doc mentioning STunnel so I am looking into that

I bought SSL certificate at comodo now, created the csr and waiting 
for it.. It seems pretty simple to setup so far (with stunnel examples)

would be using something like nginx infront of cheyenne to get ssl 
better ? (and also to server the static files directly)

I've tested only with stunnel, but nginx is also a very good option 
if you want to speed-up static files serving.

This is the STunnel example doc for https .. the webmaster at the 
top doesn't recommend it that much ... http://www.stunnel.org/examples/https_windows.html


This shows nginx with separate  ssl usage and also using it as reverse 
proxy (with load balancing also)  http://www.linuxjournal.com/article/10108

SSL

server {
  listen   127.0.0.1:443;
  server_name  secure;
  access_log  /var/log/nginx/secure.access.log;
  error_log  /var/log/nginx/secure.error.log;
  ssl on;
  ssl_certificate /etc/nginx/ssl/server.crt;  
  ssl_certificate_key /etc/nginx/ssl/server.key;  
  location / {
    root   /var/www/secure;
    index  index.html index.htm;
  }
}

LOAD BALACER 
upstream python_servers {
  server 127.0.0.1:8001;
  server 127.0.0.1:8002;
}
server {
  listen   127.0.0.1:8000;
  server_name  proxy;
  access_log  /var/log/nginx/proxy.access.log;
  error_log /var/log/nginx/proxy.error.log;
  location / {
    proxy_pass http://python_servers;
  }
}

--

Both seem logical and if combining ssl + proxy (server part) them 
would work I would get what I need

So far the faster static serving is not so cruicial to me.. I want 
the more reliable and less complicated option .. neither seem very 
complicated from lookign at it

Doc: did you use the stunnel config like it's in that example link 
I gave?

Yes, like the one in section "10. Running the server". You need also 
to block direct access on port 80 for your SSL protected resources. 
There are various way to achieve that like using a local firewall 
to block incoming traffic on port 80 from outside (but not from localhost), 
or in per webapp, using a custom 'on-page-start handler testing the 
server port of the incoming request (and rejecting it if port<>443).

I was thinking of giving users a choice to use or not use http or 
https .. so I would leave both open (if that doesn't mean something 
bad which I don't know)

If the choice is up to the user, then both ports will stay open, 
that should be the easiest way to handle it, AFAICT.

ok, then I will go that way

thanks

How does it work with virtual hosts?  Do you need a certificate for 
each host?

I think you need a certificate per domain (more than one subdomains 
can be handeled by 1 so called wildcard cert.)

I got response from them on my mail with company data.. they couldn't 
validate me yet because I bought the domain on my personal name and 
cert is on company .. I need to change that in whois info (I hope 
it's even possible)

so does stunnel handle multiple certificates?  Anyone know?