I'm calling a SOAP web service using WCF. When the server gots error or turns into maintenance state, it replies with a HTML document. With WCF client an TargetInvocationException will be thrown because the reply is not a soap message.
I want to intercept the HTTP response and do some process (logging for exemple) when the server turns into abnormal state. I tried the IClientMessageInspector with IEndpointBehavior, when the server replies well (even Soap Fault), the method IClientMessageInspector.AfterReceiveReply fires and i can catch the message.
But when the server replies with a HTML document (where i need that method fired), that method did not fired. i just got TargetInvocationException and within that exception i can not get the original http reponse.
Does any one faced the same problem and maybe a solution for this ?
Thanks.
Related
I limited my WCF service to allow requests up to 1 MB. This is done via binding configuration in web.config. This is working fine and client is getting 413 error code back in response. The only problem is the response body is empty. I want to include custom message in response body but I don't find a way to do it as .NET handles it automatically.
Let me know if anyone know how to add custom message in response of large requests.
I am facing an issue while calling SOAP API and getting different responses due to single space between envelope and body i.e:
<s:Envelope><DataRequest> if I request it like this I receive empty SOAP body from server, but if I send it like this:
<s:Envelope> <DataRequest> I receive proper response from server side.
Can anyone suggest what to do in this situation? Should I ask server side dev team to do some changes? If so, what changes should be done?
I have WCF clients that are making some large HTTP Post requests from some potentially slow connections. I want to do some server side work on those requests as soon as I know the URI and QueryString of the request but before the payload actually finishes uploading. The requests are non-streaming.
My understanding is that the AfterReceiveRequest method of IDispatchMessageInspector gets called after the request has been fully received so that doesn't work.
Is this even possible in WCF?
You are right that the message would have been received, but you can still operate or replace the the message in the AfterReceiveRequest.
AfterReceiveRequest is invoked by the dispatcher when a message has
been received, processed by the channel stack and assigned to a
service, but before it is deserialized and dispatched to an operation.
If the incoming message was encrypted, the message is already
decrypted when it reaches the message inspector. The method gets the
request message passed as a reference parameter, which allows the
message to be inspected, manipulated or replaced as required.
It seems you'd prefer to do something server side, but you can also implement the IClientMessageInspector.BeforeSendRequest to inspect and operate on the message just before it is sent out to the server.
BeforeSendRequest is invoked when the message has been composed either
by the client application or by the operation formatter. As with the
dispatcher message inspectors, the message can just be inspected or
entirely replaced.
MSDN Documentation
I'm trying to make a WCF service that will be consumed by other parties by passing a SOAP request to the service. The client requires me to handle a set of FaultExceptions that could happen during the interaction.
This includes that if the client send a malformed Uri in the SOAP request [wsa:To] element, that is if the client for example send a request contains the following:
<wsa:To>http//:this.is.invalid/address</wsa:To>
I should be able to throw a specific FaultException. I tried to implement the IDispatchMessageInspector to capture the SOAP request before it reach the operation but when the client send a request contains a bad Uri like in the above example, the AfterReceiveRequest is not called and so I can NOT handle this type of error.
I couldn't find the error until I've enabled the trace logging for my WCF service and I'm the error
System.UriFormatException, System, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089<br><br>with the description
<br><br>Handling an exception. Exception details:
System.UriFormatException: Invalid URI: The URI scheme is not valid.
The question is how and where can I catch this exception in the Code? Thanks in advance,
The soap header wsa:To should contain the address of the intended receiver of the message. WCF client-side framework enforces this by using the service endpoint address as the value for the wsa:To header element. I'm not sure whether the WCF service-side framework enforces validation of this element since it has already ready received the soap message.
You're seeing the 400 HTTP error because the WCF client is attempting to sent a soap message to an invalid service endpoint. To properly test an invalid wsa:To value you need code that will create the soap XML with an invalid wsa:To value but sent to the correct service endpoint.
If WCF doesn't validate this value, you're approach of using an implementation of the IDispatchMessageInspector should work. Otherwise, if WCF throws an exception before the IDispatchMessageInspector implementation is called then you may need to implement a IErrorHandler endpoint behavior to catch this kind of "in the plumbing" exception. See this great blog post for information on how to implement and configure it.
Perhaps I'm overlooking something, but can client WCF not handle a server response that isn't a 200? For example, I'm trying to consume a service that returns a 400 when you asked for something naughty, but the body of the response is still a perfectly good and consumable SOAP message. It does the same for requested data that doesn't exist, returning a 404 but still having good hints about what the problem is. The WCF proxy seems to just puke and I can't get at the underlying body of the message.
Is that really how it rolls?
The only way to do this is to capture the protocol exception and then manually unserialize the envelope. The channel is hard coded to always throw a fault anytime an non 200 web response.