I'm using AFNetworking 2.0 to receive response from server. For first response, it works fine. However, after I change the data on the admin site, and verify that the change is made in a browser, then I run the app again, but I still get the previous response. I don't understand why? It seems that AFNetworking is caching the old response. I want to download the current feed. Who can help me, please????
I had the exact opposite problem. I was getting the same image from my server twice, AFNetworking wasn't caching. As I debugged it I realized that I was calling 2 slightly different URLs, in one case I was specifying an option that was the default on the server.
So this gave me the idea for a work around hack for you. It isn't the right answer but it should work. Just pass a useless parameter to the server. Change this parameter for each server call.
https://example.com/myrequest?index=0
then
https://example.com/myrequest?index=1
where index is the unused parameter.
Note: this is actually a pretty gross hack, it should get you running but you really should find the "correct" answer.
Related
i cant verify my webapp using maven-failsave because the web-jetty.xml referenced a missing dtd (http://jetty.mortbay.org/configure.dtd).
Any ideas? Can i disable the dtd-check?
Where can i get the content of http://jetty.mortbay.org/configure.dtd?
old one should work, I'll look into that, but you can also get it at:
http://www.eclipse.org/jetty/configure.dtd
[edit] An update on this:
We have a number of redirects in place as we try and keep the really old xml file doctypes valid. We recently wired up a redirect from jetty.codehaus.org to www.eclipse.org/jetty which has resulted in a number of validation errors on these old urls. This is being addressed but if it impacts you updating to www.eclipse.org/jetty/configure.dtd is the best solution so the redirect game is no longer played.
I found the source of my problem for SuperAgent (http://visionmedia.github.com/superagent/) on Firefox. Not sure if SuperAgent is doing it in its AJAX call or if FireFox is triggering it.
Essentially, every time I make an AJAX call an OPTIONS method is being fired on the URL before the actual AJAX call. Quite annoying since the server currently doesn't support OPTIONS. How can I make a call without it going to crap and re-coding the server?
Thanks
Ok found out some more details. Thankfully testing on Safari gave me more insight into what was actually happening and I applied my knowledge here.
It seems to be the standard that browsers are calling an OPTIONS method before making an actual AJAX call. Seems a bit overbearing.
So to get around it I simply added a catch-all in my reverse proxy server to handle each OPTIONS call. You can see the question below for the code:
Play! 2.0 easy fix to OPTIONS response for router catch-all?
And if you want to read up more on why browsers are doing this, see here:
Why am I getting an OPTIONS request instead of a GET request?
OPTIONS is from the CORS standard.
Disabling web-secuty in phantomjs also helped to resolve this problem (--web-security=no). Because I didn't have access to API server to make changes for OPTION method.
There are several topics about the problem with cross-domain AJAX. I've been looking at these and the conclusion seems to be this:
Apart from using somthing like JSONP, or a proxy sollution, you should not be able to do a basic jquery $.post() to another domain
My test code looks something like this (running on "http://myTestdomain.tld/path/file.html")
var myData = {datum1 : "datum", datum2: "datum"}
$.post("http://External-Ip:port", myData,function(return){alert(return);});
When I tried this (the reason I started looking), chrome-console told me:
XMLHttpRequest cannot load
http://External-IP:port/page.php. Origin
http://myTestdomain.tld is not allowed
by Access-Control-Allow-Origin.
Now this is, as far as I can tell, expected. I should not be able to do this. The problem is that the POST actually DOES come trough. I've got a simple script running that saves the $_POST to a file, and it is clear the post gets trough. Any real data I return is not delivered to my calling script, which again seems expected because of the Access-control issue. But the fact that the post actually arrived at the server got me confused.
Is it correct that I assume that above code running on "myTestdomain" should not be able to do a simple $.post() to the other domain (External-IP)?
Is it expected that the request would actually arrive at the external-ip's script, even though output is not received? or is this a bug. (I'm using Chrome 11.0.696.60 )
I posted a ticket about this on the WebKit bugtracker earlier, since I thought it was weird behaviour and possibly a security risk.
Since security-related tickets aren't publicly viewable, I'll quote the reply from Justin Schuh here:
This is implemented exactly as required by the spec. For simple cross-origin requests http://www.w3.org/TR/cors/#simple-method> there is no pre-flight check; the request is made and the response cannot be read if the appropriate headers do not authorize the requesting origin. Functionally, this is no different than creating a form and using script to make an off-origin POST (which has always been possible).
So: you're allowed to do the POST since you could have done that anyway by embedding a form and triggering the submit button with javascript, but you can't see the result. Because you wouldn't be able to do that in the form scenario.
A solution would be to add a header to the script running on the target server, e.g.
<?php
header("Access-Control-Allow-Origin: http://your_source_domain");
....
?>
Haven't tested that, but according to the spec, that should work.
Firefox 3.6 seems to handle it differently, by first doing an OPTIONS to see whether or not it can do the actual POST. Firefox 4 does the same thing Chrome does, or at least it did in my quick experiment. More about that is on https://developer.mozilla.org/en/http_access_control
The important thing to note about the JavaScript same-origin policy restriction is that it is something built into modern browsers for security - it is not a limitation of the technology or something enforced by servers.
To answer your question, neither of these are bugs.
Requests are not stopped from reaching the server - this gives the server the option to allow these cross-domain requests by setting the appropriate headers1.
The response is also received back by the browser. Before the use of the access control headers 1, responses to cross-domain requests would be stopped dead in their tracks by a security conscious browser - the browser would receive the response but it would not hand it off to the script. With the access control headers, the server has the option of setting the appropriate headers indicating to a compliant browser that it would like to allow certain origin URLs to make cross domain requests.
The exact behaviour on response might differ between browsers - I can't recall for sure now but I think Chrome calls the success callback function when using jQuery's ajax() but the response is empty. IIRC, Firefox will not invoke the success function.
I get the same thing happening for me. You are able to post across domains but are not able to receive a response. This is what I expected to be able to do and happens for me in Firefox, Chrome, and IE.
One way to kind of get around this caveat is having a local php file with will call the data via curl and respond the response to your javascript. (Kind of restated what you said you knew already.)
Yes, it's correct and you won't be able to do that unless you use any proxy.
No, request won't go to the external IP as soon as there is such limitation.
I want to change the settings of firefox so as to allow it to make cross domain ajax calls. Since due to the security feature of the firefox it doen't allow ajax calls to be made. I know if it is in same domain it will allow. I have a code given bellow which in safari works fine but firefox doesn't display the results when it calls csce server then since the code is on local machine doesn't allow it and returns error. I know it will start working if I load my this code to csce server but I want to run the code from my machine. So can anyone help me in resolving this. I have spent past couple of days just searching for this solution.
Kindly suggest how to achieve this or should I go with some older version of firefox?
I googled and set the parameters of browser in config file as specified in this site but it still doesn't work.
http://code.google.com/p/httpfox/issues/detail?id=20
Maybe you could use privoxy and tell it to inject something like "Access-Control-Allow-Origin: *" in the server response.
To do this, you would have to go into the file user.filter (create it if it doesn't exist) in privoxys configuration directory and insert something like this:
SERVER-HEADER-FILTER: allow-crossdomain
s|Server: .*|Access-Control-Allow-Origin: *|
Instead of Server, you can also use any other header that's always present and you don't need.
And this into user.action:
{+server-header-filter{allow-crossdomain}}
csce.unl.edu
Note: I didn't test it.
https://developer.mozilla.org/En/HTTP_access_control
http://config.privoxy.org/user-manual/
This appears to enable XSS from file:// pages in Firefox 4, although it prompts you so might not be suitable for more than simple test pages:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
I have an app that I'm creating with CakePHP, which rewrites the url from something illegible to most users to something a little easier to comprehend. I'm having a problem when I use the FBML canvas.
When I try to access, say, http://apps.facebook.com/myapp/articles, I get the following error:
Received HTTP error code 404 while
loading
http://www.myapp.com/myapparticles/
I did notice that when I try to access http://apps.facebook.com/myapp/articles/posts, it changes the error to show the following url, which is slightly different: http://www.myapp.com/myapparticles/posts
Which lead me to try accessing it with this: http://apps.facebook.com/myapp//articles, which does work most of the time, though for some reason sometimes it will give the previous error. (And it also seems like a hack-y way of getting it to work).
I'm at a loss for how to fix this.
Turns out I was missing the trailing slash (http://www.myapp.com/myapp/) on the url that I specified as my canvas callback, which is in the app settings. Putting it there fixes the problem.
This happens when you are not using semantic markup or you have an error or some code not supported by fb. Also that famous error is generated by fb when it is down or slow too.
I would suggest you checking your code thoroughly and going through fb documentation. That should help you the most. thanks