I am new to web development, and I guess that it is a basic issue, but I couldn't find a solution on the internet.
To start, what I am trying to do is to have a script, loaded on a webpage using TamperMonkey, download a xml file located on a php server.
The process worked perfectly when I tested it on localhost (using MAMP), but then I put it on a 000webhost server, and it's not working, I get an Error 400 Bad request in the ajax response. I also tried on other web hosting services and I get the same error.
On the other hand, the request works perfectly on the 000webhost server when I'm just sending it though my google chrome searchbar. Also, the url to which it is sent is well formed, as when I console.log it, and then click the link, it does what it should.
I am using the GM_xmlhttpRequest method. Here is the code :
let url = some_correct_url;
GM_xmlhttpRequest({
methode: "GET",
url: url,
headers: {
"Accept": "text/xml"
},
onload: function(response){
var r= null;
if (!response.responseXML){
r= new DOMParser().parseFromString(response.responseXML, "text/xml");
}
r= response.responseXML;
console.log(r);
console.log(response.responseText);
});
});
You have a typo in your request body.
Typo: methodE: "GET"
Please correct the typo so it reads method: "GET" and let us know the results.
I am working on an internal web application at work. In IE10 the requests work fine, but in Chrome all the AJAX requests (which there are many) are sent using OPTIONS instead of whatever defined method I give it. Technically my requests are "cross domain." The site is served on localhost:6120 and the service I'm making AJAX requests to is on 57124. This closed jquery bug defines the issue, but not a real fix.
What can I do to use the proper http method in ajax requests?
Edit:
This is in the document load of every page:
jQuery.support.cors = true;
And every AJAX is built similarly:
var url = 'http://localhost:57124/My/Rest/Call';
$.ajax({
url: url,
dataType: "json",
data: json,
async: true,
cache: false,
timeout: 30000,
headers: { "x-li-format": "json", "X-UserName": userName },
success: function (data) {
// my success stuff
},
error: function (request, status, error) {
// my error stuff
},
type: "POST"
});
Chrome is preflighting the request to look for CORS headers. If the request is acceptable, it will then send the real request. If you're doing this cross-domain, you will simply have to deal with it or else find a way to make the request non-cross-domain. This is why the jQuery bug was closed as won't-fix. This is by design.
Unlike simple requests (discussed above), "preflighted" requests first
send an HTTP request by the OPTIONS method to the resource on the
other domain, in order to determine whether the actual request is safe
to send. Cross-site requests are preflighted like this since they may
have implications to user data. In particular, a request is
preflighted if:
It uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than
application/x-www-form-urlencoded, multipart/form-data, or text/plain,
e.g. if the POST request sends an XML payload to the server using
application/xml or text/xml, then the request is preflighted.
It sets custom headers in the request (e.g. the request uses a header such as X-PINGOTHER)
Based on the fact that the request isn't sent on the default port 80/443 this Ajax call is automatically considered a cross-origin resource (CORS) request, which in other words means that the request automatically issues an OPTIONS request which checks for CORS headers on the server's/servlet's side.
This happens even if you set
crossOrigin: false;
or even if you ommit it.
The reason is simply that localhost != localhost:57124. Try sending it only to localhost without the port - it will fail, because the requested target won't be reachable, however notice that if the domain names are equal the request is sent without the OPTIONS request before POST.
I agree with Kevin B, the bug report says it all. It sounds like you are trying to make cross-domain ajax calls. If you're not familiar with the same origin policy you can start here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript.
If this is not intended to be a cross-domain ajax call, try making your target url relative and see if the problem goes away. If you're really desperate look into the JSONP, but beware, mayhem lurks. There really isn't much more we can do to help you.
If it is possible pass the params through regular GET/POST with a different name and let your server side code handles it.
I had a similar issue with my own proxy to bypass CORS and I got the same error of POST->OPTION in Chrome. It was the Authorization header in my case ("x-li-format" and "X-UserName" here in your case.) I ended up passing it in a dummy format (e.g. AuthorizatinJack in GET) and I changed the code for my proxy to turn that into a header when making the call to the destination. Here it is in PHP:
if (isset($_GET['AuthorizationJack'])) {
$request_headers[] = "Authorization: Basic ".$_GET['AuthorizationJack'];
}
In my case I'm calling an API hosted by AWS (API Gateway). The error happened when I tried to call the API from a domain other than the API own domain. Since I'm the API owner I enabled CORS for the test environment, as described in the Amazon Documentation.
In production this error will not happen, since the request and the api will be in the same domain.
I hope it helps!
As answered by #Dark Falcon, I simply dealt with it.
In my case, I am using node.js server, and creating a session if it does not exist. Since the OPTIONS method does not have the session details in it, it ended up creating a new session for every POST method request.
So in my app routine to create-session-if-not-exist, I just added a check to see if method is OPTIONS, and if so, just skip session creating part:
app.use(function(req, res, next) {
if (req.method !== "OPTIONS") {
if (req.session && req.session.id) {
// Session exists
next();
}else{
// Create session
next();
}
} else {
// If request method is OPTIONS, just skip this part and move to the next method.
next();
}
}
"preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Consider using axios
axios.get( url,
{ headers: {"Content-Type": "application/json"} } ).then( res => {
if(res.data.error) {
} else {
doAnything( res.data )
}
}).catch(function (error) {
doAnythingError(error)
});
I had this issue using fetch and axios worked perfectly.
I've encountered a very similar issue. I spent almost half a day to understand why everything works correctly in Firefox and fails in Chrome. In my case it was because of duplicated (or maybe mistyped) fields in my request header.
Use fetch instead of XHR,then the request will not be prelighted even it's cross-domained.
$.ajax({
url: '###',
contentType: 'text/plain; charset=utf-8',
async: false,
xhrFields: {
withCredentials: true,
crossDomain: true,
Authorization: "Bearer ...."
},
method: 'POST',
data: JSON.stringify( request ),
success: function (data) {
console.log(data);
}
});
the contentType: 'text/plain; charset=utf-8', or just contentType: 'text/plain', works for me!
regards!!
I am beginner in loopback and working on Get Post in loopback
This is code on client side
var datas = 'Something';
$.ajax({
type: 'POST',
url: '/post',
data: datas,
dataType: 'text'
})
.done(function(data) {
console.log('Successful');
.fail(function(jqXhr) {
console.log('Failed');
});
and this is on server side(server.js)
app.post('/post', function(req, res){
console.log('This is DATA '+ req.body);
});
This is not working it gives me 404 not found or failed.
What am I doing wrong and Is there another method for get post in loopback?
the server side needs an server and listening a port.
the client side needs to listen another port.
so they are not in one domain and cannot get access to each other.
this called a "cross-origin requests"
check this for the solution:https://www.w3.org/TR/cors/
Your URL starts with '/'.
Whenever a URL starts with '/' it is treated as absolute URL.
Whereas, most of the time, web apps are bounded with a context root.
Try using URL without initial '/' and it should work.
I have seen a couple of examples from stackoverflow itself and also in the extjs documentation. But all I can see is 404 error.
Ext.Ajax.request({
url: '/project-desktop-service/decisions.json',
method: 'post',
headers: {'Content-Type': 'application/json'},
params: {
rolename: 'rolename'
},
success: function(){console.log('success');},
failure: function(){console.log('failure');}
});
I also have tried different combinations of removing and adding the content type, adding absolute url etc. But the result is the same failure everytime.
from Wiki :
The 404 or Not Found error message is a HTTP standard response code indicating that
the client was able to communicate with the server,
but the server could not find what was requested.
the only thing is not function right is you URL or you request somthing that was not ther.
When accessing a localhost's protected CouchDB database via $.ajax, it prompts an alert asking for the username/password. If i cancel the prompt, CouchDB alerts an error and my $.ajax error callback is never executed. If i pass in an authorized user to the url (http://user:pass#local...), the success callback is executed properly.
So, is possible to make authenticated ajax queries to Couch and use my own error handling functions?
Edit, code:
var request = $.ajax({
url: myUrl,
type: "GET",
dataType: "jsonp",
success: function(){
console.log("ok");
},
error: function(){
console.log("error");
}
});
If myUrl does not include credentials, like http://localhost:5984/mydb/handshakeDoc, error callback is never executed after cancelling the prompt.
If myUrl include invalid credentials, like http://user:invalidpass#localhost:5984/mydb/handshakeDoc, error prompt still appears and error callback is never executed after cancelling the prompt.
If myUrl include valid credentials, success callback is executed
----- possible solution -----
So, I got a solution that worked for me. However I had to use apache as a Proxy server to circumvent the cross origin policy.
The idea here is to remove the problems with the cross domain policy and use an http-server to proxy our request locally to the couchdb service. Every request for example.com/couch will be redirected to the couchdb service. That way you don't have to use a jsonp request anymore.
The initial problem you asked about whether or not you can use your own error handling is directly linked to jsonp requests in jQuery as they do not use the error handlers - They never get called at all.
Apache configuration:
<VirtualHost 123.123.123.123:80>
ServerName example.com
ProxyPass /couch http://localhost:5984
ProxyPassReverse /couch http://localhost:5984
</VirtualHost>
jQuery ajax request:
var request = $.ajax({
url: "http://example.com/couch",
dataType: "json",
}).done(function() {console.log("done");})
.fail(function() {console.log("fail");})
.always(function() {console.log("always");});
});
----- Original post -----
You could try this:
var request = $.ajax({
url: myUrl,
type: "GET",
username: user,
password: pass,
dataType: "jsonp",
success: function(){
console.log("ok");
},
error: function(){
console.log("error");
}
});
jQuery gives you the possibility to use the http basic auth via two ajax parameters (username and password).
Or you might wanna try the CouchDB jQuery plugin.