The WSDL is typically generated on the fly based on your models metadata, attributes, and host location. So if the wsdl is then proxied to another environment, it's going to have issues.

One escape hatch in [**`servicemetadata`**][5] is to specify a **`externalMetadataLocation`**:

> A Uri that contains the location of a WSDL file, which is returned to the user in response to WSDL and MEX requests instead of the auto-generated WSDL.

Add `externalMetadataLocation` like this below:



<pre><code>&lt;system.serviceModel&gt;
 &lt;behaviors&gt;
 &lt;serviceBehaviors&gt;
 &lt;behavior&gt;
 &lt;serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" 
 externalMetadataLocation="https://example.com/SOAP/Service1.wsdl" /&gt;
 &lt;/behavior&gt;
 &lt;/serviceBehaviors&gt;
 &lt;/behaviors&gt;
&lt;/system.serviceModel&gt;</code></pre>

You can then pre-generate your WSDL ahead of time, tweak at will, and upload the modified file to serve as the contract.

### Further Reading

* [Supply a different endpoint address in the WSDL of a WCF web service][0]
* [WCF behind a public reverse proxy which is used for traffic encryption][1]
* [WebService behind reverse proxy][2]
* [WCF Webservice behind public reverse proxy][3]
* [Fix the Endpoint Address When Using externalMetadataLocation][4]

[0]: https://stackoverflow.com/q/5073936/1366033
[1]: https://stackoverflow.com/q/12166587/1366033
[2]: https://stackoverflow.com/q/10213911/1366033
[3]: https://stackoverflow.com/q/274984/1366033
[4]: https://stackoverflow.com/q/4035523/1366033
[5]: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/wcf/servicemetadata

My apologize for long post...
We have a WCF service written in .Net 4.0 used internally within the organization. Recently there was a requirement to make this service available outside the organization network. So the network guys used reverse proxy to make this service available outside the organization. Here is the picture how it is set up.

![enter image description here][1]


As you can see in the picture..the service http://mywebservice.com/readd.svc is hosted on WIndows 2008 R2 which has a internal IP address as XXX.YYY.ZZZ.RRR. The service is hosted on port 80.

what is the problem ?.

Internally I can access the service as http://mywebservice.com/readd.svc using WCFTestClient and browser. But outside the organization if I type http://mywebservice.com/readd.svc I get "404 file not find error" and in WCFTestCleint I get error as "Error: Cannot obtain Metadata from http://mywebservice.com/readd.svc .........".

However if I type in the service as httpS://mywebservice.com/readd.svc in browser I get the screen which shows soap link as shown below. Please ignore the LookUpService.svc name mismatch.
![enter image description here][2]

As you can see in above figure ...address bar is https , but the soap link is http . If I click the http link http://.... ?wsdl , I get not found error. This is since Reverse proxy only allows connection as https .

If I use WCFTextClient and add servicie as https://mywebsite.com/readd.svc I get error as below.

"Error: Cannot obtain Metadata from https://mywebsite.com/readd.svc If this is a Windows (R)
 Communication Foundation service to which you have access, please check that you have
enabled metadata publishing at the specified address. For help enabling metadata publishing,
 please refer to the MSDN documentation at http://go.microsoft.com/fwlink/?LinkId=65455.WS-Metadata Exchange Error
 URI: http://mywebsite.com/readd.svc Metadata contains a reference that cannot be resolved: 
'https://mywebsite.com/readd.svc'. Content Type application/soap+xml; charset=utf-8 was not supported
 by service https://mywebsite.com/readd.svc. 
The client and service bindings may be mismatched. 
The remote server returned an error: (415) OK.HTTP GET Error 
 URI: https://mywebsite.com/readd.svc 
 The document at the url http://mywebsite.com/readd.svc was not recognized 
as a known document type.The error message from each known type may help you 
fix the problem:- Report from 'XML Schema' is 
'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.- 
Report from 'http://mywebsite.com/readd.svc' is 
'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.-
 Report from 'DISCO Document' is 'There was an error downloading 'http://mywebsite.com/readd.svc?disco'.'. -
 The request failed with HTTP status 404: Not Found.- Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'. "

I was informed by network guys to make service available as https. Here is my web.config file


 <system.serviceModel>
 <bindings>
 <basicHttpBinding>
 <binding name="BSBindingConfig" closeTimeout="00:10:00" openTimeout="00:10:00"
 receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false"
 maxBufferPoolSize="524388" maxBufferSize="50000000" maxReceivedMessageSize="50000000" messageEncoding="Text" 
 textEncoding="utf-8" useDefaultWebProxy="true" transferMode="Buffered">
 <readerQuotas maxDepth="32" maxStringContentLength="50000000" maxArrayLength="16384"
 maxBytesPerRead="4096" maxNameTableCharCount="16384" />
 </binding>
 </basicHttpBinding>
 </bindings>
 
 <behaviors>
 
 <serviceBehaviors>
 
 <behavior name="ServiceLookup.LookupServiceBehavior">
 <serviceMetadata httpGetEnabled="true" httpGetUrl=""/>
 <serviceDebug includeExceptionDetailInFaults="true"/>
 <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
 </behavior>
 
 </serviceBehaviors>
 
 </behaviors>
 
 <services>
 <service behaviorConfiguration="ServiceLookup.LookupServiceBehavior" name="SmallApp.ServiceLookUp.LookUpService">
 
 <endpoint address="" binding="basicHttpBinding" bindingConfiguration="BSBindingConfig" name="SmallApplianceBSEndPoint"
 contract="SmallApp.ServiceLookUp.ILookupService" />


 <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
 </service>
 </services>
 
 
 
 </system.serviceModel>

Can you suggest how I can resole this issue ..so that users outside organization can access the api with WCFTestCleint as http/https .

 [1]: http://i.stack.imgur.com/Q6Kg8.png
 [2]: http://i.stack.imgur.com/7Fw1S.png

Updated web.config file
<system.serviceModel>
 <bindings>
 <basicHttpBinding>
 <binding name="BSBindingConfig" closeTimeout="00:10:00" openTimeout="00:10:00"
 receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false"
 maxBufferPoolSize="524388" maxBufferSize="50000000" maxReceivedMessageSize="50000000" messageEncoding="Text" 
 textEncoding="utf-8" useDefaultWebProxy="true" transferMode="Buffered">
 <readerQuotas maxDepth="32" maxStringContentLength="50000000" maxArrayLength="16384"
 maxBytesPerRead="4096" maxNameTableCharCount="16384" />
 <security mode="Transport"> 
 </security>

 </binding>
 </basicHttpBinding>
 </bindings>
 
 <behaviors>
 
 <serviceBehaviors>
 
 <behavior name="ServiceLookup.LookupServiceBehavior">
 <serviceMetadata httpGetEnabled="true" httpGetUrl="" httpsGetEnabled="true"/>
 <serviceDebug includeExceptionDetailInFaults="true"/>
 <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
 </behavior>
 
 </serviceBehaviors>
 
 </behaviors>
 
 <services>
 <service behaviorConfiguration="ServiceLookup.LookupServiceBehavior" name="SmallApp.ServiceLookUp.LookUpService">
 
 <endpoint address="" binding="basicHttpBinding" bindingConfiguration="BSBindingConfig" name="SmallApplianceBSEndPoint"
 contract="SmallApp.ServiceLookUp.ILookupService" />
 
 <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
 <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
 </service>
 </services>
 
 <serviceHostingEnvironment multipleSiteBindingsEnabled="true"/>
 
 </system.serviceModel>
I am still gettign error accessing as http or https outside organization network

WCF using Reverse proxy

You cannot modify XHR requests coming back from the ASP.NET. Doing so would be to attempt a Man In The Middle Attack (which your proxy is acting as), but Microsoft has good reason to prevent.

Here's a dummy message to explore the syntax ASP.NET uses in the response:


 1|#||2|52|updatePanel|ctl00_mainContentPlaceHolder_firstUpdatePanel|
 New Content For First Update Panel 

The header starts with `1|#| |` and then the number of updates in the rest of the message (2) 
Then each update section follows the pattern: 

 |char_len|update_type|id_of_field_to_update| 
 New contents to insert into field

The `len` in each section must exactly equal the number of characters to follow. So finding and replacing content in these messages is extremely fickle.

The best recommendation is to simply return a relative URL that is server agnostic so the client can be redirected relative to their current domain.

When going through a proxy server (A), any self-referential links sent from the apps server (B) need to be re-written to use the proxy as a host instead.

Here's an example:

Response from (B) contains: <code>&lt;a href=&quot;http://apps/path&quot;&gt;path&lt;/a&gt;</code> 
Proxy (A) needs to rewrite as: <code>&lt;a href=&quot;http://proxy/path&quot;&gt;path&lt;/a&gt;</code>

Normally, this is done by creating an outbound rule that inspects html responses for tags that contain urls, looks for references to to the apps server, and rewrites them. 

**Here's a normal rule** [*GUI version*][1]: 



 <outboundRules>
 <rule name="Outbound Links" preCondition="IsHTML" enabled="true">
 <match filterByTags="A, Form, IFrame, Img, Input, Link, Script" pattern="(https?:\/\/proxy|^)\/(.*)" />
 <conditions logicalGrouping="MatchAll" trackAllCaptures="true" />
 <action type="Rewrite" value="http://apps/{R:2}" />
 </rule>

**Where `IsHTML` is defined as**:



 <preConditions>
 <preCondition name="IsHTML">
 <add input="{RESPONSE_CONTENT_TYPE}" pattern="text\/html" />
 </preCondition>

**The problem** is that some of the page content is returned via an XHR request. Minimally, this fails the HTML precondition.

[![Content Type - text/html vs XHR][2]][2]

 but I can expand the rule to also include content types of `xhr`

However, URL Rewrite still has trouble **parsing** the returned text into tags because it is not valid HTML. 

Here's an example of what the response looks like:



 |6383|updatePanel|ctl00_mainContentPlaceHolder_contentUpdatePanel|
 
 <div id="ctl00_mainContentPlaceHolder_resultsPanel">
 <a href="http://apps/path">path</a> 
 </div>

 ...
 
 |0|hiddenField|__EVENTTARGET||0|hiddenField|__EVENTARGUMENT||0|hiddenField|

However, when I do this, I get the error:

> **Sys.WebForms.PageRequestManagerParserErrorException**: 
The message received from the server could not be parsed.

 [1]: http://i.stack.imgur.com/Eaewx.png
 [2]: http://i.stack.imgur.com/Wd0n8.png