2

In producing a web-based data entry system, is the fact that you are adding an extra server request per page a significant concern when deciding whether or not to use a post/redirect/get design?

Wes
  • 1,834
  • 3
  • 15
  • 26

5 Answers5

4

The request alone isn't a problem, especially that the alternative gives a pretty bad user experience.

However, when using a site with load balancing and/or database replication, you need to take care to ensure that the GET after POST will see the data that has been posted.

When using load balancing and caching, this is sometimes solved with "sticky sessions" that direct the same user to the same machine, so data stored in a write-through cache on that machine will be current.

When using database replication, GET requests after POST may need to read directly from the "primary" database, instead of a local "secondary" as usual.

Kornel
  • 97,764
  • 37
  • 219
  • 309
  • 2
    Another option is to use database mirroring instead of replication, and memcached for caching. Then it doesn't matter which front end the user gets redirected to. – Jesse Weigert Dec 16 '09 at 19:40
  • Thanks for the additional things to think about! – Wes Dec 16 '09 at 19:43
2

If I understand your question (and I'm not entirely sure I do), it is definitely good design to do a redirect after a post, even if you are showing them the same page with the updated info.

By doing the redirect you are breaking the connection between the page being viewed and the POST which caused the change. The user can bookmark and/or refresh the page without any popup asking "Do you want to resend the data?"

Peter Rowell
  • 17,605
  • 2
  • 49
  • 65
  • I don't know what language/framework/server you are using, but there are a gazillion examples on the net in ever possible language. Simply search on POST/REDIRECT/GET. [Here is the Wikipedia](https://en.wikipedia.org/wiki/Post/Redirect/Get) page on it. – Peter Rowell Jul 30 '17 at 20:36
  • I have gone through all such articles but unable to understand still. What I understand here is: In abc.php
    Then in xyz.php I should collect the data using $x=$_POST['']; Then redirect to abc.php & use $x=$_GET['']; to collect the data again? It's very confusing.
     – Prakash Patil Aug 01 '17 at 19:40
  • No. POST/REDIRECT/GET (those are HTTP commands, *not* PHP global variables) is to *avoid* the problem of someone filling out a form, submitting it (POSTing it), landing on the 'Thanks!' page, *and then hitting Refresh while on the 'Thanks!' page.* The browser asks, 'Do you want to resubmit your data' (or whatever), and most bozos won't read/understand that and just click Yes, because that's what they always do. So the data gets sent to the site *again*, which is probably *not* what you wanted to have happen. The REDIRECT causes them to be on a "safe" page, i.e. no resubmit of data. – Peter Rowell Aug 01 '17 at 23:03
  • Yes I understand what the error occurs. I am facing those issues from a long time. I have read thousands of articles explaining it with diagrams. But noone gives a working example. I have a php page that is xyz.php when a user submits the form the same page collects the data and makes an entry into the database. But when the user refreshes the page he gets that resubmit data message. So shall I create another php page like abc.php and collect the data there & then use header("Location:xyz.php"); & then use $_GET and in xyz.php? – Prakash Patil Aug 03 '17 at 11:04
  • Here are 3 pages to look at: 2 SO conversations on the topic (both 4+ years old and with examples) [here](https://stackoverflow.com/questions/4142809/simple-post-redirect-get-code-example) and [here](https://stackoverflow.com/questions/10827242/understanding-post-redirect-get), and a [google search result](https://www.google.com/search?q=php+post+redirect+get&oq=php+post+redirect) (with 73+ million hits). I'm done. – Peter Rowell Aug 04 '17 at 18:42
0

Most of the time, posts only happen when data is changed. The most traffic and CPU time on sites is generated by queries (GETS) rather than changes, so I think these extra requests aren't very significant.

Jeroen Landheer
  • 9,160
  • 2
  • 36
  • 43
0

I think the usability that this offers outweighs the small performance hit.

Jesse Weigert
  • 4,714
  • 5
  • 28
  • 37
0

Test it out by performing some performance benchmarks and you will be able to see if it is going to be a concern in your particular case. See this article for more information.

David Glass
  • 2,334
  • 1
  • 25
  • 35