WCF service running under ASP.NET 4.52, Silverlight client. The app used to work when hosted on Windows 2008 R2. Now I've set it up on a Windows 2016 server, and the very first service call errors out with error 405 - method not allowed. The method here is POST. The error description goes:
405 - HTTP verb used to access this page is not allowed.
On the Windows 2008 based instance, it's POST also, but the back end has no problem with that. The service uses HTTPS with Windows auth.
The relevant Web.config bits are:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="winAuthBasicHttpBinding" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647">
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxDepth="2147483647" maxNameTableCharCount="2147483647" maxStringContentLength="2147483647"/>
<security mode="Transport">
<transport clientCredentialType="Ntlm"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="Foo.Web.Services.FooBehavior">
<serviceMetadata httpsGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="Foo.Web.Services.FooBehavior" name="Foo.Web.Services.FooService">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="winAuthBasicHttpBinding" contract="Foo.Web.Services.IFooService">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</service>
</services>
</system.serviceModel>
The erroring method has no annotations other than [OperationContract]. The interface only has [ServiceContract]. The service class has:
[WcfErrorBehavior]
[WcfSilverlightFaultBehavior]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
It might be relevant that the method has no arguments; I believe more recent versions of WCF use GET for those. The app is quite old.
The error reproduces with a generic HTTP client, it's not specific to the Silverlight front-end.
Looks like a difference in machine-level WCF configuration between .NET versions. Less likely, it could be that a Windows component is missing on the Windows 2016 box.
EDIT: enabled request tracing, got something back. There's a notification EXECUTE_REQUEST_HANDLER sent to StaticFileModule. A WCF service is most definitely not a static file.
Anyway, I want to reply to this thread. it might be useful to whoever encountered a similar issue.
#Seva Alekseyev, as you mentioned, for hosting WCF service created by Webhttpbinding in IIS, and some other protocol, such as Nettcpbinding, we should enable some kinds of Windows features.
For NetTcpbinding, we also need to enable the below Windows feature.
Feel free to let me know if there is anything I can help with.
Under Server Manager, roles and features, "HTTP Activation" was missing in the WCF category. My second hunch was right. That said, the error is somewhat misleading, so I'll leave this question here for posterity's sake.
Related
I am trying to use https & http for the website. The website has .svc files which act as REST service and called from JavaScript.
My Config:
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="AjaxBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="MyServiceBehaviour">
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpGetEnabled="True" httpsGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<services>
<service behaviorConfiguration="MyServiceBehaviour" name="MyService.Lookups">
<endpoint address="" behaviorConfiguration="AjaxBehavior"
binding="webHttpBinding" bindingConfiguration="httpWebBinding" contract="MyService.Lookups" >
</endpoint>
<endpoint address="" behaviorConfiguration="AjaxBehavior"
binding="webHttpBinding" bindingConfiguration="httpsWebBinding" contract="MyService.Lookups" >
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<bindings>
<webHttpBinding>
<binding name="httpsWebBinding">
<security mode="Transport">
<transport clientCredentialType="None" proxyCredentialType="None" />
</security>
</binding>
<binding name="httpWebBinding">
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" />
</security>
</binding>
</webHttpBinding>
</bindings>
</system.serviceModel>
Browsing https://myserver/services/Lookups.svc/Hello gives
Could not find a base address that matches scheme http for the endpoint with binding WebHttpBinding. Registered base address schemes are [https]
Browsing http://myserver/services/Lookups.svc/Hello gives
Could not find a base address that matches scheme https for the endpoint with binding WebHttpBinding. Registered base address schemes are [http]
If I remove any one endpoint it works. Example removing endpoint configured with bindingConfiguration="httpWebBinding" works for HTTPS ,
How can I make it work with HTTP and HTTPS? As of now, I can able to use either http or https by removing one endpoint.
Referred How can I combine the WCF services config for both http and https in one web.config? and How do you setup HTTP and HTTPS WCF 4 RESTful services?
Note: In IIS, it is two web sites one listen on http and another on
https. Both sharing same code in physical folder
UPDATE: As of now, I removed endpoints and it works. But my concern is removing endpoing configured with behaviourConfiguration doesnt look great solution to me.
This works for both http & https
<services>
<service behaviorConfiguration="MyServiceBehaviour" name="MyService.Lookups">
</service>
</services>
I've recreated your scenario and used your web.config to configure endpoints for my test service. Your configuration is ok and works correctly. The part that don't works for you is probably your https configuration in IIS. Make sure you have enabled https access to your service. If you test it with IISExpress from Visual Studio then left click on your project and in the properties window (View -> Properties Window ) select for SSL Enabled = True.
As #Lesmian pointed out in his answer, the issue is in your IIS configuration.
More specifically in:
Note: In IIS, it is two web sites one listen on http and another on https. Both sharing same code in physical folder
The reason is that IIS can not handle endpoints on a schema which it does not support.
You have two sites, and one of them has HTTP binding but does not has HTTPS, and the other has HTTPS but not HTTP.
So when you browse to http:// URL, IIS directs you to the (surprise!) http-enabled site, reads web.config, sees that it registers https endpoint (which is not supported by the site) and throws the exception telling that there is no https scheme support on the http-enabled-only site.
When you browse to the https:// URL the situation is similar - IIS does not allow you to use http endpoint on the https-enabled-only site.
To handle the issue you better use a single site with two bindings.
Another (and more complex) option would be using different web.configs for sites: set up separate sites (pointed to separate folders) and use the publishing and web.config transforming tools of the Visual Studio
Add This Code.
<protocolMapping>
<add scheme="http" binding="webHttpBinding" bindingConfiguration="httpWebBinding"/>
<add scheme="https" binding="webHttpBinding" bindingConfiguration="httpsWebBinding"/>
</protocolMapping>
I dont't know this query is still active or not but as i checked Please
Add binding="mexHttpsBinding" also
with binding="mexHttpBinding" with different endpoint
This helps me.
I'm building an ASP.NET website - it's a solution with a few projects, a data base and a web service. Everything worked fine, but last time I tried to run the project, I got the following error:
There was no endpoint listening at http://localhost:[number]/BooksWS.svc that could accept the
message. This is often caused by an incorrect address or SOAP action. See InnerException,
if present, for more details.
The inner exception says:
Unable to connect to the remote server
This error sort of came out of the blue, so I'm not sure what additional information I should provide. Does anyone have any idea why this could happen?
I suppose even a general answer could help, the only info I found about this error in the web concerned WCF.
go to webconfig page of your site, look for the tag endpoint, and check the port in the address attribute, maybe there was a change in the port number
Another case I just had - when the request size is bigger than the request size set in IIS as a limit, then you can get that error too.
Check the IIS request limit and increase it if it's lower than you need.
Here is how you can check and change the IIS request limit:
Open the IIS
Click your site and/or your mapped application
Click on Feature view and click Request Filtering
Click - Edit Feature Settings.
I just found also another thread in stack
IIS 7.5 hosted WCF service throws EndpointNotFoundException with 404 only for large requests
An another possible case is make sure that you have installed WCF Activation feature.
Go to Server Manager > Features > Add Features
I had this problem when I was trying to call a WCF service hosted in a new server from a windows application from my local. I was getting same error message and at end had this "No connection could be made because the target machine actively refused it 127.0.0.1:8888". I donot know whether I am wrong or correct but I feel whenever the server was getting request from my windows application it is routing to something else. So I did some reading and added below in Web.config of service host project. After that everything worked like a magic.
<system.net>
<defaultProxy enabled="false">
</defaultProxy>
</system.net>
Short answer but did you have Skype open? This interferes specifically with ASP.NET by default (and localhosts in general) using port:80.
In Windows: Go to Tools -> Options -> Advanced -> Connection and uncheck the box "use port 80 and 443 as alternatives for incoming connections".
Try this:
Delete the service instance.
Create a new instance of the service.
Sometimes the port is changed and generated error.
I tried a bunch of these ideas to get HTTPS working, but the key for me was adding the protocol mapping. Here's what my server config file looks like, this works for both HTTP and HTTPS client connections:
<system.serviceModel>
<protocolMapping>
<add scheme="https" binding="wsHttpBinding" bindingConfiguration="TransportSecurityBinding" />
</protocolMapping>
<services>
<service name="FeatureService" behaviorConfiguration="HttpsBehavior">
<endpoint address="soap" binding="wsHttpBinding" contract="MyServices.IFeature" bindingConfiguration="TransportSecurityBinding" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="HttpsBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
<behavior name="">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="TransportSecurityBinding" maxReceivedMessageSize="2147483647">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
If you are using custom binding, please make sure that you are putting the same name for both custom binding (Server and Client)in config files
<bindings>
<customBinding>
<binding name="BufferedHttpServerNoAuth" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
<gzipMessageEncoding innerMessageEncoding="textMessageEncoding" MaxArrayLength="10485760" MaxBytesPerRead="31457280" MaxStringContentLength="102400000" />
<httpsTransport hostNameComparisonMode="StrongWildcard" manualAddressing="False" maxReceivedMessageSize="31457280" authenticationScheme="Anonymous" bypassProxyOnLocal="True" realm="" useDefaultWebProxy="False" />
</binding>
</customBinding>
</bindings>
the binding name "BufferedHttpServerNoAuth" should be same in both.
Hope this would help someone
This is ancient history but I just ran into this issue and the fix for me was recycling the application pool of the website in IIS. Easy fix, for once.
I changed my website and app bindings to a new port and it worked for me. This error might occur because the port the website uses is not available. Hence sometimes the problem is solved by simply restarting the machine
-Edit-
Alternative (and easier) solution:reference
Get PID of process which is using the port
CMD command-
netstat -aon | findstr 0.0:80
Use the PID to get process name -
tasklist /FI "PID eq "
Open task manager, find this process and stop it.
(Note- Make sure you do not stop Net.tcp services)
I solved it by passing the binding with endpoint.
"http://abcd.net/SampleFileService.svc/basicHttpWSSecurity"
Click on Service which you have created right click on it then select update references after this rebuild the application it will work
Few days ago I had quite a headache with authentication problems when using Windows authentication between client and wcf web service. The error I was getting was "The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was "NTLM". None of the solutions on stack worked because most of them were related to old methods.
THE ANSWER: The problem was all of the posts for such an issue were related to older kerberos and IIS issues where proxy credentials or AllowNTLM properties were helping. My case was different. What I have discovered after hours of picking worms from the ground was that somewhat IIS installation did not include Negotiate provider under IIS Windows authentication providers list. So I had to add it and move up. My WCF service started to authenticate as expected. Here is the screenshot how it should look if you are using Windows authentication with Anonymous auth OFF.
You need to right click on Windows authentication and choose providers menu item.
Hope this helps to save some time.
I have upgraded my older version of WCF to WCF 4 with below changes, hope you can also make the similar changes.
1. Web.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="Demo_BasicHttp">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="InheritedFromHost"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="DemoServices.CalculatorService.ServiceImplementation.CalculatorService" behaviorConfiguration="Demo_ServiceBehavior">
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="Demo_BasicHttp" contract="DemoServices.CalculatorService.ServiceContracts.ICalculatorServiceContract">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Demo_ServiceBehavior">
<!-- To avoid disclosing metadata information, set the values below to false before deployment -->
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<protocolMapping>
<add scheme="http" binding="basicHttpBinding" bindingConfiguration="Demo_BasicHttp"/>
</protocolMapping>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
</system.serviceModel>
2. App.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ICalculatorServiceContract" maxBufferSize="2147483647" maxBufferPoolSize="33554432" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" sendTimeout="00:10:00" receiveTimeout="00:10:00">
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="4096" />
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:24357/CalculatorService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICalculatorServiceContract" contract="ICalculatorServiceContract" name="Demo_BasicHttp" />
</client>
</system.serviceModel>
Not this exact problem, but this is the top result when googling for almost the exact same error:
If you see this problem calling a WCF Service hosted on the same machine, you may need to populate the BackConnectionHostNames registry key
In regedit, locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
In the Name column, type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK.
Type each host name on a separate line.
See Calling WCF service hosted in IIS on the same machine as client throws authentication error for details.
For me the solution was besides using "Ntlm" as credential type:
XxxSoapClient xxxClient = new XxxSoapClient();
ApplyCredentials(userName, password, xxxClient.ClientCredentials);
private static void ApplyCredentials(string userName, string password, ClientCredentials clientCredentials)
{
clientCredentials.UserName.UserName = userName;
clientCredentials.UserName.Password = password;
clientCredentials.Windows.ClientCredential.UserName = userName;
clientCredentials.Windows.ClientCredential.Password = password;
clientCredentials.Windows.AllowNtlm = true;
clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
}
The solution for me was to set the AppPool from using the AppPoolIdentity to the NetworkService identity.
I had the same problem, to solve it set specific user from domain in iis -> action sidebar->Basic Settings -> Connect as... -> specific user
I am consuming a WCF Service from a webpart in Sharepoint 2007. But its giving me the following error:
There was no endpoint listening at
http://locathost:2929/BusinessObjectService
that could accept the message. This is
often caused by an incorrect address
or SOAP action. See InnerException, if
present, for more details. --->
System.Net.WebException: The remote
server returned an error: (404) Not
Found.
My Binding Details in the WCF web.config is:
<system.serviceModel>
<diagnostics performanceCounters="All">
<messageLogging logEntireMessage="true" logMessagesAtServiceLevel="false"
maxMessagesToLog="4000" />
</diagnostics>
<services>
<service behaviorConfiguration="MyService.IBusinessObjectServiceContractBehavior"
name="MyService.BusinessObjectService">
<endpoint address="http://localhost:2929/BusinessObjectService.svc"
binding="wsHttpBinding" contract="MyService.IBusinessObjectServiceContract">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="MyService.IBusinessObjectServiceContractBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
My binding details in the Sharepoint site web.config is:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IBusinessObjectServiceContract"
closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00"
sendTimeout="00:01:00" bypassProxyOnLocal="false" transactionFlow="false"
hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288"
maxReceivedMessageSize="65536" messageEncoding="Mtom" textEncoding="utf-8"
useDefaultWebProxy="true" allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
algorithmSuite="Default" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:2929/BusinessObjectService.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IBusinessObjectServiceContract"
contract="BusinessObjectService.IBusinessObjectServiceContract"
name="WSHttpBinding_IBusinessObjectServiceContract">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
</system.serviceModel>
I am able to view the WCF (and its wsdl) in browser, using the URL given in the end point. So, I guess the URL is definately correct. Please help !!!
I've replicated your code and it runs correctly for me, but there are a couple of discrepencies.
Firstly, the server side configuration you've supplied is not complete. The endpoint mex fails because I don't have the IMetadataExchange contract. When you browse to the WSDL, this is presumably the endpoint you are viewing.
I'm just removing this endpoint altogether. Following from this, I'm specifying an address for the serviceMetadata element in the behavior like this:
<serviceMetadata httpGetEnabled="true" httpGetUrl="http://localhost:2929/BusinessObjectService.svc?wsdl" />
Not ideal but it works to let me discover the service. Then my generated client config file is the same as yours, except...
Secondly, I have messageEncoding="Text" instead of messageEncoding="Mtom"
Try changing messagingEncoding to Text. You haven't specified on server side that it should be Mtom so I don't understand why it has been generated on client side as Mtom.
Apart from these two issues my configuration is the same as yours, and it runs without a problem. I'm not sure that the second issue I've identified is a real issue at all (I can't see how the metadata exchange would give the wrong message encoding), but the first issue is stopping the service from running on my side.
I got an error that looked almost identical as the described error. However my error was a 503 and I was calling a web service on an external server.
When I called the service from a standalone app I had no problems, but when I called the service from a web part in SharePoint it failed.
Solutions that worked me, without any further explanation because I haven't really digged into why it works (If you know, please enlighten me :))
1st solution that worked for me was to use my own domain account instead of the service account for the application pool that was used by the SPWebApplication.
2nd solution was to set the service binding attribute UseDefaultWebProxy to false
UseDefaultWebProxy = false
Of course these solutions depends on your proxy settings and user settings. My proxy settings was setup to bypass proxy for the service I was calling, so my suspicion is that the proxy settings (configured here: IE->Internet Options->Connections->LAN settings) doesn't apply to the service account but only to the logged in user. By now, this is what I'll investigate more.
EDIT 1:
Hmm. that was actually not bringing anything new to the table, I used psexec to view my proxy settings as the service account (netsh->winhttp->show proxy) and that looked correct, so I don't think this could be the issue.
EDIT 2:
Final solution, so the problem was that my SP web app was not using the proxy settings I had setup in IE when the app pool was run in the context of a service account, when I used my user account for the app pool I had no problems and the proxy settings in IE was used. After a little more investigation it appeared that I could define proxy settings for my SPWebApplication in web.config and I chose just to disable the proxy
<system.net>
<defaultProxy enabled="false" />
</system.net>
I have a WCF service method in a Silverlight application that inserts some data into a SQL Server database deployed on a shared GoDaddy server. Some of the methods work, and some do not, but all of them work when the application is run locally (with a local database). I get the generic "The remote server returned an error: NotFound", and I can't seem to get any more info. When I run the method directly from the service class (not through the service reference), it works correctly. Here is the service part of my web.config:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<behaviors>
<serviceBehaviors>
<behavior name="default">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<dataContractSerializer maxItemsInObjectGraph="6553600" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IncreasedBuffer"
maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="2147483647">
<readerQuotas maxBytesPerRead="2147483647" maxDepth="2147483647"
maxArrayLength="2147483647" maxNameTableCharCount="2147483647"/>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="GreekTools.Services.DataService"
behaviorConfiguration="default">
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IncreasedBuffer"
contract="GreekTools.Contracts.IDataService" />
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
Any ideas?
Could it be that you have an older version of the dll deployed on the server side. That would explain why some work and some do not.
If this is not the case, is there any pattern in what works and what does not?
This is usually the case when you attempt to do a request on a url that does not exist. For example, you expect a service to be at http://hostname/path/Service.svc but it actually lives at http://hostname/Service.svc.
Your best course of action is to download a web debugging tool (Fiddler is a good choice) and check the actual requests that are sent from your Silverlight client to your web server. Very probably you'll see some problem with a url path that's incorrect.