This question already has answers here:
When do you use POST and when do you use GET?
(27 answers)
Closed 6 years ago.
We can accomplish the same thing by doing:
localhost:3000/endpoint?var1=val1&var2=val2
That we can do by using POST with a JSON body.
So why should anyone use PUT/POST/PATCH if they can get the same goals by using url params? Even with auth, instead of header, you can send the information of the auth token back and forth by using a parameter?
one reason is that GET parameters have to be URL-encoded.
then there are limitations of URL length documented in RFC I think.
This will make it difficult when transfering large data (e.g. file uploads,...)
additionally, developers may want to hide some informations from the user, to prevent users to bookmark a page with all these parameters...
Definitely NO reason for POST args is security on the transport layer. in both cases the data are plain text in HTTP, and both (also the URL) are encoded end-to-end when using a secure HTTPS connection.
It is more secure, because your data is encrypted and sent in the header of the request.
Related
This question already has answers here:
Sending PHP GET data to server using Html links
(2 answers)
Closed 4 years ago.
I know that requests placed by jQuery $.get() can include an optional parameter for additional data. I was wondering if there was any way to pass that information through requests that come about by clicking an link, or relocation the windows location.
Yes, you can use a Query String.
Excerpt:
Typical URL containing a query string is as follows:
http://example.com/over/there?name=ferret
When a server receives a request for such a page, it may run a program, passing the query string, which in this case is, name=ferret unchanged, to the program. The question mark is used as a separator, and is not part of the query string.
So your anchor could be:
My Link
or
My Link
or
My Link
Be aware that you can get caching issues by links/get requests.
The only way to pass data through a link as the page is visited is to use URL Parameters/Query Strings.
This question already has answers here:
How to send an email from JavaScript
(20 answers)
Closed 4 years ago.
I have a problem. I want to put a contact form on the page, but I do not know how to do it in the Vue. I wanted to do it normally as jquery, php, but it does not work in Vue. Does anyone have an idea what I can do?
Vue is a View (hence the name) library, meant for describing your View layer i.e. how your application looks. Such logic as sending an email would for one be dependent on Javascript itself and not on Vue.
However it is not possible to send an email from Javascript in the browser. Instead you'd need to build a backend which can send an email for you, or you could call the user's email client, both described here.
You would ideally send email data (to, message body - html escaped of course) as a request to a backend end point and send from there. You can use Vue's HTTP resource to send the request: https://github.com/pagekit/vue-resource
But sending an email directly from Vue isn't possible.
This question already has answers here:
Passing "#" hash symbol in request parameter of url not working in Firefox
(3 answers)
Closed 6 years ago.
I have a problem. I'm working with Elixir Phoenix and React.JS. I have a Token that is used to verify the user. This Token also has hashtags in it so when I send a request to verify it, it is being sent without the hash symbols and what comes after them which makes my request to fail. How can I solve this issue? For some reason I don't have that problem when I use fetch with React Native, but here I do. I tried many variations as you can see in the image.
The hash and anything after it will not be sent by browsers in a request.
You should encode the token so that the hash is escaped.
fetch('http://localhost:4000/api/users/'+encodeURIComponent(accesstoken), {
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm wondering, why are we still using GET method in AJAX requests for example:
$.ajax({
type: "GET",
url: "SomeController/GetSomething",
data: { id: 100}
});
GET is handy, when you want to store data in url, when you are querying Google and you want to send that query to friend or whatever else. On the other hand, we have security gaps. They are not big (I'd say they are obstacles), but it'd be slightly better to use POST when you don't want to show form data. Moreover, POST can store any type of data, control data size and hide somehow passing variables.
Is it a good solution to always use GET in places, which are not "public" (search bars, article page, user profile, ...) and use POST everywhere else? With this approach, all AJAX queries should be send using POST method.
When using POST XHR, you use a two-step process : sending the headers first and then the data, but you use Ajax for responsiveness, right ? So why use a two-step process when you can use a one-step process (GET XHR)?
Furthermore, AFAIK, GET request are cacheable, POST are not.
Last but not least, as some have pointed : HTTP verbs do have a meaning.
Keep on using GET XHR for getting datafrom server, and POST XHR for sending data.
Like you said, GET is not secure but it allows us to copy and paste links and get the same results. POST is more secure in the way it does not show the parameters directly, it still needs work on the backend to plug all the holes.
The key is not to forget why one is called "GET" and the other one "POST".
GET is accessible, so not good for anything sensitive, but easy to manipulate directly.
POST should be used to submit to the server side, sensitive or "lengthy" data.
This is only my opinion:
A savvy user who really wants to know what data is being posted will always be able to discover exactly what data is being transmitted during an http request. The only tool that you really need for this are the tools that are built into modern browsers. If you transmit using HTTPS, then a third party will be able to discern GET parameters, but not POST data, so I would say you are correct that sensitive data should only be sent as POST. Otherwise, as a security tool, POST over GET serves a similar function to a password mask on password inputs (prevent someone from looking at your data over your shoulder).
Now, to your question "Is GET better...?"
I would say that just like with synchronous http requests, you should use GET when the user or your application need to get data, and POST when your app of the user needs to post data (for persistence - in the session (like a login), or a database, etc). So it's really more of a semantic difference. Practically, you could use post for everything if you wanted to.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Client-side detection of HTTP request method
I'm working on Javascript that is injected on any page. The script is injected on servers that I'm not controlling. (Injection is done with an add-on or bookmarklet.)
The Javascript needs to know whether the page was loaded as the result of an HTTP GET or POST. The reason for this is that if the page was loaded with a GET, the URL is an identifier for the page that can be bookmarked, shared with others, etc. In case of a POST, I need to handle it differently.
Can this be done? I have found no way of accessing the request from Javascript, but perhaps there is some trick that I don't know of.
I think you can't.
Brendan Eich just confirmed that last night on his twitter, in a conversation with dhh.
Reproducing here:
#dhh: Is there any continued reason why JavaScript can't access HTTP headers in the browser outside of Ajax? And what's the historic reason?
#BrendanEich: #dhh #lostconvos no good reason -- I had no time in the old days (apart from document.cookie and navigator.userAgent), no one followed up.
#dhh: Could we just borrow the API from xhr: getResponseHeader() and getAllResponseHeaders()?
I suggest you follow both in case you are interested on this matter.
In the meantime, I think the best you can do is having two different javascripts - one for POST pages and another one for the rest. You give both to your providers and tell them how to use them. But yes, this involves cooperation from the servers.
It's not possible to directly retrieve the POST data of a webpage; Imagine that it's possible. Then, the sensitive data, submitted through a POST request can also be read, which is obviously not desired.
If you're writing an extension/userscript which has control over the generated HTML, you can append a query string to each form element with method=post. This method is only reliable if the POST requests are not scripted (AJAX), but initiated through a form.
Example code:
javascript:(function(){
var form = document.forms, i=form.length-1;
for(; i>=0; i--) {
if(/post/i.test(form[i].method)) form[i].action += "#method-post";
}
//check whether the hash contains `#method-post`
var is_post = location.hash.indexOf("#method-post") != -1;
//Optionally, remove the hash to not interfere with the scripts at the page:
//location.hash = location.hash.replace('#method-post', '');
})();
Location hashes are not submitted to the server, but passed by the browser. This solution works perfectly for extensions, but possibly inaccurate for bookmarklets, since the user should always activate it.