What could potentially stop an AJAX call from working on the host server, when it works fine on the local host? I tried returning an error from the AJAX call, but all I get is 'undefined'. I don't think the actual page method is being called since no information is added in my log (and I've explicitly added a call). I can't reproduce the problem on my local machine, so does anyone know possible areas I should look into?
Thanks
What URL is in your Browser, and What URL is your Ajax call hitting? Browsers have 'security' constraints that don't allow cross domain AJAX calls. So for instance, if I am loading a local file:
http://localhost:20080/myCustomPage.html
and within that page, I make an ajax call to
http://search.twitter.com/search?q=test
I would get a security warning from the browser. Depending on your browser this may manifest itself in a warning icon in the bottom corner (IE), or an error in the javascript log (firefox).
There is a way to get around this in ONE specific case. That case being any GET request. To do this instead of making an 'ajax' call you include a tag. That script tag will then be read and loaded. The catch here, is the call now needs to include a "callback" method, that you can implement on your side, that gets called with the result of the call.
So instead of a response like:
{
"first_name": "peter",
"last_name": "parker"
}
you would need to return
myCallBackFunction({
"first_name": "peter",
"last_name": "parker"
});
This example is using JSON, but you could easily use XML, HTML or any other result format as long as the function is called.
myCallbackFunction("INSERT RESPONSE TEXT HERE")
This method is commonly refereed to as JSONP and is fortunately implemented in the common javascript libraries like jquery from the client perspective. If you control the server side, you will need to hard code a callBackFunction wrapper, or expose a parameter that allows the client to set it. And unfortunately if you don't own the library there isn't much you can do unless the owner of the service already provides that feature. Fortunately most Web 2.0 services you would be doing stuff like this, already implement that feature.
I've managed to fix it. There was an issue with running IIS7 in integrated mode. I moved all my modules from to and my to (also in the section)
Hope that helps anyone else.
More info
Related
Regarding this question and also many documents have stated that sending a PUT request directly via form in browser is impossible due to security reason.
However, What I am seeing in Backbone is that it could still send a direct PUT request via browser without a workaround like adding a hidden form field.
And they're confusing to me. Is there anything that I'm missing here?
A form can only send a GET or a POST request, as set in the method attribute.
However, Backbone delegates its requests to jQuery.ajax by default (or whatever you want via Backbone.ajax) which itself wraps XMLHttpRequest, an object that can send PUT/DELETE/PATCH requests.
From https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
XMLHttpRequest is a JavaScript object that was designed by Microsoft
and adopted by Mozilla, Apple, and Google. It's now being standardized
in the W3C. It provides an easy way to retrieve data from a URL
without having to do a full page refresh. A Web page can update just a
part of the page without disrupting what the user is doing.
XMLHttpRequest is used heavily in AJAX programming.
many documents have stated that sending a PUT request directly via browser is impossible due to security reason
Citation please.
Backbone sends a PUT just like it sends any other request, with jQuery,
Backbone.ajax({
type: 'PUT'
...
});
It is just some server side langauges,like PHP, that have problems with receiving a PUT request.
The hidden form field is used when posting from a <form>. Backbone uses javascript.
Currently I'm working on a jQuery Mobile website which will later be transformed into an app via Titanium. I have created a RESTful JSON web service, which is running on a different server than the jQuery Mobile application. The web service is consumed via AJAX using JSONP.
One thing I find annoying is that I can't make use of HTTP error codes, because jQuery automatically aborts a JSONP call whenever the server issues an error. I can never get hold of the error code on the client side.
Another thing is that JSONP only works with the HTTP verb GET, you cannot issue a JSONP POST for example (Currently, the web service is GET only, but that could change).
Are there any alternatives to JSONP? Or is JSONP the only choice I have when using remote JSON web services with AJAX? For example, how do Twitter apps interact with the Twitter API (they have a REST API)?
Your question is a nice illustration why people complain that jquery is too easy to adopt ;)
JSONP is not ajax. There are no success and failure callbacks. JSONP is this:
put the parameters in the url
add &jsoncallback=random2745273
create a global variable random2745273 and put the callback reference in it
add <script src="theurlhere"></script> to the head
that's all you can do.
The server returns
random2745273({somedata});
and that's how your callback is called.
If you want to report errors, then your server has to generate a correct code. You will not know what HTTP headers were sent.
And this is the only way you can communicate cross-domain with an api.
Sending cross-domain communicates is also possible with generating iframes, but it's hacky and rarely used.
[edit]
Ok, that got me thinking... I could use the iframe hack to wrap over the JSONP!
And as usual - I wasn't the first to have the idea (and I'm finally humble enough to google my ideas expecting it ;) )
Here it is: http://beebole.com/en/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/
awesome
[edit2]
awww, I forgot... There's another one.
window.postMessage
It already got implemented in some browsers. If you don't have to be compatible with most of the browsers, you can start using it now! :)
After some more research on postMessage I found an alternative to JSONP: AJAX via Cross-domain messaging with EasyXDM.
See http://easyxdm.net/wp/2010/03/17/cross-domain-ajax/
I want to be able to send a simple http post from my firefox extension to my ASP.NET application. From the client side, I have used XMLHTTPRequest by sending the post with the url: http://localhost:15227 which is the url on my ASP.NET app.
What do I need to do to receive a remote request from ASP.NET please?
thanks
This page from Apple has a pretty good example of how to send/receive data using a raw XmlHttpReqeust object (as opposed to a JavaScript library).
You can get the value of the response from the responseText property once you know the response came back successfully. Specifically take a look at where the processReqChange function is defined, your code will go in there (or your equivalent of that function).
If you want to explore JavaScript frameworks, take a look at how much less code you need if you use jQuery get (for example).
I am adding headers to a page as follows:
Page.Response.AddHeader("foo", "bar");
Depending upon previous processing, sometimes this fails with "Server cannot append header after HTTP headers have been sent." I am dealing with this by enclosing Page.Response.AddHeader("foo", "bar"); within a try-catch construct. However, to keep things cleaner and avoid generating an exception is there any way to detect that the headers have already been sent? (btw if I try evaluating Page.Response.Headers then I get the following error: "This operation requires IIS integrated pipeline mode")
Thanks
As of .NET 4.5.2, you can do this using the now-public HeadersWritten property of HttpResponse (see the msdn docs):
if (HttpContext.Current.Response.HeadersWritten) { ... }
You can use an HttpModule to register for the PreSendRequestHeaders event. When it gets called, write a value to HttpContext.Current.Items indicating that the headers are being sent – and then everywhere else in your code you check the value in HttpContext.Current.Items to see if its been sent yet.
UPDATE: the HeadersWritten property is now available on the HttpResponse object.
Unfortunately, whilst the HttpResponse object has a property called HeadersWritten, and a backing field called _headersWritten, neither of these are accessible from outside of the System.Web assembly - unless you use Reflection. I'm not clear what you think you'll be able to obtain from the Headers collection, it may or may not exist, independently of whether the headers have been sent yet.
If you want to use Reflection, it may have it's own performance penalties, and it will require your application to run in full trust.
All of the publicly accessible methods on HttpResponse that involve the _headersWritten field seem to use it to throw an exception.
Trying setting buffer to false:
http://msdn.microsoft.com/en-us/library/950xf363.aspx
This will alleviate your first problem but your perfromance and user experience can suffer.
Also "This operation requires IIS integrated pipeline mode" is related to non-IIS 7 server processing that line of code. You can find more info on it here:
http://forums.asp.net/p/1253457/2323117.aspx
I have a situation where we're aggregating what amounts to marketing data from N number of clients, where a client can host a HTML form using any backend of their choice, each with the action of the form pointing to a path that we're hosting. Each client has a different URL, there's no auth (but there is some simple validation of the data) and it's all generally working just fine.
However, there's one small wrinkle that I can't seem to get my head around.
The aspx that is processing the submitted data resides at a path, let's call it ~/submit/default.aspx. The idea is that we should be able to hand to our partner a URL along the lines of "http://sample.com/submit/?foo=bar" as the action of their form. Doing this however results in a HTTP 405 error, "Resource not allowed".
Having the action of the form set as "http://sample.com/submit/default.aspx" works just fine and dandy however.
Default.aspx is set as one of the default document names in IIS 6.
The .aspx file extension is properly mapped to the correct .Net dll and has the verbs GET, HEAd, POST, and DEBUG activated for the mapping.
Those were the only two things I could think of to double check first--anyone else have any ideas? I'd have preferred to use URL rewriting / routing with IIS7, but that's unfortunately not an option--and I have a number of additional requirements where "clean" URLs will highly be preferable, so solving this problem is going to be a pretty core problem to get through.
IIRC, IIS will only use the default docs if the requested resource is a directory. Since the requested resource in the first case is not, it'll never make it through the default doc handlers - instead failing on a POST to an unregistered script extension (405).
it may depend on the document type of "http://sample.com/submit/?foo=bar"... if you IIS doesn't know how to handle the document type being returned to it (which then returns it to you, the client), then you may get an http 405 error - which means that it doesn't know how to handle that document type, server-wise. Maybe try putting something like
in your web.config file that drives the app. HTTP Handlers are modular pieces of code, written and compiled in a .net language, and act as kind of a 'servlet' if you're familiar with Java terms. It's a piece of code that writes out something to the client -- in your case maybe a rendering of a .doc file, found programmatically in your handler class.
for some reason, it didn't render my code sample!! you guys need to decode and encode less than and greater than signs for your "Your Answer" text box.... anyways,
<httpHandlers>
<add verb="your.class.to.handle.doc.files"/>
</httpHandlers>
is what should be in your web.config file.