I have implement autocomplete for search text box on my site.
it is working perfectly on all browsers.
But after production I got 404 error when I use Edge browser and samsung browser too.
But at same time on production it work perfectly with Chrome, Firefox, Brave and tor browsers
On edge I get this error in the console:
https://mysitedomainName/en/Home/ItemsMatchResultAjax **404**
In the browser development tools XHR I see the following:
Request URL: https://mysitedomainName/en/Home/ItemsMatchResultAjax
Request Method: POST
Status Code: 404
Remote Address: ip address:443
Referrer Policy: strict-origin-when-cross-origin
These errors do not appear in other browsers as mentioned above, it works perfectly!
Even in the development environment, when I use the same browsers such as Edge, it is working fine!
this is the signature of the action :
[HttpPost]
public async Task<JsonResult> ItemsMatchResultAjax(string strTag)
Any explanation that can help me in this situation?
Related
I am trying to use the Soundcloud API. I make a request backend which works fine. I get the track id and with that i call api.soundcloud.com/tracks/242264498/stream?client_id=[REMOVED]. That link works fine in both Chrome and Firefox. However, when using it with jQuery/HTML it seems to fail in Firefox.
Request:
$(".jukebox").prop("src", 'https://api.soundcloud.com/tracks/'+track_id+'/stream?client_id=2487d5f911c4c44f0882c063ec104332').trigger('play');
Response (ONLY Firefox):
GET https://ec-media.sndcdn.com/C21H6loBzYez.128.mp3 [HTTP/1.1 403 Forbidden 23ms]
Running this in Firefox console plays the track for less than 1 second. I can hear it "stutter". Then it gives the 403.
$(".jukebox").prop("src", 'https://api.soundcloud.com/tracks/'+242264498+'/stream?client_id=2487d5f911c4c44f0882c063ec104332').trigger('play');
The HTML looks like this:
<audio class="audio_file jukebox" controls preload="auto" data-volume="0.25"></audio>
Just tested your code. And it worked fine even in firefox too.
https://ec-media.sndcdn.com/C21H6loBzYez.128.mp3
This url will simply not work, it needs access token id and other GET parameters. If SoundCloud is redirecting you to this url (with no GET parameters such as access token id and any others) then it may be something with SoundCloud as its not a 'normal' behavior.
I suggest you to re-test your code as it worked fine for me.
I am trying to build an "app version" of my website (a social network).
I am using PhoneGap + jQuery Mobile (i started learning them today).
The app simply needs to retrieve new posts from the website and show them to the user. Therefore I thought a simple Ajax Request would do the job.
So, i created a php test file on the server (URL: http://www.racebooking.net/it/moto/app/get_post_test.php), which simply Echoes Alien contact SUCCESS!
I've made a simple html page in localhost (on my PC) called index.html with a div called #post-container and an AJAX request:
var root = "http://www.racebooking.net/it/moto"
$.get(root + "/app/get_post_test.php", function(data){
$("#posts-container").html(data);
});
If everything is correct, i expect to see Alien contact SUCCESS! in the post-content div.
What happens looks strange:
If i run the app from eclipse using Genymotion, everything works fine
and i see the message Alien contact SUCCESS! -> the AJAX request
went fine
If i open the index.html file on firefox, i don't see anything
and FireBug informs me that the cross-origin request was blocked.
He also tells me to activate CORS.
1) Why is that happening and how can i make FireBug work (which is better and faster for debugging)?
2) Am i following the right procedure or i am missing something?
I found the solution from this post.
I just needed to add header('Access-Control-Allow-Origin: *'); at the top of my php file.
The main problem about Access-Control-Allow-Origin I think. But when I configure the Web API project as defined in the given documentation, it still not working in chrome and firefox but working in IE well (it is about IE thinks localhost is not cross domain, AFAIK). I tried different ways to make it work but no result.
I put the example project to github repository. Project is very simple. There are two applications working on cross domains. It is very simple chat application like in signalr examples.
You must change the value of api host in client javascript file:
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApp/Scripts/app/chat.js#L2
When you open the Chat page in mvc project, there will be two requests to api application
1- Regular ajax request (which is working fine)
2- Signalr negotiate request (cancelled)
And also I don't think browser disables the CORS because of if it disables there would not be an hit to server. So I think it is about browser but not about browser disables (something else).
Details are in repository
Readme: https://github.com/yusufuzun/WebApiSignalR/blob/master/README.md
Fiddler Results: https://github.com/yusufuzun/WebApiSignalR/blob/master/FiddlerResults
The bad part about it also is server returning 500 with this error:
System.InvalidOperationException: 'chat' Hub could not be resolved.
Which hub name is chat also.
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Hubs/ChatHub.cs#L10
You can enable CORS for Web Api in project with different ways for test purposes. Each one is giving different errors all about XMLHttpRequest Access-Control-Allow-Origin.
I commented them, so you can uncomment and make test for each one:
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Global.asax.cs#L24
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/App_Start/WebApiConfig.cs#L14
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/App_Start/WebApiConfig.cs#L16
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Controllers/ChatController.cs#L17
So what is going on here?
After I talked with David Fowler in JabbR, he mentioned the thing about using CORS with SignalR. My signalr startup code was wrong. So after changing the startup code like in his advice it worked well.
He also mentioned SignalR and Web API are working with different CORS definitions. So enabling or disabling one doesn't affect other.
Here is the new startup code:
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
map.RunSignalR(new HubConfiguration()
{
EnableDetailedErrors = true,
EnableJavaScriptProxies = true
});
});
The old one:
app.MapSignalR(new HubConfiguration()
{
EnableDetailedErrors = true,
EnableJavaScriptProxies = true
}).UseCors(CorsOptions.AllowAll);
Hope it helps to somebody out there.
I'm having issues with using $http on ie8. The request does not reach the server, until I hit a refresh. Coming back to the same link still has the same problem until I hit refresh again.
The weird thing is if the web server is on LAN and the request is made to a server in LAN, it works fine. But if the webserver is hosted remotely, it does not work!
Here is the code:
Index.html
{{test}}
Controller
app.controller(
"TestController",
function( $scope, $http) {
var url = '/test/get_data';
$http.get(url).success(function(data) {
$scope.test = data;
});
}
);
I got this error: TypeError: Object doesn't support this property or methodundefined
I prepared a JSFiddle earlier but JSFiddle is broken in ie8 so I don't provide it here.
Unfortunately I don't have a remote server that I can share with you.
Edit
Previously I used an external url which gave me 'Access Denied' error in ie because of Same Origin Policy as mentioned by one answer below. But this was not my original problem. I still have the issue above when request is from the same origin
This is a cross domain request, which is not allowed in ajax because of Same Origin Policy.
There are two solutions for this
1. JSONP: It is a cross browser way to handle cross domain ajax requests using javascript callback mechanism
2. CORS: It is a HTML5 standard, it is implemented by most of the modern browsers except IE
Mongodb lab is not supporting jsonp since it has support for CORS, that is why your request is failing in IE and works in Chrome and other browsers.
As per this post they do not have any plan to support jsonp, so I don't thick there is a way to make this work in IE.
So I found the fix... Hope this helps anyone out there that experience this problem
Angular script needs to be loaded after jQuery. I didn't have this because Yii framework that I use autoloads jQuery and the angular was not included after the jQuery.
All the controller functions need to be at the end of body section (just before the closing )
Updating to angular 1.0.5 seems to fix the problem. The problem occurred in 1.0.4 with all the above tricks. I think is related to fix 791804bd
I have code that uses Microsoft's XDomainRequest object in IE8. The code looks like this:
var url = "http://<host>/api/acquire?<query string>";
var xdr = new XDomainRequest();
xdr.onload = function(){
$.("#identifier").text(xdr.responseText);
};
xdr.open("GET", url);
xdr.send();
When the scheme in "url" is "http://" the command works fine. However, when the scheme is "https://" IE8 gives me an "Access denied" JavaScript error. Both schemes work fine in FF 3.6.3, where I am, of course, using XmlHttpRequest. With both browsers I am complying with W3C Access Control. "http://" works cross origin for both browsers. So the problem is with IE8, XDomainRequest, and SSL.
The SSL certificate is not the problem. If I type https://<host>/ into the address bar of IE8, where <host> is the same as in "url" above, the page loads fine.
So we have the following:
- hitting https://<host>/ directly from the browser works fine;
- hitting https://<host>/api/acquire?<query string> via XDomainRequest is not allowed.
Can it be done? Am I leaving something out?
Apparently, the answer is here: Link
Point 7 on this page says, "Requests must be targeted to the same scheme as the hosting page."
Here is some of the supporting text for point 7:
"It was definitely our intent to prevent HTTPS pages from making
XDomainRequests for HTTP-based resources, as that scenario presents a
Mixed Content Security Threat which many developers and most users do
not understand.
However, this restriction is overly broad, because it prevents HTTP
pages from issuing XDomainRequests targeted to HTTPS pages. While it’s
true that the HTTP page itself may have been compromised, there’s no
reason that it should be forbidden from receiving public resources
securely."
It would appear at present that the answer to my original question is: YES, if the hosting page can use the "https://" scheme; NO, if it cannot.