gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] multitaskhttpd experiment


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] multitaskhttpd experiment
Date: Thu, 15 Jul 2010 07:46:30 +0200
User-agent: KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.5; i686; ; )

Am Mittwoch 14 Juli 2010, 22:28:55 schrieb lkcl:

Hi,

> rrright, i even solved the problem of lynx not working: i made the back-end
> server support HTTP Keep-Alives which i should have done in the first
> place.
> 
> apply these:
> http://lkcl.net/gnumed/0005-add-keep-alive-version-of-list-server-directory
> -file.patch
> http://lkcl.net/gnumed/0006-add-keepalive-version-of-send-error.-demo-show
> ing-th.patch
> 

The second patch is missing on your server. I cannot download it.

> then git pull on multitaskhttpd repo
> 
> then do:
> $ cd multitaskhttpd
> $ python proxyapp.py &

I must be doing something wrong here since git pull claims it is up to date 
and still does not have proxyapp.py

Can you send me the git clone line again so I am using the correct one ?

> 
> this will redirect traffic from http://127.0.0.1:8080 to
> http://127.0.0.1:60001
> 
> then do:
> cd gnumed/client
> ./gm-from-vcs.sh --ui=mtweb &

I will try this when I have all the file. So you want me to try mtweb again, 
not the pxweb you introduced a while back ?

> 
> this will start up the SimpleJSONRPCServer.py on port 60001
> 
> then do python testjsonrpc.py
> 
> and you should be rewarded with two successful queries and a prompt
> *inside* SimpleJSONRPCServer asking for a username and password.  this is
> *correct* because there should be an exception thrown instead.
> 
Good to know.

> if you also browse to http://127.0.0.1:8080 you should see a listing of the
> current directory, and at the bottom a "Cookie: hexdigest" shown. check
> also the "send_head. pid: NNNN" number and make a note of it.  if you then
> *close* the web browser down entirely and re-visit the page, you should
> note that the same hexdigest is shown. also, double-check that the debug
> info from SimpleJSONRPCServer "send_head. pid: NNNN" is the *exact* same
> number.
>
So the cookie stays there and is read in again when the browser gets opened 
agian ?
 
> then, open a 2nd web browser, you should now get a 2nd hexdigest and a 2nd
> pid: NNNN number.  refresh the first browser, the two should be separate,
> all happy, regardless of how many times you exit the web browser(s).
> 
That you have to explain to me. Two seperate browsers have two seperate 
hexdigest values (which is intended) but closing and reopening does not create 
one despite that I would *assume* that closing and reopening would be equal to 
a thrird or fourth browser ?

Please correct me if I am wrong. Is it correct that the current code handles 
the situation that a connection will not get lost even if the user is inactive 
(but lets the browser window stay open )? Is it also true that the current 
code will handle the situation that when a user closes down the browser he 
will be asked for credentials when opening a new browser instance ?

Best regards,

Sebastian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]