Redirect Back Button
The Magnet
Hi,
I'm looking to change the location of where the page goes when someone
hits the back button.
I have a page which the user fills out a form, hits SUBMIT. It does
it's PHP thing, sends me the info, and then puts up a confirmation
page with a link to another page. At that point, if the user hits the
browsers 'BACK' button, it goes back, and I've put in a session
variable to re-direct the page using "header", but it still sends me
the confirmation again???
How can that be when I check for the session variable first thing:
<?
session_start();
if ($_SESSION['BACK'] == "Y") {
header("Location: feedback.php");
}
First thing in the page. It goes back to 'feedback.php' properly, but
not before sending me another email.
Any ideas why??
Jerry Stuckle
Wrong approach. When the user submits the forum, process the input then
redirect to a new page with a header() call.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Peter H. Coffin
'cause that's how it's supposed to be? Just add a transaction ID
someplace in your form, and when you get a submission, check that ID to
see if it's already done or not. If it IS already done, don't send the
email again, or only send it if the submission data is different from
last time, or whatever makes sense for your application.
(And remember, always, that you can't control the browser. You can hint
but not force, so code like the browser is operated by a genius
orangutan who hates you and your entire family, and wants you all to be
miserable.)
--
Graham's First Rule of Internet Retailing:
If your 'shopping cart' site requires anything more complex than
HTML, SSL and a session cookie, at least one of your competitors
will run a site which does not. Your competitor will get the sale.
Willem Bogaerts
> orangutan who hates you and your entire family, and wants you all to be
> miserable.)
Gee, what an amateur am I. I thought that programming was fun... ;)
Have fun,
--
Willem Bogaerts
Application smith
Kratz B.V.
http://www.kratz.nl/
Satyakaran
> ==================
Here it is :
http://www.satya-weblog.com/2009/10/avoid-resubmitting-html-form.html
Michael Fesser
JFTR: The Location header requires an absolute URI. Using a relative one
like in your examples violates the HTTP specification and might cause
problems in some HTTP agents (at least one known browser shows a
warning).
Micha
Gordon
Just out of curiosity, what browser is that? I test PHP apps under
several browsers and have never seen any emit a warning due to use of
relative URLs in the Location header.
Peter H. Coffin
Dunno about a browser, but Apache used to fuss about it, and some
browsers (IE especially) used to utterly fail at managing it in a
form-submission context, like if your page POSTed results and the target
page redirected elsewhere, the submission would end up in GET results
instead of POST at the new target page... THAT one was fun to figure
out.
And, of course, USING the absolute can make browsers complain as well.
If you've got pages that are servable with https and redirect to http,
that throws up a warning to the user as well...
--
26. No matter how attractive certain members of the rebellion are, there is
probably someone just as attractive who is not desperate to kill me.
Therefore, I will think twice before ordering a prisoner sent to my
bedchamber. --Peter Anspach's list of things to do as an Evil Overlord
Michael Fesser
>On Nov 9, 10:26�pm, Michael Fesser <neti...@gmx.de> wrote:
>> .oO(Satyakaran)
>>
>> >Here it is :
>> >http://www.satya-weblog.com/2009/10/avoid-resubmitting-html-form.html
>>
>> JFTR: The Location header requires an absolute URI. Using a relative one
>> like in your examples violates the HTTP specification and might cause
>> problems in some HTTP agents (at least one known browser shows a
>> warning).
>
>Just out of curiosity, what browser is that? I test PHP apps under
>several browsers and have never seen any emit a warning due to use of
>relative URLs in the Location header.
Lynx.
Surely not a big player (but very helpful for testing, though). I was
just mentioning this issue because there's a lot more than just the
handful of main browsers. Every search engine or download manager for
example is an HTTP UA (user agent) as well. Or think about HTML
validators. All that stuff. There are hundreds of them, and they all
(should) behave like the spec defines. If you violate the spec, don't be
suprised if some UA does something funny. In case of the Location header
the spec clearly requires an absolute URL, so you can't expect a UA
being able to resolve a relative URL there. Most do, but you shouldn't
rely on such implicit "bug fixing".
Micha
Michael Fesser
>Dunno about a browser, but Apache used to fuss about it, and some
>browsers (IE especially) used to utterly fail at managing it in a
>form-submission context, like if your page POSTed results and the target
>page redirected elsewhere, the submission would end up in GET results
>instead of POST at the new target page... THAT one was fun to figure
>out.
But that's more a script problem (maybe in conjunction with a browser
bug). POSTs are not supposed to be redirected, at least not without user
confirmation:
| If the 302 status code is received in response to a request other than
| GET or HEAD, the user agent MUST NOT automatically redirect the
| request unless it can be confirmed by the user, since this might
| change the conditions under which the request was issued.
(RFC 2616, 10.3.3)
Micha
Peter H. Coffin
> Surely not a big player (but very helpful for testing, though). I was
> just mentioning this issue because there's a lot more than just the
> handful of main browsers. Every search engine or download manager for
> example is an HTTP UA (user agent) as well. Or think about HTML
> validators. All that stuff. There are hundreds of them, and they all
> (should) behave like the spec defines. If you violate the spec, don't be
> suprised if some UA does something funny. In case of the Location header
> the spec clearly requires an absolute URL, so you can't expect a UA
> being able to resolve a relative URL there. Most do, but you shouldn't
> rely on such implicit "bug fixing".
Hell, half the traffic I see is web trawls of various kinds. If they
can't get to your content, they can't index it, and if they can't index
it, they can't send people to it...
--
7. When I've captured my adversary and he says, "Look, before you kill me,
will you at least tell me what this is all about?" I'll say, "No." and
shoot him. No, on second thought I'll shoot him then say "No."