6
I am creating a filter page, but this page will have many fields for the user to fill, select and this will make a search in the bank mysql and will return the data to the user on another page.
One of the doubts I have, that being many fields, with fields of type select, input’s[text, option, checkbox], is if I send the data by get or is in this case step by post?
3
The best is to use POST for this type of action, especially if you have some field of the type textarea, where the content can be very large and can extrapolate the url limit (despite not having an established limit, generally servers limit, and it is advisable to use URL’s smaller than 2000 characters. Source) where the method is GET.
But when there is no need for a textarea (which I don’t see much use in a filter) and has a good validation against SQL Injection can use GET hassle-free.
A good improvement for filters of many fields is to create a history of favorite queries and queries.
1
Summing up I find post safer.
The GET method
GET, one of HTTP’s methods, is triggered by an HTML form via the method=get directive included in the tag. Through this method, the data in the form is first transmitted to the server software and this, in turn, stores the data temporarily in a context variable called QUERY_STRING.
A CGI script, called via the action= directive included in the initial tag of the form, needs to extract the data from this context variable in order to obtain the data that was sent to it (see also context variables). Using Perl, for example, it is possible to extract this data with $dados_form = $ENV{'QUERY_STRING'};.
When an HTML form uses the GET method, the data stream is separated from the URL address that calls the CGI via a question mark (?). This form of addressing and sorting can be seen in the address field of the user’s browser just after the form has been sent. You’ll see something like:
http://www.meusite.com/meuscript.cgi?nome=Maria&id=123The POST method
POST, also an HTTP method, is triggered by an HTML form via the method=post directive included in the tag .
This method causes the form data to be directly transmitted to the address listed in the action=directive. A CGI script, called by action=, needs to extract the data through the standard input (standart input) in order to obtain the data transmitted by the form. You can, for example, use Perl and indicate read(STDIN, $Data, $ENV{'CONTENT_LENGTH'});.
Note that the program needs to get the value of the CONTENT_LENGTH context variable to know how many characters need to be read through the standard input. This is necessary because there is no separator character in the data stream.
The importance of knowing the method
If you want to make use of a ready-made CGI script, you need to know by which of the two methods the script expects to receive data. Usually this is documented by the author of the script. Some smarter scripts test both methods - in this case, no matter what data transfer method you use in the form - both will work.
If you are writing your own scripts, remember to determine which method should be used in the form. Or program intelligently: get the script ready for both methods.
Data flow in form data transmission
A typical HTML form is composed of named fields (for example for name, address, and comment). In the transmission of the completed form to the web server / CGI program, the data needs to be transmitted in such a way that the CGI script is able to identify the form fields and their values. This is why there is a specific coding method that separates the form fields from their respective values. This coding method is based on the following rules:
. Each of the form elements, including their values, are separated by the & ("e" commercial or ampersand) symbol; . The name and value (data) of a form item are separated by = (equals sign); . Blank spaces in the data (e.g. several words) are replaced by + (plus sign); . All extended ASCII characters, with values from 128 to 255 (hexadecimal 80 to FF), are replaced by a set consisting of the % (percent) sign followed by the hexadecimal value of the character (e.g. our ç (cedilla) is replaced by %E7); . All characters used in these rules as delimiters (i.e., &, +, = and %) are also converted to hexadecimal following the same rule for extended ASCII characters.
Thanks for the answer, but still did not really take away my doubt I have and commented "Summarizing I find post safer." I still don’t think that’s the right answer to what I need. Valew
I think for a better answer we need better questions
I think you got me wrong, but okay. What I meant is that for what I asked I would like to know other things, as a matter of amount of characters that can be passed by the get and the post, security, but something more concrete regarding security, but still thank you
Now understanding a little better Browsers allow up to 2kb, or between 2000 and 2400 bytes. The limit depends on each browser
Browser other questions tagged php mysql
You are not signed in. Login or sign up in order to post.
So, it’s not like creating the filter, but what better way to use, I ask this pq, I know that if I send by get will be in the user’s url and with this it can copy and paste and query in the future (this may be good) but at the same time, as you said yourself, if I have a field of type textarea, for example, you may exceed the limit of the url.
– Marcelo Diniz
And taking advantage, I edited the question, I think it’s a little bit clearer now.
– Marcelo Diniz
This, but like, you can limit the size of the textarea, although I don’t see much use in textarea for a filter, so in this case you can use the GET method without any problems, remembering only to do a good validation to avoid SQL Injection and voila.
– KaduAmaral
Oh yes, not that I have textarea in my filter, but some input fields[type=text], select>option, input[type=radio], input[type=checkbox] but there are several of all these.
– Marcelo Diniz
I just saw in another question, about the boundary of the URI. I even updated the answer there.
– KaduAmaral