I am hosting my pages on my doamain. I put the following info. When I go to view the app it shows 405 Method Not Allowed..Not sure what I am doing wrong.
*
The first page load a APP makes is a POST request.
Seems your server could be rejecting them.
Its worth checking the server side error log for further information.
Indeed, it will most probably be a setting on your server. I had the same problem, my server didn't allow POST method on .html pages, changed my canvas page source to .php and all works fine now.
If you can look at your apache logs, it will provide a more clear error that we can help you debug with. Though a 405 error typically signifies a problem with the server and usually stems for a POST request.
I have made the mistake 2 times of creating my site in html instead of using a scripting extension. For example, if you are running on a Windows server and coding in Visual Studio, it is tempting to just create .htm or .html files. However, most web servers will not allow a POST operation to these pages. Instead, create .aspx pages, which will still allow you to use the same exact static HTML and JavaScript. This solved my problem in both cases.
Related
I maintain a vb.net website. A button on a page shows an AjaxControlToolkit.dll ModalPopupExtender. When I click the button, the page reloads, but no popup appears.
My tests below cover the scenarios I can think of. Please help me diagnose and fix.
This ModalPopupExtender succeeded in the past. The error might have started when we moved to a new server, or when we implemented https, or a browser update, or at some other time since then.
Tried Chrome (latest) and Firefox.
I RDPed into the server and opened the page in Chrome there. ModalPopupExtender succeeded. Same Chrome version as my PC. So, unlikely to be a code issue.
A different page on the same site uses ModalPopupExtender successfully. So, unlikely to be local PC settings.
I put lines of test code immediately before and after ModalPopupExtender.Show(). Both succeed.
Aha - found it!
Solution
The ASPX/HTML referred to http://ajax.googleapis.com. Changing the references to https made ModalPopupExtender.Show() work correctly for me.
Explanation/Diagnosis (if you can clarify further, please comment)
When I checked the html served to my browser, I noticed it defined a javascript function called fn(). The definition for fn() didn't appear in the html served to the server's browser. After the https change, fn() no longer appears in the html I receive. The other page, where ModalPopupExtender worked, didn't have any reference to googleapis.com.
I assume that using http instead of https caused ajax.googleapis.com to provide fn() and that fn() in some way interfered with the normal operation of my ModalPopupExtender.
Here's the fn() definition: (function {var fn = function() {Sys.Extended.UI.ModalPopupBehavior.invokeViaServer('ctl00_cphContent_ModalPopupExtenderConfirm', true); Sys.Application.remove_load(fn);};Sys.Application.add_load(fn);})();
Note: the http also included another javascript function related to the ModalPopupExtender. But there was a similar one on the working page, and in the working version served to the server's browser, and in my fixed version. So, I assume that function is correct.
Ok so I asked a question earlier about a using
webclient.downloadfile($url,$path)
I couldn't open the PDF file because it was coded improperly.
What I now know is that it's because the website ONLY allows Internet Explorer to be used. therefore, I never actually downloaded the PDF, but rather an HTML page..as a PDF. Thus the error. For the website, when any other site is used, a page pops up letting you know so. I found out when I used:
$webclient.downloadstring($url)
..And read through a few lines in the Powershell ISE, coming across the same sentence:
"Detected Incompatible browser. Must use IE 7.0 and up"
Ok. So I did some research and learned about this .AddHeader() Function. I used the following.
$wc.Headers.Add("user-agent", "Windows-RSS-Platform/2.0 (MSIE 9.0; Windows NT 6.1)")
On this website actually. I figured this will trick the site into thinking I am using Internet Explorer 9.0. I typed in $webclient to view all properties of my Net.webclient object and read
Headers: {user-agent}
Sweet I said. Now it will work. But then I tried my .downloadfile function and the same shiz happened.
After running my downloadfile, I checked out the properties for $webclient again and Headers= {} What happened to my user-agent? Can anyone let me know why this is happening or offer any tips to get this working?
This is normal - headers are being reset after the first call made by WebClient. So any subsequent call will have them empty. Here's a proof link from msdn.microsoft.com:
Repeated calls with the same WebClient casues 404
We've found that the second (and subsequent) calls made using a WebClient fail.
This is because any headers are lost. So you need to ensure the custom headers
you use are reset before each call on the same WebClient instance.
I have applications which are displayed as tabs in Facebook pages which have been working fine. They suddenly started displaying this output in the tab:
/1336720089,176820405/
if (window.CavalryLogger) { CavalryLogger.start_js(["EgxV3"]); }
__d("UFIUpdate",
Any ideas what is going on???
Here is a link to one of them: http://www.facebook.com/TweakShoes/app_132692060112327
A temporary solution is to add https:// to facebook itself. This doesn't solve the problem, but it'll allow you to see your page on a per client basis.
The best fix in the longer term until facebook fixes this issue is to go to your account settings > Security > Enable secure browsing. This will enforce HTTPS wherever it can and should resolve the issue for a lot of pages you're trying to access.
Good Luck!
After encountering this issue yesterday, I tracked it down to an apparent conflict with the JS log wrapper included as part of HTML5 Boilerplate's script.js file. In particular, the "make it safe to use console.log always" snippet. After commenting it out, the FB lib error went away and my app displayed properly.
I didn't dig into what the conflict was, but here is the snippet. If you use something similar on your page, then it may be worth investigating.
/* make it safe to use console.log always */
(function(b){function c(){}for(var d="assert,count,debug,dir,dirxml,error,exception,group,groupCollapsed,groupEnd,info,log,timeStamp,profile,profileEnd,time,timeEnd,trace,warn".split(","),a;a=d.pop();){b[a]=b[a]||c}})((function(){try
{console.log();return window.console;}catch(err){return window.console={};}})());
It's probably not a coincidence that FB's own logger bugs out with this.
Facebook has opened a bug for this issue and recently triaged it to medium priority - no word on when it will be addressed.
I have a GWT application which is secured by Spring Security. I have a Main.html which serves the application and Login.html for login. For most part everything works fine everytime. But sometimes after restarting my application I can still access Main.html - although most of the widgets on the page are unusable. I can see the Login.html's HTML in the console being printed as exception. On refreshing, it takes me to login page. Has anyone ran into similar issue? Is this some kind of caching issue? How can this be avoided?
It seems that in your case your bootstrap file is beining cached and thus a wrong version of your app is being loaded.
You have to make sure that your bootstrap file (the one which is named nocache) is never cached. See here for more details.
You can check if your bootstrap file is cached by using Firebug and looking at the HTTP requests for your scripts. You can check two things:
If the correct <md5>.cache.html are loaded (compare it to the ones in your gwt output folder).
The response type of your .nocache. file is not 304 or so.
Adding meta tag on top of my Main.html - helped me resolve my issue for now.
Read this for more details : HTML http-equiv Attribute
The last couple of days i came across a bunch of https issues (just altering facebook apps to work with https). Now when all files are on the same website everything is easy to alter also using //www.domain.com/etc and ofcourse FB._https = {window.location.protocol== "https"};
is a time saver.
But now i have a file which uses get_file_content('http://www.somesite') and i can find the src that causes the https to be insecure.
Is there some firebug / webdeveloper tab i should look at???? How to find the troubling src??
regards
Can't you look at the net tab of firebug and set it just to show image responses?