views:

213

answers:

1

I am running into an “interesting” error with my WCF JSONP web service. It is the only one I have and it only exposes one method. If I hit my service via web browser internally it pops up with a message that, effectively, MEX is not enabled (true). If I hit it from outside our network (like you would unless you were on a machine in my company) it just sits and finally times out. The URL is: http://demo.rivworks.com/services/Negotiate.svc. Any ideas as to what might be causing this behavior?

Here is the web.config:

  <!-- WCF configuration -->
  <system.serviceModel>
    <behaviors>
      <endpointBehaviors>
        <behavior name="JsonpServiceBehavior">
          <webHttp />
        </behavior>
      </endpointBehaviors>
    </behaviors>

    <services>
      <service name="RivWorks.Web.Service.NegotiateService">
        <endpoint address=""
                binding="customBinding"
                bindingConfiguration="jsonpBinding"
                behaviorConfiguration="JsonpServiceBehavior"
                contract="RivWorks.Web.Service.INegotiateService" />
      </service>
    </services>

    <extensions>
      <bindingElementExtensions>
        <add name="jsonpMessageEncoding" type="RivWorks.Web.Service.JSONPBindingExtension, RivWorks.Web.Service, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      </bindingElementExtensions>
    </extensions>

    <bindings>
      <customBinding>
        <binding name="jsonpBinding" >
          <jsonpMessageEncoding />
          <httpTransport manualAddressing="true"/>
        </binding>
      </customBinding>
    </bindings>    
  </system.serviceModel>
</configuration>

Here is the code:

namespace RivWorks.Web.Service
{
    //----------------------------------------------------------------------------------------------------------//
    // Data class                                                                                               //
    //----------------------------------------------------------------------------------------------------------//
    [DataContract(Name = "NegotiateSetup", Namespace = "http://rivworks.com/DataContracts/2009/01/15")]
    public class NegotiateSetup : INegotiationInitialize
    {
        #region Declarations
        ...
        #endregion


        #region INegotiationInitialize Members
        ...
        #endregion
    }

    //----------------------------------------------------------------------------------------------------------//
    // Service Implementation                                                                                   //
    //----------------------------------------------------------------------------------------------------------//
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class NegotiateService : INegotiateService
    {
        public NegotiateService() { }

        public INegotiationInitialize GetSetup(string method, string jsonInput)
        {
            ...
            return resultSet;
        }
    }
}

I am after a couple of things here:

  1. Why can I NOT hit it from outside my local network?
  2. How can I get MEX working properly

Note: I am using the JSONP classes found here: http://msdn.microsoft.com/en-us/library/cc716898.aspx

A: 

To enable your MEX, add this inside your service tag:

<endpoint address="mex"
          binding="mexHttpBinding"
          contract="IMetadataExchange" />

Inside your behaviors tag, add:

  <serviceBehaviors>
    <behavior name="JsonpServiceBehavior">
      <serviceMetadata httpGetEnabled="true"/>
    </behavior>
  </serviceBehaviors>

About why that service isn't accessible from outside, can this be a firewall issue?

Rubens Farias
We found out our hosting company had changed the IP address for this particular site "because of SSL conflicts" - even though it had run stable for almost a year now. We had an intermediate cert fail and had to reinstall our wild card cert. One of the comman line scripts for mapping host headers to port 443 (SSL) was not run. When IIS finally cycled the app pool the failure showed up. Rackspace changed some IPs but did not remap the certs correctly. So, that leaves me with the MEX challenge and this answer seems to handle it now. Thanks!
Keith Barrows