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
Related
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.
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.
So basically I am trying to debug my routes, because they are not working as intended, but when using the profiler, I can see the URI string, which is basically the second part of URL in the browser address bar and CLASS/METHOD which are always of the 404 page that I am being redirected to. So how can I get the primary routes Class, Method and arguments/parameters that were attempted to run before being sent to 404?
E.g.
$route['en/catalog/(.+)/(.+)'] = "ccatalog/index/$1/$2";
something's gone wrong and I get redirected to the 404, but I want to see which class (most likely "ccatalog" here), which method (hopefully "index") and arguments ($1, $2).
Thank you in advance to anyone who could help me with my problem!
I don't see a reason for your route to not work.
Check by directly opening your_path/ccatalog/index/whatever/whatever in the browser.
If it gives you a 404, it means the problem is with your controller, maybe the controller or function naming.
If it is working fine, then you may be able to use a pre_system hook to figure out the parameter values.
You may also consider hacking around with Routing files in the core(making sure you change them back), to figure out what the real issue is.
Actually, this was done really easy:
$this->uri->rsegment(1);
I just spent several hours of my life debugging this problem. I'm documenting it here for others.
Question:
I'm getting the following error when I try to click on an AjaxLink in Internet Explorer:
Wicket: ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Object required
It works fine in all other browsers; just IE is busted.
Check to make sure that your HTML is 100% syntactically correct. Ajax responses are returned to the browser inside a CDATA section, and if the payload is not well-formed, IE will sometimes choke.
In my case I neglected to close a <link> tag in the <head> section. Simply closing that link tag made all the difference.
Aside: if you ever come across a tough-to-solve problem in Wicket, it's a good idea to create a quickstart project that reproduces your issue. It can be a lot of work to boil things down, but in doing so you often find the source of the problem.
I want to note one more potential reason for the issue with Wicket's AJAX in IE. It might help someone, who encounters similar problem.
In my case I had the following error message in IE:
Wicket: ERROR: Wicket.Ajax.Call.failure: Error while parsing response: could not find root <ajax-response> element
The reason was an incorrect Content-Type of AJAX response. I used AbstractTransformerBehavior and there was a bug in Wicket 1.4.x so this behavior was rewriting response Content-Type with text/html. IE does not parse such response as XML.
I'm using script which is uploading files to server via flash component. Sometimes, very rarely, when trying to upload images via Firefox I get following error: IO error #2038. Searching on the net I could find reason why is it really happening to me. But I found solution for my case:
I open IE6, do the same thing there (photos are always uploaded without problem) and the when I try again in Firefox problem disappears. If someone had similar problems maybe this could help or maybe this hint could help to someone discovering cause of the problem :)
I just had this error also using ASP.Net MVC and I discovered I just had my handler namespace wrong/missspellled in the web config section where the handlers go. HTH...
After far more time than I'd like to admit, here is the solution. Change the following variables in your php.ini to be large enough to handle your largest file:
; Maximum size of POST data that PHP will accept.
post_max_size = 32M
; Maximum allowed size for uploaded files.
upload_max_filesize = 32M
; Whether to allow HTTP file uploads. (this is on by default)
file_uploads = On
Since files are sent as POST data, both the first variables need to be set. Otherwise, there will be an error, but you won't see what the error is, except IO error #2038.
If you didn't add quote around the option names, try doing that. Sometimes in IE, quoting the option names fixes the issue. It would help if you posted some example code though.
Also make sure that the path to the server being used by the upload component is correct. If the path is a relative path, try to fully qualify it. IE can do some "magic" with relative paths that the other browsers cannot do, and sometimes trying the code from one browser to the other can tweak things.
Also, could be permissions...and having IE go there first could manipulate the permissions in a way that the other browser(s) then work "correctly".
I solved the problem.
In my office I use a proxy and I must change the settings to No Proxy.
Or if you do not use proxy, try to change in php.ini:
Hostname:Port localhost:0
to:
Hostname:Port localhost:80