HTTP error request error while requesting a WCF service contract

I have a WCF service with the following configuration:

<system.serviceModel> <behaviors> <serviceBehaviors> <behavior name="MetadataEnabled"> <serviceDebug includeExceptionDetailInFaults="true" /> <serviceMetadata httpGetEnabled="true" /> </behavior> </serviceBehaviors> </behaviors> <services> <service behaviorConfiguration="MetadataEnabled" name="MyNamespace.MyService"> <endpoint name="BasicHttp" address="" binding="basicHttpBinding" contract="MyNamespace.IMyServiceContract" /> <endpoint name="MetadataHttp" address="contract" binding="mexHttpBinding" contract="IMetadataExchange" /> <host> <baseAddresses> <add baseAddress="http://localhost/myservice" /> </baseAddresses> </host> </service> </services> </system.serviceModel> 

When hosting the service in WcfSvcHost.exe , if I look at the url:

http: // localhost / myservice / contract

where service metadata is available, I get an HTTP 400 Bad Request error.

Checking the WCF logs, I found that when I called System.Xml.XmlException , I got a message: "The body of the message cannot be read because it is empty."
Here is the extraction of the log file:

 <Exception> <ExceptionType> System.ServiceModel.ProtocolException, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 </ExceptionType> <Message>There is a problem with the XML that was received from the network. See inner exception for more details.</Message> <StackTrace> at System.ServiceModel.Channels.HttpRequestContext.CreateMessage() at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, ItemDequeuedCallback callback) at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore(IAsyncResult result) at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext(IAsyncResult result) at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result) at System.Net.LazyAsyncResult.Complete(IntPtr userToken) at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken) at System.Net.ListenerAsyncResult.WaitCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped) at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP) </StackTrace> <InnerException> <ExceptionType>System.Xml.XmlException, System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType> <Message>The body of the message cannot be read because it is empty.</Message> <StackTrace> at System.ServiceModel.Channels.HttpRequestContext.CreateMessage() at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, ItemDequeuedCallback callback) at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore(IAsyncResult result) at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext(IAsyncResult result) at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result) at System.Net.LazyAsyncResult.Complete(IntPtr userToken) at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken) at System.Net.ListenerAsyncResult.WaitCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped) at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP) </StackTrace> </InnerException> </Exception> 

If I go to the URL instead:

http: // localhost / myservice? wsdl

everything works fine and I get a WSDL contract. At this point, I can also completely remove the MetadataHttp metadata endpoint, and that doesn't make any difference.

I am using .NET 3.5 SP1. Does anyone have an idea what might be wrong here?

+12
wsdl exception wcf
Nov 27 '08 at 11:49
source share
5 answers

I think I found out what the problem is.

If I go to the url:

http: // localhost / myservice / contract

using the WcfTestClient application, I can successfully get the service metadata.
So the error really occurs when I request the url through a web browser.

The HTTP Bad Request error occurs because the browser issues an HTTP GET request, where the message content is in the HTTP headers and the body is empty.
this is exactly what WCF mexHttpBinding is complaining about!

To get a service contract through a web browser, you will have to explicitly include it in the service behavior:

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

The URL for the request will then be:

http: // localhost / myservice? wsdl

So it turns out I posted this question too quickly. However, I will save it anyway just for recording.

+12
Nov 27 '08 at 12:04
source

This is usually a problem with the size of the SOAP shell. Check the binding configuration to modify MaxBufferPoolSize, MaxReceivedMessageSize to provide a huge amount of content. Remember that you must change both the client side and the server side.

Another problem is MessageEnconding (another binding parameter), make sure that the client and server use the same encoding.

Finally, check the Quotas Reader property settings.

+4
Nov 10 2018-10-10
source

I was able to fix the β€œ400 Bad Request” problem by switching the WCF service from starting Visual Studio Development Server to using the local IIS web server (right-click on the project β†’ properties β†’ web tab - β†’ in the β€œServers” section). I hope this helps someone because it took me two days to figure this out.

+3
Mar 18 '10 at 13:24
source

I am having problems with HTTP 400 when using the HTTPS-ΞΌs URL from SvcUtil, while httpsGetEnabled was set to true . The error message was far from what really was the problem, so I am posting here if someone else is facing the same problem.

I had my own CA certificate (TestRootCA), which was the issuer of the server certificate (localhost). On the client, I imported the CER file TestRootCA, but I did not import the CRL (Certificate Revocation List). It seems that when you use a self-signed CA, you must also import the CRL, otherwise server authentication fails in strange ways, none of which indicate a real problem. The worst part is that the error occurs during the establishment of the SSL connection before the request even reaches your service, so you will not see errors in the WCF trace logs.

+2
Mar 26 '14 at 17:36
source

If you do not know why your WCF code is causing an error, I highly recommend MS Trace Viewer. This is very useful in identifying such communication and transport problems. Take a look at C # Corner for more details.

+1
Mar 23 2018-11-11T00:
source



All Articles