Why would an SSL/Basic Authentication WCF service start throwing a 404? - wcf

I have a WCF service that has been working flawlessly for 3 months. It is consumed by local clients on the same server hosting the WCF service and local network clients. It uses SSL and basic authentication for security.
A few nights ago, the local client (local network clients not affected) started receiving 404 errors whenever it tried to use the service. I am able to open a browser on the server hosting the WCF and view the WSDL and even call the "put" command and get the expected "method not allowed". I have confirmed that no software or hardware changes have been made to the hosting server. I have confirmed that the SSL key is valid. I have confirmed that the permissions for the Application Pool are sufficient. I have confirmed that no firewall is running. The only thing odd is the IIS log showing that the first post does not contain the basic authentication user. However, the next line in the log does and shows a 200 response. I am not entirely sure that log is not normal. See below. I was hoping somebody could give me another place to research to find the problem. Please let me know.
2010-08-28 10:30:03 192.168.100.100 POST /protected/Service_Name_Here.svc/put - 443 - 192.168.100.100 - 401 2 5 2
2010-08-28 10:30:03 192.168.100.100 POST /protected/Service_Name_Here.svc/put - 443 User_Name_Here 192.168.100.100 - 200 0 0 5
EDIT: The local client that is throwing the error is transferring large files to the WCF service. The local network clients are transferring small files and not throwing the error. I found this link that suggests that the default transferMode="Buffered" will throw a 404 for files above 20 MB file. The fix for this person was to change the transferMode="Streamed". However, the "Streamed" setting only allows 1 parameter to be passed to the WCF service. I have multiple parameters so I need to find a fix for "buffered" mode.

The fix for this person was to change the transferMode="Streamed". However, the "Streamed" setting only allows 1 parameter to be passed to the WCF service. I have multiple parameters so I need to find a fix for "buffered" mode.
Sounds like that's the correct fix, however the caveat is that streamed mode requires custom message contracts; you can't use the "RPC" style that WCF pushes as a default for operations. If you need to provide more than one parameter in a streamed mode transfer, simply add them to your custom message contract.
Here's a nice discussion on the subject from Microsoft.

If you have problems with message size be aware that there are 3 levels of configuring accepted request size for IIS:
WCF - default max message size 65KB (maxReceivedMessageSize)
ASP.NET runtime hosting WCF - default max request size is 4MB (maxRequestLength)
IIS 7 with request filtering installed - default max request size about 28MB (maxAllowedContentLength)
If WCF rejects your message you will probably get meaning full error but for ASP.NET and IIS you will get exactly HTTP 404.
Streaming will not help you unless you change your operations.

Related

HTTP Error 404.0 - Not Found when accesing SVC service

I have REST service application which is hosted in an IIS 8 in a Windows 8 PC. When I request the service I am getting an error as follows ... HTTP Error 404.0 - Not Found.
Here is the detailed error message.
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Most likely causes:
•The directory or file specified does not exist on the Web server.
•The URL contains a typographical error.
•A custom filter or module, such as URLScan, restricts access to the file.
Things you can try:
•Create the content on the Web server.
•Review the browser URL.
•Create a tracing rule to track failed requests for this HTTP status code and see which module is calling SetStatus. For more information about creating a tracing rule for failed requests, click here.
Detailed Error Information:
Module IIS Web Core
Notification MapRequestHandler
Handler StaticFile
Error Code 0x80070002
Requested URL http://IP.com/Wining/RService.svc/general
Physical Path C:\inetpub\wwwroot\Wining\RService.svc\general
Logon Method Anonymous
Logon User Anonymous
Any help on this would be greatly appreciated.
There are myriads of possible causes. In general, the target resource at given URL is not found, so it may be simply missing, misconfigured, not started, etc. First - check the server logs, they usually contain more detailed information about the issue.
Also, please doublecheck that the service really is up and running. Connect to the www server and check it via localhost not ip.com.
I'm not an expert, but judging from the snippet you provided, it seems to be WCF service, the Handler: StaticFile seems very odd. It seems like the IIS misinterpretes your request as a StaticFile (a resource read from the disks and just passed-through without any further processing) which for me seems perfectly wrong.
You may have not installed the service properly, or have url mappings and/or handlers messed up, or you may even have NET/ASP framework not properly installed.. What have you installed first? .Net or IIS?
check similar questios, there are many.. for example:
WCF on IIS8; *.svc handler mapping doesn't work
HTTP 404 when accessing .svc file in IIS
I had to enable HTTP Activation in .NET Framework 4.5 Advanced Services > WCF Services (running on WIndows 2012) and after an IISReset it worked fine.

Response 400 (bad request) when invoking WCF service with other user than Administrator

I have a simple WCF service (hosted in Server01) which I've been using with no problems. After installing in this particular server (lets call it ClientServer01), I started to get the response 400.
So we have the following two cenarios.
Call WCF service from ClientServer01 from myApp.exe running as Administrator - Works
Call WCF service from ClientServer01 from myApp.exe running as CustomUser - Crashes
Aditional data:
ClientServer01 uses a proxy that is inside it's network to communicate
I'm able to ping Server01 from ClientServer01 using cmd running as Administrator and CustomUser both
Already tried setting expect100Continue="false" as described here
I've made MyApp.exe to isolate the problem and for debugging purposes, the real application is an IIS website in ClientServer01
The service is not a big deal. Pretty basic unsecured WCF service with BasicHttpBinding
Before asking, I tried to analyse the request with fiddler, it worked, because the component that was really making the request was fiddler. Today I tried it again, but running fiddler as mycustom user here is the output:
ERROR
The requested URL could not be retrieved
The following error was encountered while trying to retrieve the URL:
/MyServiceAppName/MyServiceName.svc
Invalid URL
Some aspect of the requested URL is incorrect.
Some possible problems are:
• Missing or incorrect access protocol (should be “http://” or similar)
• Missing hostname
• Illegal double-escape in the URL-Path
• Illegal character in hostname; underscores are not allowed.
Your cache administrator is webmaster.
Generated Mon, 27 May 2013 13:58:09 GMT by fw3.companyhostname.com.br
(squid/3.1.11)
Am I missing some server, proxy or WCF configuration that would allow CustomUser to make an http request thought port 80 to a basic WebService?
Thanks
CustomUser's proxy was not configured. So UseDefaultWebProxy would refer to an invalid proxy.
There are some solutions to this kind of problem
Set target user proxy settings (the most appropriate IMO)
Set binding ProxyAddress property
Set default app proxy in .config file tag configuration/system.net/defaultProxy/proxy <proxy proxyaddress="http://ip:port" />

WCF message: protocol in To element changes

I have a WCF service to consume in .NET. As per requirement the Action element in the header has to be "http://abc" and the To element has to be "ws://xyz" in order for the service to recognize and respond to the request. The soapAction of the operation is however blank in WSDL and it can't be changed.
My service configuration built programmatically is this:
text message encoding binding with Soap11 envelope version and WSAddressing10 addressing version
no security biding
http transport binding
The setup I found achieving this requirement is "ws://xyz" as the endpoint URL and Request.Headers.Action set to "http://abc" in BeforeSendRequest using a message inspector added using an endpoint behaviour attached to the endpoint. Then I also attach a ClientViaBehavior with the URL of "http://abc".
On my development machine this causes as required
<a:Action>http://abc</a:Action>
<a:To>ws://xyz</a:To>
However on the test server it generates
<a:Action>http://abc</a:Action>
<a:To>http://xyz</a:To>
I don't know exact configuration of the server but I believe it is Windows server as is my development box. Does the same code generates different messages on two different machines or how else would I achieve this? I should also say it worked fine for several weeks and stopped last Monday.
I have found the following later:
The test server has .NET 4.5 on it as well as another machine I tried it on (also failed). The dev machine where it works fine has just .NET 4.0 on it which would suggest it could have something to do with it. However I have no evidence it is caused by .NET 4.5 as it was installed several weeks before the problem appeared. Moreover there have been no Windows updates since it stopped to work!
I've also tried to set the To element in my ClientMessageInspector implementation but the protocol still gets flipped to http.
I think the BeforeSendRequest is not called due miss configration of your service bindings. Check if you have added the the extention configuration to you service endpoints you want to have the behavior.

Debugging HTTP 500 (Internal Server Error) in WCF Service / Staging

I have some WCF services which are running great locally; client can consume them and the server is putting data in the DB as expected. The problem is that when I deploy these to a staging machine, all I can see are HTTP 500 errors.
How do I start debugging the problem?
Given that it's only on staging and not on my local dev machine, I assume it's an IIS configuration problem somewhere.
When I use Fiddler to see what's being sent and what the response is, I can see (as expected) correct request data, and only a 500 as the response -- no further details.
I'm pretty green to WCF and IIS, so it's probably something obvious; I've used aspnet_iisreg, deployed my .svc file and all the built DLLs/files from bin; maybe I missed something.
I looked in the IIS logs, but they're pretty skimpy; no error information there, either (or maybe I'm looking in the wrong place?)
(More important than solving the specific problem is figuring out how to see enough details about errors so I can work through problems myself.)
Edit: I of course checked the event logs first -- and surprisingly, didn't find any mention of the exceptions. So I assume that the service is at least being invoked, and that something is faulting in the middle.
The first place to look for errors is event log on the server. There should be basic information why request was not processed. If it is WCF related you can turn on WCF tracing and check for more details in generated logs.
Add:
<httpErrors errorMode="Detailed"/>
In Web.config under:
<system.webServer>
And see what's happening in more details.
'Http 500 Internal Server Error' might occur if your Service Account's password got expired. Please make sure that you don't have any issues with Service Account which is running the app pool on IIS.
It turns out that the server was returning a 500 because of a huge dataset returned; WCF puts some limitations on the size of data (and strings) you can return, to prevent DOS attacks. I solved the problem by increasing the limits, and decreasing the size of data returned (where applicable).

HTTP Metadata Requests with WSIT/JAX-WS

I have a problem running a Java (using Metro) client against a .NET STS and secured web service. However, when I run my .NET based client, it always works.
As you probably already know, when a JAX-WS client is ran, it requests metadata from the service during runtime (even though it already has ran wsimport during design time). However, it seems that this runtime metadata request is where my problem is.
The problem that I'm facing is that during the runtime requests of metadata, some WSDL's exported by my WCF service caused the Java client to just 'hang' during the mex requests. When it hangs, it doesn't even get to the point of issuing the RST request.
For example, I can get to a spot where I have 9 [OperationContract] attributes and it works. But when I add a 10th service method, it doesn't work. However, if I remove one of the 9, then it works. I know there isn't a problem with a particular method because I can mix and match and the same pattern holds.
I can't seem to deduce a pattern or reason for why some WSDL's work and some don't. I strongly doubt there is a limit to the number of service methods. However, could this be a problem with "overall complexity" with the exported WSDL?
Does anyone have any ideas? Have anyone run into this issue before?
If more information is needed, I can glady post it. I'm just trying to keep the initial post a manageable length.
I will also add that I'm running the STS and secured web serivce in .NET 4, and they are based on WIF (so I don't have to worry about security settings). My .NET client is also .NET 4. On the Java side, I'm using Netbeans 6.9.1 with Metro 2.1 running Glassfish 3. I've verified that I receive the same issue running on Metro 2.0.
Please see WSDL Requests with Metro/JAX-WS/WSIT During Runtime for a detailed answer.
Following the example given, there're chances that MaxMessageReceivedSize or MaxStringContentLength limit is reached. Have you tried increasing the values of MaxMessageReceivedSize and MaxStringContentLength for binding? You can try enabling WCF traces, there'd be a warning logged if any such limit is reached.