Question

I created a WCF web service and hosted it on IIS. The web.config looks something like this:

[...]
<system.serviceModel>
    <behaviors>
        <serviceBehaviors>
            <behavior name="[Namespace].[ServiceNameBehavior]">
                <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
                <serviceDebug includeExceptionDetailInFaults="true"/>
            </behavior>
        </serviceBehaviors>
    </behaviors>

    <services>
        <service name="[Namespace].[ServiceName]" behaviorConfiguration="[NameSpace].[ServiceNameBehavior]" >
            <endpoint address="basic" binding="basicHttpBinding" contract="[Namespace].[IService]" />
            <endpoint address="secure" binding="basicHttpsBinding" contract="[Namespace].[IService]" />
        </service>
    </services>
</system.serviceModel>
[...]

When I access http://localhost/[Namespace]/[ServiceName].svc I get the usual web service web page indicating you have created a service, and that to test it you should call the service using svcutil.exe, etc, etc…

Now.. the problem is that, as defined in the web.config, I want to use two types of connections for this web service (and actually just limit the access to those two, so disabling the default .svc call) but when I go to http://localhost/[Namespace]/[ServiceName].svc/basic or https://localhost/[Namespace]/[ServiceName].svc/secure I get a blank page nor can I access the services from a local-hosted PHP page.

Is it normal that these bindings behave like this? If not, How can I fix it?

Update 1

---

I also noticed that trying to create references to either of these endpoints from Visual Studio results in the following error:

There was an error downloading ‘https://localhost/%5BNamespace%5D/%5BServiceName%5D.svc/secure’.
The request failed with HTTP status 400: Bad Request.
Metadata contains a reference that cannot be resolved: ‘https://localhost/%5BNamespace%5D/%5BServiceName%5D.svc/secure’.
Content Type application/soap+xml; charset=utf-8 was not supported by service https://localhost/%5BNamespace%5D/%5BServiceName%5D.svc/secure. The client and service bindings may be mismatched.
The remote server returned an error: (415) Cannot process the message because the content type ‘application/soap+xml; charset=utf-8’ was not the expected type ‘text/xml; charset=utf-8’..
If the service is defined in the current solution, try building the solution and adding the service reference again.

Adding a reference to http://localhost/%5BNamespace%5D/%5BServiceName%5D.svc works good.

Answer 1

It all looks like it’s working to me, you just seem to have confused the concepts of Service URL and Endpoint URL:

• There is only one service URL per <service> element per protocol. This is used to get the test page, to add a service reference, and to get the WSDL document (via the ?wsdl query parameter).
• There is also one endpoint URL per <endpoint> element. These are the ones ending in /basic or /secure. The only thing that these URLs will do is accept SOAP requests. You can’t get metadata from them or browse to them. There is one exception to this, you can expose a /mex endpoint using a mexHttpBinding or mexHttpsBinding which returns metadata via a SOAP request. This is entirely optional, and in your case is unnecessary, since you are exposing the WSDL via HTTP(S) GET instead.

On the client side, in Visual Studio, you Add Service Reference using http://localhost/[Namespace]/[Service].svc. If defining client endpoints manually, you set their addresses to http://localhost/[Namespace]/[Service].svc/basic and http://localhost/[Namespace]/[Service].svc/secure respectively.

UPDATE:

To prevent the http://localhost/[Namespace]/[Service].svc URL from responding to requests, disable metadata publishing in the service config:

<behaviors>
    <serviceBehaviors>
        <behavior name="[Namespace].[ServiceNameBehavior]">
            <serviceMetadata httpGetEnabled="false" httpsGetEnabled="false"/>
            <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
    </serviceBehaviors>
</behaviors>

Obviously if you do this then you can no longer add a new service reference in any client code, but that is perfectly acceptable in a production environment where you control both client and server code.