Who knows the issue? It seems Swagger cannot support IE. I deployed Swagger example as following in Tomcat. The example works well in Google Chrome & Firefox.
https://github.com/wordnik/swagger-core/tree/master/samples/no-server
But the example cannot be shown in IE correctly. URL always be directed to tomcat's index page. I have tried to change "localhost" to IP or hostname, but it still cannot work in IE.
Does swagger cannot support IE? Is it a bug?
Input the URL and run in IE
http://localhost:8080/swagger/index.html
Redirect to the URL (always insert # inside)
http://localhost:8080/#swagger/index.html
Thanks for your help.
Swagger's own petstore demo doesn't seem to work in IE either, so I guess it's a problem with the code rather than with your particular installation.
Related
I'm trying to get a basic sample across domains working, but I just cannot get it to work. According to someone here https://github.com/SignalR/SignalR/issues/6 he got it to work by adding a Access-Control-Allow-Origin header.
Basically, I've added a hub to an mvc 3 application, added the above header in the web.config, and created a page to send a message. This setup works fine.
Next, I've created a different web application using the same client javascript on a page, but setting the url to a different server using:
$.connection.hub.url = 'http://www.myserver.com/signalr';
As soon as I use a remote url it stops working.
How can I get SignalR to work across domains?
Update:
Some added information, the above approach works for chrome and firefox, but IE9 is not liking it...
I got it working using a simple test project and Internet Explorer 9, but it wasn't easy and first I was hung on the same problems you described. I think you are almost there and you are only missing the following line in your JavaScript:
jQuery.support.cors = true;
which tells jQuery to do cross domain calls. Seems simple, but was really hard to find ;-)
I explained all the steps I did in a blog post since I didn't find any existing information on this topic so far.
Tell me if there are any more problems. I have a working test project running in Internet Explorer 9 which I can send you.
I am developing a website using Microsoft MVC3, and have built it upon the default MVC3 Application template. It accesses an external database and works on localhost.
I have deployed it to a shared server I rent from storminternet via the publish tool using ftp method (storminternet do not yet support web deploy), and it runs well. It accesses the database okay and get requests work fine.
However, any form that submits via POST protocol returns page not found error 404 (this is on actions where I have asserted [HttpPost]).
Storm internet assure me that POST and GET are allowed by default, and since the helpdesk are not developers, I'm unsure who to turn to. I don't have an excellent understanding of web.config, although I can read and understand xml and see what's going on by reading through and googling. I have tried adding the protocols to the root web.config, and I think I might be barking up the wrong tree.
Has anyone else had this problem, or might anyone know how to help me?
To replicate my error, my site is here... 213.229.125.117/$sitepreview/ase-limited.com/Dev (sorry it isn't blue. The dollar gets parsed to % something)
and the quickest route to a POST request is to click 'Add Building' at the top of the left-hand side and then click 'Save' at the top of the dialogue box.
Any help will be gratefully received. I've been stuck on this for days without luck.
Best Regards
Nick
STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-
It turned out to be a known issue with sitepreview. Switching to the proper domain sorted everything.
I have noticed that you have some 404 javascript errors when performing your AJAX requests. For example you have a request to:
http://213.229.125.117/$sitepreview/ase-limited.com/BuildingManager/Employees/2
instead of:
http://213.229.125.117/$sitepreview/ase-limited.com/Dev/BuildingManager/Employees/2
Notice how /Dev is missing. That's because in your javascripts you have hardcoded your urls instead of using url helpers to generate them. For example you wrote something like this:
$.ajax({
url: '/BuildingManager/Employees/2',
....
});
which works fine on localhost because you don't have a virtual directory name but doesn't work when you deploy on your server because now the correct path is:
$.ajax({
url: '/Dev/BuildingManager/Employees/2',
....
});
For this reason you should absolutely never hardcode urls like that.
And when I try to POST the form in tries to post to http://213.229.125.117/Dev/BuildingManager/SaveBuilding which seems a very weird url as it is missing the whole beginning. Once again: never hardcode urls. Always use url helpers.
I am developing a website, which is currently running on my test server (IIS7). I can access the web site from any browser (including different versions of Firefox), but one specific Firefox does this:
http://www.mysite.com/www.mysite.com
I have no clue what to look for… Has anyone had such a problem?
You must have to have
link
or
link
but not
link
Some browsers do "smart" thing to correct these urls, but it's bad practice.
There seem to be a know issue with IE which doesn't respond to URLs that have # sign in them.
See for example: https://mootools.lighthouseapp.com/projects/2706/tickets/638-request-fails-when-url-has-hash-in-ie7
As we use # quite frequently in out GWT based application we are lacking support for IE7 users who want to browse the site.
Is there any known workaround for GWT other than modifying the URL?
History works perfectly well in our GWT app in all IE versions...
That ticket was about XMLHttpRequest, so do not use hashes in your xmlhttprequests. It has nothing to do with GWT.
First of all, the problem described in the supplied link is related with URLs that you query with XMLHttpRequest. In GWT application # can appear in ordinary GET request (when you are opening the page, that is when you are starting your GWT application). When GWT does XMLHttpRequest request, it uses URLs similar to:
http://yourserver.com/context/com.yourcompany.SomeModule/someService
There is no # in it, so if you have any problems, they are not related with this issue.
I think I finally figured out what the problem is.
Our gwt application is sitting as an iframe inside another HTML file so setting the gwt history support
<iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1' style="position:absolute;width:0;height:0;border:0"></iframe>
has to be done in the outer HTML rather than the gwt one.
This gwt script was meant to support browsers such as IE6 and IE7 which don't have the onhashchange event implemented.
I am running a website on my local machine ("http://localhost/asdf") and trying to get some file:// protocol links to work. In reality I'm trying to open a folder, not a specific file, but I can't get either to work.
I've put localhost in my "trusted zone", I've tried every combo of "file" ,":", some number of "/" and then a whole bunch of different paths, but encoded and not encoded.
Nothing I do causes anything to open when I click on the link. If I copy the link destination, and paste that in the browser address window, then it works as expected.
Anyone know the secret?
Add your intranet site in the Intranet Zone in Security Tab.
Generally file:/// URLs shouldn't work on pages downloaded via HTTP, that they sometimes work in IE7 and earlier is a security issue.
We found that window.open method using the file protocol in the URL causes the method to fail. Under I.E. the behavior is erratic. In some instances, the object mentioned in the URL is opened but the window object instance is not created. In others, the URL failes to open. In some instances we noted that under Windows 7, the URL opens, under XP it does not. Under Safari,Chrome and Firefox, the URL never opened.
Local server is something different than just file://, that should work in IE as it is. However, if you probably want to check out apache alias and link that folder to your server. Btw, you should not use file protocol anyway, it will not work on production.