|Pliant talk forum
Discussion: Dealing with multiple browser windows
How to allow two browser windows to work ?
|Message posted by maybe Boris Reitman on 2007/11/24 11:26:13
|I have two browser tabs/windows opened to the same ui_path.
If I press in one window on a button, the other window stops working.
pressing on "Buy" button opens a form. If you open the same url in two windows,
the moment your press "buy" in one window, the other becomes broken,
the "Buy" button in the other stops working.
Can you suggest a solution ?
|Message posted by maybe Hubert Tonneau on 2007/11/25 00:33:05
|If the two tabs of your browser decide to share the same set of cookies,
then the Pliant HTTP proxy has no way to identify one from the other one,
so no way to not confuse. Right ?
|Message posted by maybe Boris Reitman on 2007/11/25 09:36:30
|What do you think about following algorithm.
- upon first request to the server, http_proxy issues a cookie,
and stores the new context in a dictionary keyed by the cookie id.
(the way it works now)
the unique random number will be also sent on the url.
- when http_proxy receives this, it the key wich consists of only
the cookie is upgraded to a longer key, which consits of cookie+" "+window_id.
- on any sebsequent request from this window, the context will be found
by the longer key cookie+" "+window_id.
At any point, in the dictionary there is 0 or 1 key which doesn't contain
the window id in it. If user open many windows very fast (fastser than alive requests),
there will be more than one such key, so any one will be picked in step (*).
This system basically makes each tab to be totally independent session from
each other. However, the perfect scenario whould be to have "url_set cross"
to keep the state global to all windows. Maybe, url closs should duplicate
all state on context keyed by the same cookie part. htpp_proxy must do that.
|Message posted by maybe Bors Reitman on 2007/11/26 09:21:58
|An alternative to cookie is to encode an id in the page and urls that are accessed by
The drawback is that a refresh of the page by hitting F5/Ctrl-R will loose the data.
However, the user will never think of refreshing the page if connection is not lost.
If connection is lost, a div is overlayed on top of the page
which says "press "Reconnect" button below", which will reload with a POST request
providing again the same unique id.
For url_set cross: there should probably be two levels of cross.
One per window, and one per multiple windows. In any case, a cookie will identify
the user, and information will be duplicated in each appropriate context
corresponding to the open windows. So there will be a dictionary mapping cookie
to the list of contexts.
So to summarize: we still need a cookie. The server receives a cookie + window id,
and locates correct context. If id is not provided, server generates a random id
|Message posted by maybe Boris Reitman on 2007/11/26 09:53:41
|To solve problem with F5/Ctrl-R refresh, we can issue a redirect 302 header
and add a unique id as a cgi parameter to the url.
when the site is accessed by a web-robot, redirect shouldn't be done.
A list of web-robots can be kept by syncing with with a an online list of robots.
|Message posted by maybe Boris Reitman on 2008/03/01 16:22:07
|FYI, multiple browser windows are now supported by latest http_proxy.pli
as can be seen at session demo,
http://demo.hypervolume.com/pliant.html ("session" link)