163

I have the following web service;

    [WebMethod]
    public string HelloWorld()
    {
        return "Hello World";
    }

It's stock standard with no alterations to the class decorators.

I have this jQuery method;

var webMethod = "http://localhost:54473/Service1.asmx/HelloWorld"; 

$.ajax({
    type: "POST",
    contentType: "application/json; charset=utf-8",
    data: "{}",  
    dataType: "json",
    url: webMethod,
    success: function(msg){ alert(msg.d); },
    error: function (XMLHttpRequest, textStatus, errorThrown) {
        alert(errorThrown);
          }
});

It's a post action because later on I need to post data to it.

When I execute the jQuery I get a "No transport" error returned.

One thing I should also mention is that the jQuery is stored in a simple HTML file on my machine and the WebService is running on my machine also.

There is no code behind on the HTML page it's simply a web page and not a c# project or anything.

Can anyone please point me in the right direction here?

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
griegs
  • 22,624
  • 33
  • 128
  • 205
  • Can you get to your web service just using a browser? – Avitus Mar 09 '11 at 03:55
  • Sorry, I didn't notice that this is a different post (I edited this post, thinking it was my own), I must've clicked the hyperlink to this one in my own post. Really sorry to the post owner =\ – Erick Garcia Jul 26 '11 at 11:05
  • $.support.cors = true; If your endpoint is CORS enabled (it responds correctly with an Access-Control-Allow-Origin header, etc), then this line of code will persuade jQuery to do a cross origin request in IE8. I just ran into this earlier, hoping it will save some of you some time and headache. – hert Jun 17 '14 at 02:26

8 Answers8

258

Add this: jQuery.support.cors = true;

It enables cross-site scripting in jQuery (introduced after 1.4x, I believe).

We were using a really old version of jQuery (1.3.2) and swapped it out for 1.6.1. Everything was working, except .ajax() calls. Adding the above line fixed the problem.

ccellar
  • 10,326
  • 2
  • 38
  • 56
SrBlanco
  • 2,581
  • 2
  • 14
  • 2
  • A bit more info here: http://blueonionsoftware.com/blog.aspx?p=03aff202-4198-4606-b9d6-686fd13697ee – Andrew Arnott Jun 22 '11 at 01:19
  • 14
    this fix my problem, worked in chrome and firefox but not IE. added this to the top of my script and all was good – Peter Jul 08 '11 at 04:40
  • @SrBlanco This fix my probem too, Thanks for sharing this info. – dev Jul 11 '11 at 21:10
  • 4
    Very good fix,I had the same problem on Internet Explorer 9 when I was requesting a kml file from the same domain using a relative path... mysteries of IE... – Matteo Conta Oct 21 '11 at 07:46
  • thanks. yes my rest calls stopped after 1.5 jquery updates. this code fixed it. – ashraf Dec 17 '11 at 01:52
  • This didn't work work me. In FF 3.6.15 I get no error message. In IE8 I get the "no transport" message. I'm using jquery.form.js to submit a form. It's ajaxSubmit function is the only function causing this error. I have other $.post functions, they work fine. I've tried changing the data type to jsonp and I changed the forms method from get to post. Nothing seems to work. – Jerinaw Apr 02 '12 at 14:26
  • *Update* I'm using $.getScript to get the script that uses the jquery.form plug in. When I removed the $.getScript and used a regular script tag my form was able to submit. Again, this only happens in FF 3.6.15 and IE8. Everything works fine on the latest Chrome and FF. – Jerinaw Apr 02 '12 at 14:37
  • *Update 2* Seems that the original problem only happens when I use https. When it's just http the form submits fine. – Jerinaw Apr 02 '12 at 15:57
  • I was sending to the same domain, using $.ajax() and https, and got the "no transport" error in IE and Opera. This fixed my problem. – Steve G May 10 '12 at 23:21
  • This fixed my problem. In ie, you can add a site to your trusted sites (with xss filtering disabled for that zone), and it will allow cross domain xmlhttprequests to the trusted site. This worked using the xmlhttprequest directly, but when I tried to use $.ajax, it didn't work. It was this setting in jQuery that was causing the issue within my test environment. – AdamantineWolverine May 21 '12 at 02:45
  • This also solved a problem for me. Had the same problem on the Samsung Smart TV SDK 2010 and 2011 (it uses a gecko version that was used with firefox 2.x). – dbozhinovski Jun 25 '12 at 15:40
  • This solution fixed my problem too, thank you! migrating from 1.4.x to 1.6.x and making an ajax call to localhost domain, using IE... – inancsevinc Oct 11 '12 at 09:40
  • @SrBlanco, Thanks this fixed my problem and I don't see "message from webpage error No Transport" for IE8 anymore. Still I have another issue where IE8 doesn't show my JSON data where Chrome does!!! – egyamado Aug 01 '14 at 18:46
  • Thanks! This should really be marked as the answer by the OP. – SpruceMoose Jun 03 '15 at 13:31
95

If your jQuery page isn't being loaded from http://localhost:54473 then this issue is probably because you're trying to make cross-domain request.

Update 1 Take a look at this blog post.

Update 2 If this is indeed the problem (and I suspect it is), you might want to check out JSONP as a solution. Here are a few links that might help you get started:

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
no.good.at.coding
  • 20,221
  • 2
  • 60
  • 51
  • 4
    Yeah, it probably has something to do with security. – thenengah Mar 09 '11 at 03:57
  • 3
    It doesn't have to be localhost:54473, it just has to be the same domain. – jcolebrand Mar 09 '11 at 03:59
  • 7
    @drachenstern Hm, I've always thought (and seem to remember always reading) that the scheme, host *and* port needed to be same. [This](http://stackoverflow.com/questions/1077218/are-different-ports-on-the-same-server-considered-cross-domain-ajax-wise) and [this](http://stackoverflow.com/questions/648048/ajax-cross-domain-calls) and [this](https://secure.wikimedia.org/wikipedia/en/wiki/Same_origin_policy#Origin_determination_rules) seem to support my way of thinking about what constitutes the same domain. – no.good.at.coding Mar 09 '11 at 04:04
  • @drachenstern Glad to be of help! All this web stuff is tricky - something new to learn everyday :) – no.good.at.coding Mar 09 '11 at 04:11
  • jQuery.support.cors fixed it thank you. Will get to the other articles a little later on. – griegs Mar 09 '11 at 04:15
  • 1
    @griegs Good to hear but do note that you're not actually solving the problem-this will only work if the environment allows cross-domain requests since you're only removing the safe-guards that jQuery puts in place. If your browser doesn't allow it, setting this property will do nothing for you. I would recommend putting in a bit of effort now to get JSONP in place. At the very least, you might want to try and see if forcing jQuery cross-domain support works with all the browsers you plan on supporting. I also can't comment on what **other** problems you might run into later! – no.good.at.coding Mar 09 '11 at 04:26
  • @no.good.at.coding, I fully appreciate that this is only a bandaid solution and your point on getting JSONP working is well noted. This is a site that will exist for around 6 months and the html pages and the webservice will sit on the same physical machine so I see no real dramas this time around. – griegs Mar 09 '11 at 21:26
  • I have this same issue in IE (in Chrome it's statusText is "error", helpful right?). Ironically, the command I am using works from a remote machine on the same subnet using an IP, however it fails when I run it on the same machine using localhost. – Kit10 Oct 24 '14 at 21:31
  • @Kit10 Because when you use "localhost" it is enforcing host name/domain policy. An IP doesn't have the domain context in it for it the code to know. – vapcguy Mar 14 '19 at 16:41
26

I had the same error on a page, and I added these lines:

<!--[if lte IE 9]>
<script type='text/javascript' src='//cdnjs.cloudflare.com/ajax/libs/jquery-ajaxtransport-xdomainrequest/1.0.3/jquery.xdomainrequest.min.js'></script>
<![endif]-->

and it finally works for me ;) no more error in IE9.

Scott Stafford
  • 43,764
  • 28
  • 129
  • 177
bsuttor
  • 2,716
  • 2
  • 17
  • 10
  • 6
    Github project: https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest and XDomainRequest information: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx . Basically, IE8 and IE9 do not support CORS on XMLHttpRequest object. You are forced to use XDomainRequest object instead (which is more limited. Can read the info on the second link). – richardaday Jan 25 '14 at 09:22
7

None of the proposed answers completely worked for me. My use case is slightly different (doing an ajax get to an S3 .json file in IE9). Setting jQuery.support.cors = true; got rid of the No Transport error but I was still getting Permission denied errors.

What did work for me was to use the jQuery-ajaxTransport-XDomainRequest to force IE9 to use XDomainRequest. Using this did not require setting jQuery.support.cors = true;

rynop
  • 50,086
  • 26
  • 101
  • 112
6

i solve it by using dataType='jsonp' at the place of dataType='json'

Abhishek
  • 173
  • 1
  • 2
  • 6
0

I too got this problem and all solutions given above either failed or were not applicable due to client webservice restrictions.

For this, I added an iframe in my page which resided in the client;s server. So when we post our data to the iframe and the iframe then posts it to the webservice. Hence the cross-domain referencing is eliminated.

We added a 2-way origin check to confirm only authorized page posts data to and from the iframe.

Hope it helps

<iframe style="display:none;" id='receiver' name="receiver" src="https://iframe-address-at-client-server">
 </iframe>

//send data to iframe
var hiddenFrame = document.getElementById('receiver').contentWindow;
hiddenFrame.postMessage(JSON.stringify(message), 'https://client-server-url');

//The iframe receives the data using the code:
window.onload = function () {
    var eventMethod = window.addEventListener ? "addEventListener" : "attachEvent";
    var eventer = window[eventMethod];
    var messageEvent = eventMethod == "attachEvent" ? "onmessage" : "message";
    eventer(messageEvent, function (e) {
        var origin = e.origin;
        //if origin not in pre-defined list, break and return
        var messageFromParent = JSON.parse(e.data);
        var json = messageFromParent.data;

        //send json to web service using AJAX   
        //return the response back to source
        e.source.postMessage(JSON.stringify(aJAXResponse), e.origin);
    }, false);
}
Riju Mahna
  • 6,718
  • 12
  • 52
  • 91
0

For me it is an entirely different story.
Since this page has a good search engine ranking, I should add my case and the solution here too.

I built jQuery myself with webpack picking only the modules I use. The ajax is always failed with "No Transport" message as the only clue.

After a long debugging, the problem turns out to be XMLHttpRequest is pluggable in jQuery and it does not include it by default.

You have to explicitly include jquery/src/ajax/xhr file in order to make the ajax working in browsers.

Heretic Monkey
  • 11,687
  • 7
  • 53
  • 122
Curious Sam
  • 884
  • 10
  • 12
-1

I solved it simply by removing the domain from the request url.

Before: https://some.domain.com/_vti_bin/service.svc

After: /_vti_bin/service.svc
Draghon
  • 347
  • 3
  • 9
  • 1
    Yes, jQuery same-domain ajax request where the domain is not specified in the url. In my case, I did not need to make a cross-site request and it seems that having the domain in the url parameter of the ajax request made the request somehow behave cross-site'ish. My environment uses Microsoft ForeFront with some redirect rules and it is possible that it could be causing the issues. – Draghon Jun 05 '14 at 19:28
  • then why are you answering in question regarding cross domain ajax request – Naeem Shaikh Jun 06 '14 at 05:26
  • 1
    @NaeemShaikh27, the nature of the request (cross-domain vs same-domain) was not clear from the OP; I was addressing the question given the "obvious" parameters in the question. Regardless, I'm just saying "hey, I got the same error, here's what I did" and whether you like it or not (or whether it's appropriate for SO), it did work for me. Now, if you go back and make the question more specific, then will my response be completely irrelevant. – Draghon Jun 27 '14 at 19:50