Date: 03/05/00
- Next message: Thomas Biebl: "Re: [PHPLIB] Problem with the challenge-crypt-md5 example..."
- Previous message: 83930337 <email protected>: "[PHPLIB] HIDDEN SECRETS"
- In reply to: Fabrizio Ermini: "Re: [PHPLIB] IE5 caching problem - workaround"
- Next in thread: Jeroen Laarhoven: "Re: [PHPLIB] IE5 caching problem - workaround"
- Reply: Jeroen Laarhoven: "Re: [PHPLIB] IE5 caching problem - workaround"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
On Fri, Mar 03, 2000 at 11:32:41AM +0100, Fabrizio Ermini wrote:
> > I only need to add code such as this to pages that use the POST method,
> > > right? Nowhere else?
> >
> > Only pages that RECEIVE posted vars (<FORM> targets).
> >
> > And because Narinda Reeders pointed out that NS is also giving problems you
> > might want to remove the IE5 check and do it always.
>
> Anyone could speculate on how much performance you'd lose by doing that
> on ALL pages for EVERY browser?
> If this could remove all this damned caching problems it could be worth
> the pain...
We're using a similar approach for solving all the
'backbutton'-uglinesses. Alas our current implementation is tightly bound
to a application framework using the 'magic active directory' approach
and furthermore stomping another layer of abstraction on top of phplib's
session variables. Hence it is not that easily to be integrated in
a 'vanilla' phplib site.
In our centralized 'action-dispatcher' we do something like this:
(pseudo-code)
page_open();
if ( REQUEST_METHOD == POST ){
** Do a rough sanity check on the contents of HTTP_POST_VARS
** Import the contents of HTTP_POST_VARS into a dedicated
session variable
** page_close();
** relocate to the 'real' consumer of the posted form data
} else {
** do the usual stuff
** page_close();
}
We found out, that it might be impossible to relocate to the
same URI (taken from REQUEST_URI)?
We solved the difficulties by standardizing the URIs used as
'actions' for forms to:
/dispatch/${site_post_prefix}/path/to/real/consumer
So the 'code' above (located in the 'dispatch'-script) recognizes
the 'post', does the sanity check would relocate to
/dispatch/path/to/real/consumer
The overhead for the relocation would only occur for necessary cases.
At least it seems to solves (together with caching=no) all
'back-and-forward-button'-problems for our application.
Have a look (sorry, this is a German only site) at
http://www.schlemmen-im-muensterland.de/
-Andreas
-- : Anti-Spam Petition: http://www.politik-digital.de/spam/ : : PGP-Key: http://www.tse-online.de/~ab/public-key : : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : - PHP3 Base Library Mailing List. Send messages to <phplib <email protected>>. To unsubscribe, send "unsubscribe" to <phplib-request <email protected>> in the body, not the subject, of your message.
- Next message: Thomas Biebl: "Re: [PHPLIB] Problem with the challenge-crypt-md5 example..."
- Previous message: 83930337 <email protected>: "[PHPLIB] HIDDEN SECRETS"
- In reply to: Fabrizio Ermini: "Re: [PHPLIB] IE5 caching problem - workaround"
- Next in thread: Jeroen Laarhoven: "Re: [PHPLIB] IE5 caching problem - workaround"
- Reply: Jeroen Laarhoven: "Re: [PHPLIB] IE5 caching problem - workaround"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

