[FX.php List] Problem with creating duplicate records

Steve Hannah shannah at sfu.ca
Sat Jul 22 02:52:12 MDT 2006


You make a good point and this adds some perspective to the issue.    
I haven't run into many browsers lately that have a 227 character  
limit (though they may  exist).  The SGML spec places a limit of 1024  
characters for URLs which should be more than enough for any search  
form.

In any case, the choice to use POST instead of GET is fine even if  
you're not updating the database.   The opposite is not true though.   
One should not use GET on a request that updates the database.

As a general rule a request that updates the database should not  
display the results on the same page.  It should forward to a new  
benign page that displays the results.  This ensures that pressing  
"refresh" will not cause the database to again be updated.

Best regards

Steve
On 21-Jul-06, at 5:11 PM, DC wrote:

> Though this is one 'intention' of GET v. POST remember the limits  
> on GET requests are determined by the browser your users use. So,  
> there are other practical implementation details that might cause  
> you to simply use whichever is most expedient.
>
> GET something like 227 characters
> POST something like 33k
>
> So, if you imagine sticking to this rule of thumb you might find  
> yourself down the road with an advanced search page (which  
> theoretically would be handled with GET) with lots of input fields  
> and it just might choke on GET. IMO, because search interfaces use  
> multiple form fields you don't really want to use GET.
>
> Another reason not to use GET is that POST obscures the data from  
> the casual snooper and makes your URLs look better. So, someone  
> won't be tempted to click in the URL bar and see what happens if  
> they change their id_number=234 to another number, etc...
>
> GET requests are stamped into the webserver log so they are not  
> good for sending passwords unless they are encrypted.
>
> anyone else got any stumbling blocks to add?
>
> dan
>
> On Jul 21, 2006, at 7:01 PM, Steve Hannah wrote:
>
>> This problem can be solved by carefully following the intentions  
>> of HTTP requests:
>> 1.  GET requests do not change data in the database.
>> 2.  POST requests can update data in the database.
>>
>> Hence, your forms should always be displayed by a GET request, and  
>> saved via a POST request.  When you process the form received from  
>> a POST request, you do your database updates and then forward to a  
>> new page with a GET request to show the next form.
>>
>> e.g.
>>
>> HTTP request: GET mypage.php :
>>
>> <form action="mypage_processor.php" method="POST">
>> ... a bunch of fields in the form...
>>
>> </form>
>>
>> User submits this form which sends an HTTP POST request to  
>> mypage_processor.php:
>>
>> In mypage_processor.php:
>>
>> if ( form validates ok){
>>     process the form
>>     if ( form processed ok){
>>         forward user to next form or success page:
>>         e.g.:  header('mypage2.php?message='.urlencode 
>> ('Successfully saved content')); exit;
>>     } else {
>>         forward user to failure page.
>>         e.g.:  header('my_failure_page1.php?message='.urlencode 
>> ('Failed because ...')); exit;
>>     }
>> } else {
>>     form didn't validate -- either display the form again right  
>> here with info about which fields were
>>    input incorrectly -- or forward back to the original form for  
>> the user to fill in... probably easier to
>>    just display it here again:
>>
>>    include('mypage.php');
>>
>> }
>>
>> This way, if the user reloads a form, it just reloads the form -  
>> and doesn't trigger the processing information.
>>
>> Hope this helps.
>>
>> ----------------------------------------
>> Steve Hannah
>> Web Services Developer
>>
>> Faculty of Applied Sciences
>> Simon Fraser University
>> shannah at sfu.ca
>> 604-268-7228
>> Homepage: http://www.sjhannah.com
>> --
>> Need to build a database driven web application quickly?
>> Try Dataface: http://fas.sfu.ca/dataface
>>
>>
>>
>> On 21-Jul-06, at 2:45 PM, Jerry Do wrote:
>>
>>> Hello all,
>>>
>>> I am new to fx.php and php.  I have problem users create  
>>> duplicate records
>>> by reload the response page.
>>> For example:
>>> I have a form name "formA" and the ACTION ="formA_response.php".
>>> When the user click submit, the form will send all the  
>>> information to
>>> formA_response.php.
>>> The formA_response.php page is the page to create new record.  I  
>>> noticed
>>> that if a user reload formA_reload.php,  new record will be  
>>> created.  Is
>>> there a good method to prevent the user reload the page or going  
>>> to that
>>> page?
>>> I am thinking that I might send to a page that will create the  
>>> record then
>>> close that page after the record created.  However, I am not sure  
>>> it will
>>> work or how to do write it yet.
>>>
>>> Any input is welcome.
>>>
>>> Thank you in advance,
>>>
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
>



More information about the FX.php_List mailing list