Menu
As we all know, file uploading is most often accomplished using POST method. So, why can't the GET method be used for file uploads instead? Is there a specific prohibition against HTTP GET uploads?
692
Mainly because GET is used to get information, while POST is used to posting it to the server. Very basically, use GET only for things that do not change anything on the server, and POST only for things that do. Uploading data in a GET command makes perfect sense when the data is a parameter for the GET.
HTTP Request action allows you to upload files on a specified service.
In PHP, we can access the actual name of the file which we are uploading by keyword $_FILES[“file”][“name”]. The $_FILES is the by default keyword in PHP to access the details of files that we uploaded. The file refers to the name which is defined in the “index. html” form in the input of the file.
RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method -- it's nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via POST/PUT/etc. Weird, right? Not a very good abstraction, is it?
So what does the spec say about the GET method ... well:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe."
So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is only "SHOULD NOT" ... technically HTTP still allows a GET requests to result in an action that isn't strictly based around "retrieval."
Of course, from a semantic standpoint using a method named GET to perform an action other than "getting" a resource doesn't make very much sense either.
Regarding idempotence, the spec says:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.
This means that a GET method must not have differing side-effects for multiple requests for the same resource. So, regardless of the entity body present as part of a GET request, the side-effects must always be the same. In layman's terms this means that if you send a GET with an entity body 100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must have the same result. This severely limits the usefulness of the GET method for sending entity bodies.
When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy of a method and its resulting side-effects.
80
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
