Re: [PHP] General use of rewrite / redirect
Nathan Nobbe wrote: im sorry i havent read through all the replies, but i have read through several of them. i essentially agree w/ Aschwin here. I'm still having difficulties understanding Aschwins main point, as well as how you can work (properly) with forms without using a 303 redirect. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Larry Garfield wrote: True, but bear in mind that the browser has to make a HEAD request for every such file in order to determine if it needs to download it again. That's a non-small amount of HTTP traffic if you have a lot of images or CSS files. True - although I rarely see HEAD requests. I see lots of conditional GETs instead. BTW, why does the browser do this for objects it has already cached? (assuming they're fresh/not expired) /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On 19 Mar 2008, at 09:54, Per Jessen wrote: Larry Garfield wrote: True, but bear in mind that the browser has to make a HEAD request for every such file in order to determine if it needs to download it again. That's a non-small amount of HTTP traffic if you have a lot of images or CSS files. True - although I rarely see HEAD requests. I see lots of conditional GETs instead. BTW, why does the browser do this for objects it has already cached? (assuming they're fresh/not expired) Because by default most web servers don't add expiry headers, so it's up to the browser. Adding expiry headers for certain content types is very easy in most web servers and depending on traffic patterns it can cause a very healthy drop in traffic. Combine that with a convention for new versions of the files as they get changed and you can put the expiry date a long time into the future. We use a year on all our images, css and js files and it's lead to a drop of ~40% in traffic to the static servers. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Stut wrote: On 19 Mar 2008, at 09:54, Per Jessen wrote: BTW, why does the browser do this for objects it has already cached? (assuming they're fresh/not expired) Because by default most web servers don't add expiry headers, so it's up to the browser. My server does add expire headers - and I still see lots of 304s. I've checked that the expiry information is correct. Adding expiry headers for certain content types is very easy in most web servers and depending on traffic patterns it can cause a very healthy drop in traffic. Combine that with a convention for new versions of the files as they get changed and you can put the expiry date a long time into the future. We use a year on all our images, css and js files and it's lead to a drop of ~40% in traffic to the static servers. Same here - I am just wondering about the need for the conditional GET then. What makes the browser want to revalidate an object when it has a valid (=unexpired) copy cached? /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On 19 Mar 2008, at 10:11, Per Jessen wrote: Stut wrote: On 19 Mar 2008, at 09:54, Per Jessen wrote: BTW, why does the browser do this for objects it has already cached? (assuming they're fresh/not expired) Because by default most web servers don't add expiry headers, so it's up to the browser. My server does add expire headers - and I still see lots of 304s. I've checked that the expiry information is correct. We see lots of them as well, but it's far less than before we added far-future expiry headers. Adding expiry headers for certain content types is very easy in most web servers and depending on traffic patterns it can cause a very healthy drop in traffic. Combine that with a convention for new versions of the files as they get changed and you can put the expiry date a long time into the future. We use a year on all our images, css and js files and it's lead to a drop of ~40% in traffic to the static servers. Same here - I am just wondering about the need for the conditional GET then. What makes the browser want to revalidate an object when it has a valid (=unexpired) copy cached? There could be a number of reasons ranging from browser configuration to badly implemented caches. There's not a lot you can do about them beyond making sure your expiry headers are working properly with the major browsers. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] General use of rewrite / redirect
Hi,
In too many projects / scripts / examples, I see rewrites or redirects
being done like (pseudocode):
if (good) {
do something
} else {
header (location: http://otherpage)
exit
}
Is this a best practice? What arguments are there to use this kind of
mechanism?
I've seen form processing being done, when finished it gets a header
redirect to a 'succes' page.
I've seen URL's with wrong or insufficient parameters being redirected
this way.
I've seen too many horrible things that actually belongs into a black
book of webscripting.
What is your opinion about (ab)using rewrites / redirects? Do you use it
quick and dirty, or is it some elegant way of controlling flow?
Thanks.
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other'/
Re: [PHP] General use of rewrite / redirect
Aschwin Wesselius wrote: I've seen form processing being done, when finished it gets a header redirect to a 'succes' page. Yes, that's a very typical setup. When the form is processed, you send a 303 redirect to the Thank you page. That way, if the user hits the back arrow, he's taken back to the form URL, not the post URL. (which would then warn him about re-submitting etc.) What is your opinion about (ab)using rewrites / redirects? Do you use it quick and dirty, or is it some elegant way of controlling flow? I think there are plenty of perfectly valid reasons for using a redirect, whether dynamically from php or via an apache config. And undoubtedly there equally many poor reason for using redirect and/or rewrite. (they're very different things, by the way). /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Per Jessen wrote: Yes, that's a very typical setup. When the form is processed, you send a 303 redirect to the Thank you page. That way, if the user hits the back arrow, he's taken back to the form URL, not the post URL. (which would then warn him about re-submitting etc.) Ok, fine. But why do a real redirect when a header with 303 could be sufficient? If you model good enough, there would not be a need for header(location) redirects. Or am I wrong? What is your opinion about (ab)using rewrites / redirects? Do you use it quick and dirty, or is it some elegant way of controlling flow? I think there are plenty of perfectly valid reasons for using a redirect, whether dynamically from php or via an apache config. And undoubtedly there equally many poor reason for using redirect and/or rewrite. (they're very different things, by the way). I know they're different things. I only want to start a discussion so people do understand other techniques instead of just using whatever 'works' as a solution to their problem with flow. Redirects do solve some issues, but they should be avoided whenever possible. header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. So, if you know what you want to handle (control) and what you want the user to see (view), one should be able to model it without the use of redirects unless it really is needed. Or is it OK, to redirect and 'simplify' the flow? -- Aschwin Wesselius /'What you would like to be done to you, do that to the other'/
Re: [PHP] General use of rewrite / redirect
Quoting Aschwin Wesselius [EMAIL PROTECTED]: Per Jessen wrote: Yes, that's a very typical setup. When the form is processed, you send a 303 redirect to the Thank you page. That way, if the user hits the back arrow, he's taken back to the form URL, not the post URL. (which would then warn him about re-submitting etc.) Ok, fine. But why do a real redirect when a header with 303 could be sufficient? If you model good enough, there would not be a need for header(location) redirects. Or am I wrong? What is your opinion about (ab)using rewrites / redirects? Do you use it quick and dirty, or is it some elegant way of controlling flow? I think there are valid reasons for using a header(location) redirect. As Per already pointed out. I don't see what using header() has to do with a good design. Sometimes you just want to do a redirect 303 or not :) I think there are plenty of perfectly valid reasons for using a redirect, whether dynamically from php or via an apache config. And undoubtedly there equally many poor reason for using redirect and/or rewrite. (they're very different things, by the way). I know they're different things. I only want to start a discussion so people do understand other techniques instead of just using whatever 'works' as a solution to their problem with flow. Redirects do solve some issues, but they should be avoided whenever possible. header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. So, if you know what you want to handle (control) and what you want the user to see (view), one should be able to model it without the use of redirects unless it really is needed. Not much different from a normal page load. Or is it OK, to redirect and 'simplify' the flow? I think it's ok to use. Also think about the fact that not all PHP applications are giant OO monsters. There's some simple scripts out there also. For wich header would be sufficient. -- Aschwin Wesselius /'What you would like to be done to you, do that to the other'/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On Tuesday 18 March 2008 14:22:26 Aschwin Wesselius wrote: Per Jessen wrote: Yes, that's a very typical setup. When the form is processed, you send a 303 redirect to the Thank you page. That way, if the user hits the back arrow, he's taken back to the form URL, not the post URL. (which would then warn him about re-submitting etc.) Ok, fine. But why do a real redirect when a header with 303 could be sufficient? If you model good enough, there would not be a need for header(location) redirects. Or am I wrong? What is your opinion about (ab)using rewrites / redirects? Do you use it quick and dirty, or is it some elegant way of controlling flow? I think there are plenty of perfectly valid reasons for using a redirect, whether dynamically from php or via an apache config. And undoubtedly there equally many poor reason for using redirect and/or rewrite. (they're very different things, by the way). I know they're different things. I only want to start a discussion so people do understand other techniques instead of just using whatever 'works' as a solution to their problem with flow. Redirects do solve some issues, but they should be avoided whenever possible. header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. So, if you know what you want to handle (control) and what you want the user to see (view), one should be able to model it without the use of redirects unless it really is needed. Or is it OK, to redirect and 'simplify' the flow? Are you asking or informing? The way of; I know it all, how do I do it? is confusing. All you do is stating the obvious either way, while it all depends on the task at hand. You may want to reconnect to a different db, cleaning out variables and posts? dunno. Probably you want the least possible transfer over the network since that is more costly than a new computer to a cluster. But with 10.000 users you have to do the math yourself, cuz heavy db tasks vs a small increase in traffic... -- --- Børge Holen http://www.arivene.net -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On Tue, Mar 18, 2008 at 9:22 PM, Aschwin Wesselius [EMAIL PROTECTED] wrote: Per Jessen wrote: Yes, that's a very typical setup. When the form is processed, you send a 303 redirect to the Thank you page. That way, if the user hits the back arrow, he's taken back to the form URL, not the post URL. (which would then warn him about re-submitting etc.) Ok, fine. But why do a real redirect when a header with 303 could be sufficient? If you model good enough, there would not be a need for header(location) redirects. Or am I wrong? What is your opinion about (ab)using rewrites / redirects? Do you use it quick and dirty, or is it some elegant way of controlling flow? I think there are plenty of perfectly valid reasons for using a redirect, whether dynamically from php or via an apache config. And undoubtedly there equally many poor reason for using redirect and/or rewrite. (they're very different things, by the way). I know they're different things. I only want to start a discussion so people do understand other techniques instead of just using whatever 'works' as a solution to their problem with flow. Redirects do solve some issues, but they should be avoided whenever possible. header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. So, if you know what you want to handle (control) and what you want the user to see (view), one should be able to model it without the use of redirects unless it really is needed. Or is it OK, to redirect and 'simplify' the flow? -- Aschwin Wesselius /'What you would like to be done to you, do that to the other'/ i am sorry.. but i don't get what u really want to say. honestly, i don't see any other way (better alternative) to avoid people to simply refresh the browser to submit the form many time. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. i don't see anything wrong with this since that is the way it is. whether you redirect or not, the script will do DB connection, session lookup anyway. i simply called exit; to stop execution after the header redirect.. sorry.. if i misunderstand your point. but that is just my opinion..
Re: [PHP] General use of rewrite / redirect
jeffry s wrote:
Requests are reinitialised, libraries
loaded (again), DB connections setup/checked again, session lookups are
being done, log write for another request etc.
i don't see anything wrong with this since that is the way it is. whether
you redirect or
not, the script will do DB connection, session lookup anyway. i simply
called exit;
to stop execution after the header redirect..
sorry.. if i misunderstand your point. but that is just my opinion..
Ok, let me point it out with an example:
include(this);
include(that);
connect(db);
session check
That is what normally could exist on a script for every page hit.
If you have a page that only does this:
if (GET || POST) {
process form variables
header (location: thankyou)
exit
}
else {
whatever
}
On the thankyou:
echo 'thank you'
What happens is that just for submitting a form (or any process on any
page), most cases all kind of libraries are included, db connection is
made, sessions are checked etc. Besides the effect on PHP, the webserver
does his job too, writing to logs, creating threads etc. Conclusion is
'load per page'.
So what happens in short looks like this:
- do heavy stuff
- process page
- redirect
- do heavy stuff
- show thank you
Why not:
- do heavy stuff
- process page
- show thank you
That is my question. How do you people think about the trade-off of
performance against the ease of just redirecting to another URL just to
be sure a user get's to the right destination?
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other'/
Re: [PHP] General use of rewrite / redirect
Aschwin Wesselius wrote: Per Jessen wrote: Yes, that's a very typical setup. When the form is processed, you send a 303 redirect to the Thank you page. That way, if the user hits the back arrow, he's taken back to the form URL, not the post URL. (which would then warn him about re-submitting etc.) Ok, fine. But why do a real redirect when a header with 303 could be sufficient? If you model good enough, there would not be a need for header(location) redirects. Or am I wrong? What's the difference between a real redirect and a header with a 303? I think there are plenty of perfectly valid reasons for using a redirect, whether dynamically from php or via an apache config. And undoubtedly there equally many poor reason for using redirect and/or rewrite. (they're very different things, by the way). I know they're different things. I only want to start a discussion so people do understand other techniques instead of just using whatever 'works' as a solution to their problem with flow. Redirects do solve some issues, but they should be avoided whenever possible. But redirect and rewrite are not solutions to the same problem - a rewrite is altering the URL internally, a redirect happens externally. header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. I'm having difficulties following you - a plain 303 redirect to a Thank you page shouldn't cause all of that. It's an HTTP reply with the 303 and the new URL, followed by a single URL request from the browser. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Aschwin Wesselius wrote:
Ok, let me point it out with an example:
include(this);
include(that);
connect(db);
session check
That is what normally could exist on a script for every page hit.
Yep, that looks common enough.
If you have a page that only does this:
if (GET || POST) {
process form variables
header (location: thankyou)
exit
}
else {
whatever
}
On the thankyou:
echo 'thank you'
What happens is that just for submitting a form (or any process on any
page), most cases all kind of libraries are included, db connection is
made, sessions are checked etc. Besides the effect on PHP, the
webserver does his job too, writing to logs, creating threads etc.
Conclusion is 'load per page'.
Well, only if you write it like that. The typical Thank you page does
not include all of that stuff. It's pretty much static with some
(cached) graphics, a Thank you and a link back to the main page (or
whereever).
That is my question. How do you people think about the trade-off of
performance against the ease of just redirecting to another URL just
to be sure a user get's to the right destination?
My typical setup for a form-page probably looks like this:
if ( $_POST )
{
// do POST processing
header(303 thankyou.html).
exit
}
// regular page starts here
// process GET (if any)
// database stuff
// display page.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Aschwin Wesselius wrote: Per Jessen wrote: I'm having difficulties following you - a plain 303 redirect to a Thank you page shouldn't cause all of that. It's an HTTP reply with the 303 and the new URL, followed by a single URL request from the browser. OK. I think I know how other people (like you) think about just requesting URL's one after another. If that's not such a performance issue for you, fine. It's not really - serving URLs one after another is what apache is good at :-) A plain 303 redirect mostly isn't just a HTML file, it's another script (or the same script with another action falling through a switch statement, whatever). I disagree - unless the 303 directs back to a new form-entry, the redirect URL is almost always a plain static page. Well, in my designs anyway. Point is: why hitting you webserver with multiple requests per user, just after submitting a form or whatever caused the redirect? If you have 2 users per day, that won't hurt. But if you have 30.000 concurrent users a minute, that could be 60.000 requests (besides all the images, stylesheets, javascripts that are being re-requested). Of which a lot will be cached. But I get your point. The main question is - what is the alternative to the 303? Sometimes I use a method where I set a messages in $_SESSION which will then be displayed on the next page, but I usually only use that in closed (=non-public) web-apps. Even then I still issue the 303 - I don't see how you can get around that. Wrt performance - the old adage of buy a bigger box is becoming more and more applicable every day. It's not always one I agree with, but sometimes performance problems _are_ best solved by a bigger box. Or am I talking nonsense? You seem to be stuck on the possible performance issues in the superfluous serving and processing of a Thank you page. Granted, if your thankyou.html includes all sort of superfluous processing, you've got a problem, but you solve that by getting rid of all that superfluous code (in the 303 page). /Per Jessen -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Per Jessen wrote: header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. I'm having difficulties following you - a plain 303 redirect to a Thank you page shouldn't cause all of that. It's an HTTP reply with the 303 and the new URL, followed by a single URL request from the browser. OK. I think I know how other people (like you) think about just requesting URL's one after another. If that's not such a performance issue for you, fine. A plain 303 redirect mostly isn't just a HTML file, it's another script (or the same script with another action falling through a switch statement, whatever). Point is: why hitting you webserver with multiple requests per user, just after submitting a form or whatever caused the redirect? If you have 2 users per day, that won't hurt. But if you have 30.000 concurrent users a minute, that could be 60.000 requests (besides all the images, stylesheets, javascripts that are being re-requested). Or am I talking nonsense? -- Aschwin Wesselius /'What you would like to be done to you, do that to the other'/
Re: [PHP] General use of rewrite / redirect
On Mar 18, 2008, at 10:11 AM, Per Jessen wrote:
Per Jessen wrote:
My typical setup for a form-page probably looks like this:
if ( $_POST )
{
// do POST processing
header(303 thankyou.html).
exit
}
If I wanted the user back on the same form page, but still with a
thank
you message, I'd still do a 303, but use $_SESSION to indicate that
the user needs a thank you message displayed.
Just to play devils advocate and to try and understand things better...
Is there any reason you couldn't do a simple:
$formsubmitted= true;
if($formsubmitted = true){
Thank you for giving the bad guys your credit card number hahahahahah!
}else{
echo HTML
PGive me your credit card number or I'll force you to eat raw spam
all day!/Pinput type=text name=txtCC
}
Or something like that :)
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Per Jessen wrote:
My typical setup for a form-page probably looks like this:
if ( $_POST )
{
// do POST processing
header(303 thankyou.html).
exit
}
If I wanted the user back on the same form page, but still with a thank
you message, I'd still do a 303, but use $_SESSION to indicate that
the user needs a thank you message displayed.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On Mar 18, 2008, at 10:08 AM, Aschwin Wesselius wrote: Per Jessen wrote: header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. I'm having difficulties following you - a plain 303 redirect to a Thank you page shouldn't cause all of that. It's an HTTP reply with the 303 and the new URL, followed by a single URL request from the browser. OK. I think I know how other people (like you) think about just requesting URL's one after another. If that's not such a performance issue for you, fine. A plain 303 redirect mostly isn't just a HTML file, it's another script (or the same script with another action falling through a switch statement, whatever). Point is: why hitting you webserver with multiple requests per user, just after submitting a form or whatever caused the redirect? If you have 2 users per day, that won't hurt. But if you have 30.000 concurrent users a minute, that could be 60.000 requests (besides all the images, stylesheets, javascripts that are being re- requested). Or am I talking nonsense? I don't know much about the actual load stuff... but I do know unless you specifically set it, the CSS should be cached unless you refresh it and the date has changed on the file. I assume the same with the images as well. -- Aschwin Wesselius /'What you would like to be done to you, do that to the other'/ -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On 18 Mar 2008, at 14:08, Aschwin Wesselius wrote: Per Jessen wrote: header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. I'm having difficulties following you - a plain 303 redirect to a Thank you page shouldn't cause all of that. It's an HTTP reply with the 303 and the new URL, followed by a single URL request from the browser. OK. I think I know how other people (like you) think about just requesting URL's one after another. If that's not such a performance issue for you, fine. A plain 303 redirect mostly isn't just a HTML file, it's another script (or the same script with another action falling through a switch statement, whatever). Point is: why hitting you webserver with multiple requests per user, just after submitting a form or whatever caused the redirect? If you have 2 users per day, that won't hurt. But if you have 30.000 concurrent users a minute, that could be 60.000 requests (besides all the images, stylesheets, javascripts that are being re- requested). Or am I talking nonsense? What Per is saying is that you should be doing the minimum amount of work possible to handle each request. If you have a shedload of code that runs for every single page request regardless of what it's going to do then your architecture sucks. If that is the case then avoiding unnecessary bounces off the client is probably a good idea. If your site is well-architected then redirects of this type will probably not be a big performance drain. One minor thing... a 303 redirect is permanent. In this situation you want to use a 302 otherwise you could potentially cause problems with proxies. My opinion is that a redirect is the best way to prevent duplicate posts. It prevents the user from getting the confusing popup and it means you don't need to track whether a form has been posted yet. If your application is well-architected you shouldn't need to worry about performance. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On 18 Mar 2008, at 14:49, Jason Pruim wrote:
On Mar 18, 2008, at 10:11 AM, Per Jessen wrote:
Per Jessen wrote:
My typical setup for a form-page probably looks like this:
if ( $_POST )
{
// do POST processing
header(303 thankyou.html).
exit
}
If I wanted the user back on the same form page, but still with a
thank
you message, I'd still do a 303, but use $_SESSION to indicate that
the user needs a thank you message displayed.
Just to play devils advocate and to try and understand things
better...
Is there any reason you couldn't do a simple:
$formsubmitted= true;
if($formsubmitted = true){
Thank you for giving the bad guys your credit card number
hahahahahah!
}else{
echo HTML
PGive me your credit card number or I'll force you to eat raw spam
all day!/Pinput type=text name=txtCC
}
Or something like that :)
Because if the user reloads that page you'll process the form again,
which could have any number of nasty effects from creating a duplicate
row in the database to charging a credit card again. It also causes a
potentially confusing confirmation request to be displayed to the user.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Quoting Aschwin Wesselius [EMAIL PROTECTED]: Per Jessen wrote: header(location) mechanisms do come with a very huge disadvantage if you don't use them with caution. Requests are reinitialised, libraries loaded (again), DB connections setup/checked again, session lookups are being done, log write for another request etc. That's quite an impact for just not knowing what to do with flow. I'm having difficulties following you - a plain 303 redirect to a Thank you page shouldn't cause all of that. It's an HTTP reply with the 303 and the new URL, followed by a single URL request from the browser. OK. I think I know how other people (like you) think about just requesting URL's one after another. If that's not such a performance issue for you, fine. People like who? Come on we try to help. A plain 303 redirect mostly isn't just a HTML file, it's another script (or the same script with another action falling through a switch statement, whatever). A 303 is whatever you make of it. Point is: why hitting you webserver with multiple requests per user, just after submitting a form or whatever caused the redirect? If you have 2 users per day, that won't hurt. But if you have 30.000 concurrent users a minute, that could be 60.000 requests (besides all the images, stylesheets, javascripts that are being re-requested). Or am I talking nonsense? True. Why hit your webserver with useless requests. But if you submit a form. There must be a action behind it .. right? So you either reload the page, use header() or some other method. The next page needs to be loaded. And so will CSS, JS, images. -- Aschwin Wesselius /'What you would like to be done to you, do that to the other'/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
Stut wrote: One minor thing... a 303 redirect is permanent. In this situation you want to use a 302 otherwise you could potentially cause problems with proxies. A redirect following a POST really should be a 303 - RFC 2616 : 10.3.4 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On 18 Mar 2008, at 15:33, Per Jessen wrote: Stut wrote: One minor thing... a 303 redirect is permanent. In this situation you want to use a 302 otherwise you could potentially cause problems with proxies. A redirect following a POST really should be a 303 - RFC 2616 : 10.3.4 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. My bad. Confusing a 303 with a 301. It's been a long day. Etc. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
im sorry i havent read through all the replies, but i have read through several of them. i essentially agree w/ Aschwin here. redirects have been the bane of my existence in several source bases ive worked on. to borrow a phrase (read in closures article mentioned in another thread) they really bump up the 'wtf factor'. and ill tell you whats worse, one of the most horrible things i have ever seen is this crap meta http-equiv=refresh content=0;url=http://wikipedia.org/ which is not too dissimilar. i remember my initial encounter with this construct, it looked as if the page was morphing in front of me, there were no header() directives on the server there were no window.location calls in the javascript, it drove me mad, and then when i discovered what it was i practically became livid. what it boils down to, is the most common usage of header(location:) is a lack of design capabilities by the person writing the code on the server side *ducks*. that said, there are plenty of valid reasons for using them, and i have them in my code in plenty of places, but plain and simple, if you have a decent sized app, handle routing on the server side, period. there is only one caveat i have found that is relevant and that is if GET parameters in a url from a page submission will incite a change to the database schema (which is a bad practice anyway) then what can happen is a page will go to the server, mod the schema, and load up the fresh page (having been internally routed back to the 'view' code lets say). so then you have a problem where the 'layman' user will periodically want to see the latest data on the page (if the data displayed was updated by someone else in the system for example). so then what happens when they refresh the page? (the one w/ the GET params that incite the db schema change) well you get theoretically undefined or at least undesirable behavior,instead of simply refreshing the 'view' logic, a database schema mod is invoked. some situations where i find this mechanism useful, and reasonable are 1. implementing pretty urls 2. preventing access to directories 3. mapping one url or sub-domain to another 4. in pitifully trivial applications (of which i have written a few ;) im sure there are other uses and also im aware that i dont know as much about http as i should or at least thats how i feel about it anyway. im sure there are additional uses when implementing restful apis for example. as aschwin has mentioned about the unnecessary use of server resources (and bandwidth obviously) i cannot agree enough. what i would say to dissuade those who view this as a typical page load is, think about the client experience. 1. unnecessarily long page load time (have to sit through all the mind numbing redirects) 2. additional, unnecessary full-page reloads 3. awkward transitions in the user interface (morphing described earlier from previous experience) this leads to confusion, frustration and in all a degraded experience for the user. not to mention the confusion, frustration and degradation of the programming experience for those who have to cleanup a web of these things on the server side ;) /end rant -nathan
Re: [PHP] General use of rewrite / redirect
On Tuesday 18 March 2008, Aschwin Wesselius wrote: Point is: why hitting you webserver with multiple requests per user, just after submitting a form or whatever caused the redirect? If you have 2 users per day, that won't hurt. But if you have 30.000 concurrent users a minute, that could be 60.000 requests (besides all the images, stylesheets, javascripts that are being re-requested). Or am I talking nonsense? If you send a redirect header, that gets sent before any HTML gets sent so no JS or images are sent either. The payload cost of a redirect is trivial. The cost of the second bootstrap process may or may not be problematic. You have to trade that off against the code simplification you can get out of redirects (or the code complication you can get if you use it stupidly). Take for instance Drupal (which I use as an example because I'm a core dev for it). Drupal does a redirect at the end of every form submission. That redirect is controllable; it could go back to the form (submit to self), or to a thank you page, or the home page, or to a page in the system that you just created, or any number of other places. That flexibility is worth the cost of the second bootstrap (and Drupal's bootstrap is admittedly not small), especially because the vast majority of Drupal sites and PHP sites in general are read-heavy, not write-heavy, so it's not a substantial number of additional bootstraps. It also means that if the user hits reload, they don't resubmit the form because they're not on the POST-requested page. I will say in general you should not ever have more than one redirect chained together. While there may be valid reasons for it conceptually, trying to trace and debug that workflow is overshadow any advantage it could otherwise offer. (IMO, YMMV, etc.) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On Tuesday 18 March 2008, Jason Pruim wrote: I don't know much about the actual load stuff... but I do know unless you specifically set it, the CSS should be cached unless you refresh it and the date has changed on the file. I assume the same with the images as well. True, but bear in mind that the browser has to make a HEAD request for every such file in order to determine if it needs to download it again. That's a non-small amount of HTTP traffic if you have a lot of images or CSS files. In Drupal (there I go again), we implemented a CSS file aggregator that merges all queued CSS files into one and caches it, then sends just the one file. Just switching that aggregator on, I can easily cut page load time in half. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] General use of rewrite / redirect
On Tue, Mar 18, 2008 at 9:45 PM, Larry Garfield [EMAIL PROTECTED] wrote: Take for instance Drupal (which I use as an example because I'm a core dev for it). thats pretty cool. I will say in general you should not ever have more than one redirect chained together. While there may be valid reasons for it conceptually, trying to trace and debug that workflow is overshadow any advantage it could otherwise offer. (IMO, YMMV, etc.) this much i agree w/ and i would say to extend upon it that using multiple redirection mechanisms in a chain is also a bad idea. eg. header(location: ) to some page. that page uses a meta tag to do a redirect to somewhere else. ive had to deal w/ this stuff and ended up stripping out all of those stupid meta tag redirects, as well as many of the header redirects on the server. -nathan
