I am using SignalR Persistent Connections with Cross-Domain support and I am able to successfully start a connection, however when I send data from client to server, the server OnReceived method gets invoked, however the data field is always null.
I have traced into SignalR client script and there is valid data at client send time.
Has anyone experienced this ?
I resolved the issue. The resolution has nothing to do with the environment being cross-domain. It seems that SignalR assumes that the jQuery $.ajaxSetup defaults are consistent with what SignalR needs, which is a bad assumption....so I had to reset the Ajax defaults prior to using SignalR....
$.ajaxSetup({
processData: true,
contentType: "application/x-www-form-urlencoded; charset=UTF-8",
dataType: "text"
});
Related
When I run this code on client side instead of server it returns the error. If it is run on the server it works fine. I'm using meteor. I'm struggling to find a solution online. Can someone explain what I'm doing wrong here?
Path: Code on client
googleMapsClient.geocode({
address: 'My test address'
}, function(err, response) {
if (!err) {
console.log(response.json.results);
}
});
Error: in console
Failed to load https://maps.googleapis.com/maps/api/geocode/json?address=Test%20address&key=MYKEY: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'http://localhost:3000' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
This seems to be answered by the author of the library here. It's a good idea to first go through the github issues for a given library in order to find common mistakes. The idea is that the library is supposed to be used on the server side, for the client side use you would use google's API.
As stated in the title, i would like to know what happens when an AJAX request is sent to a controller action and, during this time, a network timeout happens for a few ms before the request is completed.
Reply from <Server IP>: bytes=32 time=31ms TTL=122
Request timed out
Reply from <Server IP>: bytes=32 time=28ms TTL=122
Considering the timeout happens only for a couple of ms, what effects would this have on my AJAX request?
This is in continuation to a problem we are facing in our application as explained in this SO question and i would like to know if they are somehow related.
I have googled for similar issues but couldn't find anything useful.
Edit: Apart from the impact on AJAX, would it affect the action method's behavior (server)?
Regardless of whether the timeout happens only for a couple of ms or more, the request will fail. The success callback function of your AJAX request will not be executed and the request will end with the execution of complete callback function. By default, all AJAX requests will have a timeout of 0ms (unlimited), but it will hit the default timeout of the browser.
When an AJAX request times out, the error callback function will be invoked. The second argument of this function is a string describing the type of error and in this case, it will have the value timeout. You can handle request timeouts by handling this callback function and by optionally specifying a timeout value (if not specified, works on the default value) in the AJAX request body:
$.ajax({
...
timeout: 5000, //specify the timeout value in milliseconds
error: function(jqXHR, textStatus, errorThrown) {
if(textStatus==="timeout") {
//code to execute when timeout occurs
}
}
});
Additionally, you can also check if the request has timed out in the complete callback function (in a similar way as shown above) by checking the second argument which is a string and it will have the value timeout if the request was timed out.
Also, note this:
The timeout period starts at the point the $.ajax call is made; if several other requests are in progress and the browser has no connections available, it is possible for a request to time out before it can be sent.
Request timeouts are usually either left at their default or set as a global default using $.ajaxSetup() rather than being overridden for specific requests with the timeout option.
I would suggest you to use an alternative HTTP/s traffic monitoring tool like fiddler to find the mystery behind the second request.
More info: jQuery ajax documentation
The request will "fail", meaning it will enter the onError state of your AJAX request. The status code will then be 0, since there is no response from the server to determine the real status code (eg. 200 OK or 500 Internal Server Error).
In case of time-out your success callback wont execute so you have to write an error callback at the client side to handle such issues.
You have to raise an exception from server side in case of time-out so that it will get back to the client as an error that is the one way you can handle the time-out.
In my Meteor (1.2) application, I make a client-side HTTP.get call over https to a remote server supporting CORS.
var getUrl= "https://remoteserver/;
HTTP.call('GET', getUrl , {}, function (error, response) {
console.log (response);
}
Now, the issue is that set-cookie string is present in HTTP headers of the response of such HTTP call in Chrome's DevTools' Network tab.
However when I call console.log (response) , they're not included. Actually only these 3 properties are printed in response['headers']:
Content-Type
cache-control
last-modified
Digging more in, I found out on Meteor Docs that
Cookies are deliberately excluded from the headers as they are a security risk for this transport. For details and alternatives, see the SockJS documentation.
Now, on the linked SockJS docs, it says that
Basically - cookies are not suited for SockJS model. If you want to authorise a session - provide a unique token on a page, send it as a first thing over SockJS connection and validate it on the server side. In essence, this is how cookies work.
I found this this answer about sockJS but it looks outdated an not specific to Meteor.
The remote server expects me to use cookie-set header, so I have no choice. Also, for established scalability reasons, the HTTP.call must be done client-side (server-side was not an issue at all)
What solution / workaround can I adopt?
This package looks to be designed to help in situations like this, though I have not used it:
https://atmospherejs.com/dandv/http-more
I have an asp.net MVC3 application that makes Ajax calls to the server on various occassion. We have a debate in our team on how to handle error response:
Option 1: Use HTTP status code to return back an error response, and have the ajax failure handler bind to the function that needs to be called on error.
Option 2: Use a header/payload concept using JSON, with a structure similar to
response:
success: true
text: <status text>
....
payload: <actual response>
The argument for first is - why not reuse the mechanism provided by HTTP and Ajax.
The argument for second is - Let alone the onFailure ajax handler to deal with 'genuine' http errors (e.g caused by network failure etc..) and have a uniform contract between the client and server for application's success and error response. Parse the response to get failure/success and status text.
Thoughts on both approaches are welcome. Thanks.
I would go with the first approach. The HTTP protocol already provides all the mechanisms, so why does each developer should reinvent error handling everytime? If you return 200 status code intermediaries such as proxy servers has no way of knowing that this response should not be cached.
I've been looking for an example of a 1.1 web service getting called using jQuery. I'd like to call a web service and pass a few parameters to it.
Can someone point me in the right direction?
Thanks!
Without more details on the web service, the generic answer is "use an AJAX call". The example below sends data in a JSON format, and retrieves JSON data back.
$.ajax({
type: "POST",
url: "theWebServiceURL",
data: {'key1':'value1','key2':'value2'},
dataType: /* depends on the return of the web service */,
success: function(data) { /* do stuff here */ };
});
There are some peculiarities sometimes on sending the data, if you need to send data.
UPDATE: Given John Saunder's post, I thought I'd expand on the last sentence. ASP.NET v1.1 accepts (by default) HTTP GET, HTTP POST or HTTP SOAP. What one particular web service is set to accept basically dictates how the whole AJAX request must be sent to the web service. Using jQuery, you are mainly going to go to HTTP GET or HTTP POST. (Unless you get fancy and set processData: false. You then create and send your SOAP-formatted (XML) data and set content-type to text/xml, but I've never done this, so I am unsure of the details.)
Just following up on this in case anyone else needs it in the future. I was able to call the 1.1 web service by using the ajax method and a POST:
$.ajax({
type: "POST",
url: 'PathToYourService.asmx/FunctionName',
data: 'foo1=value1&foo2=value&foo3=value',
dataType: "xml",
success: function(xml) {
//do something with your data
}
});
I don't believe that .NET 1.1 Web Services suppoted JSON. That's stuff from back around 2002 or 2003. You'll have to use SOAP, or else upgrade, preferably to .NET 3.5 SP1 (the current release).
Here's a solid set to get you started:
For specific ASP examples, see Using jQuery to directly call ASP.NET AJAX page methods
For details on various ways you can make calls, check out the jQuery AJAX documentation.
To monitor your calls and responses, consider using something like Firebug for Firefox
You also want to review 3 mistakes to avoid when using jQuery with ASP.NET AJAX
Good luck! M