This question already has answers here:
When should I use GET or POST method? What's the difference between them?
(15 answers)
Closed 9 years ago.
I'm new in this forum and I'm learning PHP from this night.
I want to send a form but I do not know the difference between:
<form action="page2.php" method="GET">
and
<form action="page2.php" method="POST">
Anyone could help me please ?
Thanks.
GET:
Parameters remain in browser history because they are part of the URL
Can be bookmarked.
GET method should not be used when sending passwords or other sensitive information.
7607 character maximum size.
Url example: page2.php?category=sport
POST:
Parameters are not saved in browser history.
Can not be bookmarked.
POST method used when sending passwords or other sensitive information.
8 Mb max size for the POST method.
Url example: page2.php
By convention HTTP GET is used for search forms while HTTP POST is used to change forms. A GET displays its information in the URL, publicly viewable, from which you can query the variables. A POST will not display its information. There is really no difference security wise.
If a GET request is used, the form parameters are encoded in the URL in what is called a query string.For example
www.someemailprovider.com/?login=joe#email.com&password=xxyz
A POST request, unlike a GET request, passes the form parameters in the body of the HTTP request, not in the URL.
Moreover GET is idempotent and POST is not that means If you call GET method on server nothing will be changed on server, but if you call POST then server will be changed may be a some additional data will be added in to the server, so GET is idempotent while POST is not.
Note
The main thing to keep in mind as a programmer is that defining your form to use the GET method does not protect against causing changes. You could use a GET request to do pretty much the same thing as a POST query. It’s just that browsers are generally coded to expect that POST requests will be used for things that will cause changes – like placing an order, or writing to a database, etc . GET requests should be used for pure queries that don’t affect anything on the server. So, one should always remember not to use GET requests for any action that would cause a change on the server – like ordering a big screen tv.
These are both HTTP request methods, not PHP exclusive.
$_GET is appended to end or URL. i.e. http://example.org/?foo=bar
Access it in PHP with:
$foo = $_GET['foo'];
or
$foo = $_REQUEST['foo'];
GET is used for information you don't mind people seeing, and can be manually typed into links and urls to get results.
$_POST is not visible in your URL, and generally is used after submitting a form.
Access it in PHP with:
$foo = $_POST['foo'];
or
$foo = $_REQUEST['foo'];
Read more about HTTP requests at http://www.w3schools.com/tags/ref_httpmethods.asp
Related
I read on SoloLearn that the method attribute of an input tag within a form can be set to GET or POST. If both methods are sending data to another location, is an HTTP GET being used somehow? I thought GET was used to retrieve data, not send it. Can anyone help me understand, please?
All HTTP requests involve sending something to the server.
A GET request is designed to be used to ask for something.
If you GET http://example.com/ then you ask for the root document for that site.
If you submit the form at https://duckduckgo.com/ then your request is to GET https://duckduckgo.com/?q=example&t=hf&ia=web. You are asking for the search results for the keyword "example".
This question already has answers here:
HTTP GET with request body
(23 answers)
Closed 7 years ago.
I don't want to see so long parameters string in the URI. So, can GET method use json data?
In my situation, I need to filter the result given kind of parameters. If there are a lot of parameter, the length may exceed the limit of URI. So, is there best practice for this problem?
In theory, there's nothing preventing you from sending a request body in a GET request. The HTTP protocol allows it, but have no defined semantics, so it's up to you to document what exactly is going to happen when a client sends a GET payload. For instance, you have to define if parameters in a JSON body are equivalent to querystring parameters or something else entirely.
However, since there are no clearly defined semantics, you have no guarantee that implementations between your application and the client will respect it. A server or proxy might reject the whole request, or ignore the body, or anything else. The REST way to deal with broken implementations is to circumvent it in a way that's decoupled from your application, so I'd say you have two options that can be considered best practices.
The simple option is to use POST instead of GET as recommended by other answers. Since POST is not standardized by HTTP, you'll have to document how exactly that's supposed to work.
Another option, which I prefer, is to implement your application assuming the GET payload is never tampered with. Then, in case something has a broken implementation, you allow clients to override the HTTP method with the X-HTTP-Method-Override header, which is a popular convention for clients to emulate HTTP methods with POST. So, if a client has a broken implementation, it can write the GET request as a POST, sending the X-HTTP-Method-Override: GET header, and you can have a middleware that's decoupled from your application implementation and rewrites the method accordingly. This is the best option if you're a purist.
To answer your question, yes you may pass JSON in the URI as part of a GET request (provided you URL-encode). However, considering your reason for doing this is due to the length of the URI, using JSON will be self-defeating (introducing more characters than required).
I suggest you send your parameters in body of a POST request, either in regular CGI style (param1=val1¶m2=val2) or JSON (parsed by your API upon receipt)
Why if I submit an URL like:
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER ,
I get an error that says "Bad Request - invalid URL HTTP Error 400. The request URL is invalid." ?
The default maximum length of a URL is 4096 in IIS. You may well be breaching that with the comment posted by the user. Generally, the best way to transfer that kind of data is by POST rather than in a URL. You can either trim the comment to a more suitable size of increase the maxUrl value in the requestLimits section of your IIS config: http://msdn.microsoft.com/en-us/library/ms689462%28v=vs.90%29.aspx
Firstly, HTTP 400 error is intended for cases when the client has made an error. As you've noticed yourself it's a bad request error. So that means possibly due to bad syntax the request can not be carried out. As Mike Brind mentions, you're most probably exceeding the maximum length of the URL (the default value anyway)
Secondly, why are you trying to "submit" a long post by URL? Use the POST method instead. A way to do this is by using Jquery's Post method to do this. See this. Or simply by calling the form's submit method through OnClick method or however the user is submitting the form.
POST is perfect for transmitting large amounts of data. So submitting data from the client side, the easiest way by far is to use POST to archieve this.
As you have yourself stated in the Question code part,
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER
the Long comment by user, must be inside the limits that are in the web.config file of your website.
Secondly, no Server would allow a very Long Url thinking that the user might be trying to post a malware. Also, using short URLs is good for Data transfer as they consume less data.
From the limits on Requests one would easily come to understand that the URL must be less than 4096bytes, only 4KB. So do you think, all that URL would be 4KB?
As Mike has suggested to use POST request to send the long data, I would also suggest you to use HttpPost requests to send this type of long data. This way, Browser would encrypt the data and sending it as an attachment to the request.
I know differences and advantages of each command, my question is could I replace POST requests with GET everywhere? And which these commands calls by default while sending request from html form?
could I replace POST requests with GET everywhere
No (and it would be a terrible idea to try).
Things that a form can do with POST that you can't do with GET include:
Sending lots of data
Sending files
There are other things that would simply be stupid to do with GET.
From http://www.w3.org/TR/html5/forms.html#attr-fs-method :
The method and formmethod content attributes are enumerated attributes
with the following keywords and states:
The keyword get, mapping to the state GET, indicating the HTTP GET
method. The keyword post, mapping to the state POST, indicating the
HTTP POST method. The invalid value default for these attributes is
the GET state. (There is no missing value default.)
When using GET to transfer data from the client to the server, the data is added to the URL, there is not BODY of the request. There is usually a limit on how long a URL can be, in the old days this was 1024 characters but that really depends on the server software and server middleware and even the browser.
This means if you want to transfer loads or data or upload a file to the server, you can not do it with GET.
I know that there are two methods of submitting a form: 'GET' and 'POST'. We can also use request method for accessing the content of the submitted.
I want to know whether there is any other method of submitting the form. As far as my knowledge there are only two methods. But some one asked me this question in a interview that there are 5 method of submitting the form.
If any one has any idea about this please tell me.
The question was probably about HTTP request methods. There 9 request methods:
HTTP defines nine methods (sometimes referred to as "verbs")
indicating the desired action to be performed on the identified
resource. What this resource represents, whether pre-existing data or
data that is generated dynamically, depends on the implementation of
the server. Often, the resource corresponds to a file or the output of
an executable residing on the server.
HEAD: Asks for the response identical to the one that would
correspond to a GET request, but without the response body. This is
useful for retrieving meta-information written in response headers,
without having to transport the entire content.
GET: Requests a representation of the specified resource. Requests
using GET (and a few other HTTP methods) "SHOULD NOT have the
significance of taking an action other than retrieval". The W3C has
published guidance principles on this distinction, saying, "Web
application design should be informed by the above principles, but
also by the relevant limitations." See safe methods below.
POST: Submits data to be processed (e.g., from an HTML form) to
the identified resource. The data is included in the body of the
request. This may result in the creation of a new resource or the
updates of existing resources or both.
PUT: Uploads a representation of the specified resource.
DELETE: Deletes the specified resource.
TRACE: Echoes back the received request, so that a client can see
what (if any) changes or additions have been made by intermediate
servers.
OPTIONS: Returns the HTTP methods that the server supports for
specified URL. This can be used to check the functionality of a web
server by requesting '*' instead of a specific resource.
CONNECT: Converts the request connection to a transparent TCP/IP
tunnel, usually to facilitate SSL-encrypted communication (HTTPS)
through an unencrypted HTTP proxy.
PATCH: Is used to apply partial modifications to a resource.
HTTP servers are required to implement at least the GET and HEAD
methods
The HTML form element's method only accepts two parameters, GET and POST. Evidenced by this entry on the W3 Standards site:
method (GET|POST) GET -- HTTP method used to submit the form--
They may have been asking you about ways to submit the data. In which case there are many more, like AJAX, Flash, P2P types, etc.
However if they specifically said FORM, as in the HTML FORM element -- then no. POST and GET.
Addendum: Here is a StackOverflow question asked on a similar topic. In that the answerer highlights other methods which can be submitted via AJAX. Again, though, note that these are down through AJAX and not strictly through the FORM element.