Cross Domain and Method Dispatch Issues with 1.0 Alpha 1/2 #980

Closed
RussellPolitzky opened this Issue Nov 19, 2012 · 7 comments

Comments

Projects
None yet
2 participants
@RussellPolitzky

Hi All,

After upgrading to 1.0 Alpha 1 and explicitly specifying JSON P for cross domain, I'm getting the following error IRO CORS:

XMLHttpRequest cannot load http://localhost:50945/signalr/send?transport=longPolling&connectionId=c4ca7904-ef0a-4f2c-a8e3-8a7f3ceb24d8. Origin http://localhost:50944 is not allowed by Access-Control-Allow-Origin.

And this one from one of my hubs after forcing JSONP.

Description: An unhandled exception occurred during the execution of the current web request. Please >review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidOperationException: 'Publish' method could not be resolved.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[InvalidOperationException: 'Publish' method could not be resolved.]
Microsoft.AspNet.SignalR.Hubs.HubDispatcher.OnReceivedAsync(IRequest request, String connectionId, String data) +502
Microsoft.AspNet.SignalR.<>c__DisplayClass6.b__4(String data) +69
Microsoft.AspNet.SignalR.Transports.LongPollingTransport.ProcessSendRequest() +107
Microsoft.AspNet.SignalR.Transports.LongPollingTransport.ProcessRequest(ITransportConnection connection) +37
Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequestAsync(HostContext context) +498
Microsoft.AspNet.SignalR.Hubs.HubDispatcher.ProcessRequestAsync(HostContext context) +162
Microsoft.AspNet.SignalR.Hosting.AspNet.AspNetHandler.ProcessRequestAsync(HttpContextBase. context) +457
Microsoft.AspNet.SignalR.Hosting.AspNet.HttpTaskAsyncHandler.System.Web.IHttpAsyncHandler.Begi>nProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) +68
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +301
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +155

We're using cross domain with JSON P on this branch since CORS seems to be failing with a cross domain issue on 1.0 Alpha 1/2 in our code base. Interestingly, other hubs in the same solution still work correctly. There's one difference between these though, namely that this hub deals with larger messages. Looking at a typical JSONP request, I see that they're in the 1200 character range.

I'm primarily using Chrome for these tests, but seem to be encountering the same issue with Firefox. Upgrading to 1.0 Alpha 2 also didn't correct the problem. It seems that the hub proxies are being generated correctly in 1.0 Alpha 1/2 but that there's a problem with method dispatch/resolution on the server side as per the error given above.

I have a branch using 0.5.3 which works correctly (ie. it allows CORS and the calls do go through to the hub method that's failing on 1.0 Alpha 1/2).

Am I missing something here? Is there any additional config for 1.0 Alpha required for cross domain operation? Any ideas on this one?

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Nov 19, 2012

Member

Not sure JSONP has anything to do with this particular issue. Seems like the data is getting to the server but maybe the hubs aren't being discovered properly? One quick way to check is to hit your server in the browser and look at the signalr/hubs generated file and see if your hubs are there.

Member

davidfowl commented Nov 19, 2012

Not sure JSONP has anything to do with this particular issue. Seems like the data is getting to the server but maybe the hubs aren't being discovered properly? One quick way to check is to hit your server in the browser and look at the signalr/hubs generated file and see if your hubs are there.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Nov 19, 2012

Member

Another possible reason for this error would be passing the wrong number of arguments to the method in question.

Member

davidfowl commented Nov 19, 2012

Another possible reason for this error would be passing the wrong number of arguments to the method in question.

@RussellPolitzky

This comment has been minimized.

Show comment Hide comment
@RussellPolitzky

RussellPolitzky Nov 19, 2012

Thanks for those suggestions David. The first one was what I initially thought but the generated code in hubs looks good:

 signalR.publishHub = signalR.hub.createHubProxy('publishHub'); 
    signalR.publishHub.client = { };
    signalR.publishHub.server = {
        publish: function (sendMessagesRequest) {
            return signalR.publishHub.invoke.apply(signalR.publishHub, $.merge(["Publish"], $.makeArray(arguments)));
         }
    };

I think the number of args is correct. Here's a sample call from chrome showing the decoded query string params with irrelevant content removed and the JSON data pretty printed.

transport:longPolling
connectionId:d2e500f8-1b5f-4099-a5ef-f04533469958
callback:jQuery18207175194981973618_1353348820070
data:{
  "hub": "publishhub",
  "method": "Publish",
  "args": [
    {
      "messages": [
        {
           ............
        }
      ]
    },
    null
  ],
  "state": {

  },
  "id": 2
}_:1353348867123

The target method on the server side has a single request object argument::

   public virtual SendMessagesResponse Publish(SendMessagesRequest sendMessagesRequest)
   {
       ...........
   }

Should I be seeing the null as the last item in the data array of this request? Is that perhaps the issue here?

Thanks for those suggestions David. The first one was what I initially thought but the generated code in hubs looks good:

 signalR.publishHub = signalR.hub.createHubProxy('publishHub'); 
    signalR.publishHub.client = { };
    signalR.publishHub.server = {
        publish: function (sendMessagesRequest) {
            return signalR.publishHub.invoke.apply(signalR.publishHub, $.merge(["Publish"], $.makeArray(arguments)));
         }
    };

I think the number of args is correct. Here's a sample call from chrome showing the decoded query string params with irrelevant content removed and the JSON data pretty printed.

transport:longPolling
connectionId:d2e500f8-1b5f-4099-a5ef-f04533469958
callback:jQuery18207175194981973618_1353348820070
data:{
  "hub": "publishhub",
  "method": "Publish",
  "args": [
    {
      "messages": [
        {
           ............
        }
      ]
    },
    null
  ],
  "state": {

  },
  "id": 2
}_:1353348867123

The target method on the server side has a single request object argument::

   public virtual SendMessagesResponse Publish(SendMessagesRequest sendMessagesRequest)
   {
       ...........
   }

Should I be seeing the null as the last item in the data array of this request? Is that perhaps the issue here?

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Nov 19, 2012

Member

That looks wrong, where is that null coming from. Its definitely the reason things are broken.

Member

davidfowl commented Nov 19, 2012

That looks wrong, where is that null coming from. Its definitely the reason things are broken.

@RussellPolitzky

This comment has been minimized.

Show comment Hide comment
@RussellPolitzky

RussellPolitzky Nov 19, 2012

Thanks David. I'll investigate tomorrow morning and find out where that null is coming from.

Thanks David. I'll investigate tomorrow morning and find out where that null is coming from.

@RussellPolitzky

This comment has been minimized.

Show comment Hide comment
@RussellPolitzky

RussellPolitzky Nov 20, 2012

David, the problem was that we had some old code using the following calling pattern:

myHub.someMethod(param1, doneCallback)
     .fail(function(error) {
     });

I've changed it to use jQuery Deferreds properly and the call's now working as expected.

myHub.someMethod(param1)
     .done(function(result) {
     })
     .fail(function(error) {
     });

Thanks for pointing us in the right direction. I suspect that the old calling pattern is no longer supported so this isn't a bug.

I'll do a little more testing around CORS.

David, the problem was that we had some old code using the following calling pattern:

myHub.someMethod(param1, doneCallback)
     .fail(function(error) {
     });

I've changed it to use jQuery Deferreds properly and the call's now working as expected.

myHub.someMethod(param1)
     .done(function(result) {
     })
     .fail(function(error) {
     });

Thanks for pointing us in the right direction. I suspect that the old calling pattern is no longer supported so this isn't a bug.

I'll do a little more testing around CORS.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Nov 20, 2012

Member

Awesome! I filed this #981.

Member

davidfowl commented Nov 20, 2012

Awesome! I filed this #981.

@davidfowl davidfowl closed this Nov 20, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment