I know this has been an issue for years, but I am hoping for a recent solution other than abandoning WCF for Webrequest since none of the questions going back 5-7 years fix the problem.
If one removes the mustUnderstand attribute from the SOAP envelope captured in Fiddler, and drop it into SoapUI a response is received.
The WCF/WSDL mustUnderstand=1 setting is rejected by a partner's server beyond my control with a "Generic error occurred" fault. I have not found any recent settings that allow me to control it, and the vendor (Aperia) has no interest in addressing it, even though they included it in all of their documentation.
I've spent a few hours trying to port the https request to a webrequest, and hate to abandon WCF for this.
Related
I have implemented message layer security using message inspector mechanism in a wcf service.
On the client side, in IClientMessageInspector.BeforeSendRequest I add an authentication header.
On the service side, in IDispatchMessageInspector.AfterReceiveRequest I inspect the authentication header in the message. If it is not found or as expected, I throw a SecurityException and try to log it to a database.
Here comes the interesting part. When logging to database, I try to read from this webservice again (this is web service which provides configuration info).
This is where the service stalls/deadlocks. I can see that the call to read configuration (when logging to db) is made, but I don't receive the call on the service. I keep getting a timedout exception every time.
After a little googling, I came across this post, which mentions that message inspectors are synchronous in nature. If that is so, how can I achieve what I am after?
I have a peculiar problem with client requests randomly not getting a response to a WCF service call.
The setup is a Silverlight 5 application making calls to a WCF service, using both HTTP and PollingDuplex bindings. The SL makes a number of requests upon loading (20+ in 20s), and every now and then does not receive a response to one or two of them. To be clear, the exact same request works 90% of time, if I refresh the page all requests could get a response.
The error cannot be the actual request sent. I use Fiddler to validate this as well, since I see the request being made (make sure the content is the same as previous successful requests), but there is no response to the request. Eventually the client times out the request. The WCF service is hosted in IIS7, and I have diagnostics and logging enabled on both. In the WCF server trace logs, I only see message logged when the client times the request out. It has the following exception action logged under a "Processing message" activity, at the time of the client timing out:
"The number of bytes available is inconsistent with the HTTP Content-Length header. There may have been a network error or the client may be sending invalid requests."
This is as if the body of the HTTP is not getting through to WCF (I do not know if I can log the full request received by IIS before passing to WCF handlers?). As I said, using Fiddler I can see the full message is valid (note that this behaviour also occurs when Fiddler is not sniffing the traffic, so I've ruled Fiddler out as the problem).
Typically the "Processing message" activity has a "To: Process action xxx"
Like I said this occurs with Http and PollingDuplex services, on my dev box as well as production web servers. Occurs on different endpoints as well, and I don't think it has to do with WCF throttling behaviour, since it occurs
Any information or help will be appreciated to get to the cause, whether it's additional information I can gather to help diagnose or any hints.
I have a Silverlight application which uses WCF RIA services and WindowsAuthentication mode. When I deploy to our web server calls that are greater than 20 seconds in length seem to lose authentication and I get a dialog box from IE to re-enter my username and password.
Does anyone know how to fix this issue?
UPDATE: I found out that the issue had nothing to do with what Fiddler was indicating and the authentication dialog was a side effect of another issue.
When I turned on WCF diagnostic tracing I found that what was really happening was that the service was throwing an exception due to the max number of items in graph. My bindings in my web.config to override the service had an old service name so it was not picked up.
Based on this I would highly suggest that anyone having an issue turn on WCF diagnostic tracing on the web server and see what that says before following an error out of fiddler...
Thanks for the response to the post and your will to help out...
I think it should be caused by the timeout issue, take a look at following link:
receiveTimeout
Hope it help you. If it doesn't work, you may try to look at other timeouts, for example inactivityTimeout in reliable session.
I am working on a bug we have encountered in one of our web services. We are using Axis2 1.4.1 running on OC4J. The issues is that when sending multiple signed binary attachments to the service with MTOM, the service only gets one of the attachments. If I disable WS-Security and send the same request to the web service, all the attachments get through. This seems to only happen when MTOM "determines" the attachments are large enough to warrant breaking them out into separate MIME sections. If they are quite small, then MTOM just base64encodes them and leaves them inline and all data gets through.
All the request SOAP Xml is produced correctly. That is, all the multiple attachments are being sent to the service and all the MIME boundaries are present and all the XOP includes are in place, as I have snooped the requests with Eclipses TCP/IP Monitor and also with the output provided in SOAP Sonar.
Has anyone else run into an issues when trying to send signed content to an Axis2 web service?
I found the answer, sort of, on my own question after spelunking through many JIRA tickets on the AXIS2 JIRA. The fix, or work around actually, is described in AXIS2-4973. Using the method described, Axis2 seems to generate the code the parses multiple MTOM attachments correctly.
It seems that WCF diagnostics is not available in SL. Is it because of limited System.Diagnostics support or something else? Anyway, how do you track client-side WCF issues when server-side diagnostics is not enough?
This is how I solved my problem of correctly obtaining exceptions at the Silverlight Client. Similar to Rus' but does not require wrapping of exceptions. Though it does require the version number to be exact in web.config (still working on solving that)
Programmatic configuration of Exception-sending in WCF
I think this article will help.
http://msmvps.com/blogs/theproblemsolver/archive/2009/01/27/returning-exception-information-to-a-silverlight-client-through-wcf.aspx
If you're getting a 'Not Found' Error the most likely cause is the cross domain access policy. What I use to try diagnose those problems is Fiddler2, and look at the raw traffic.
Are you sure that your WCF service is not faulting on the call? If something is going wrong on the server-side the returned message will be of HTTP status code 500. Due to security restrictions, the browser will not pass any non-200 messages back to the silverlight plugin which results in silverlight throwing the classic CommunicationException "The remote server returned an error: NotFound."
There are some pretty well documented work-arounds for using a WCF behavior to change the HTTP status code on the fault from 500 to 200 so silverlight will actually have access to the details of what went wrong. More info here:
http://msdn.microsoft.com/en-us/library/dd470096(VS.95).aspx
http://www.netfxharmonics.com/2009/07/Understanding-WCF-Faults-in-Silverlight-3