I'm learning WCF and have the following code working in my dev environment using visual studio 2008 and its web server. When I publish the web service to IIS 6, all requests result in 400 "Bad Request" error. Looking at the IIS log, the status code is 400 and the win32-status code is 1380. Using net helpmsg 1380
, it tells me that wind32 status code means "Logon failure: the user has not been granted the requested logon type at this computer." But I'm using webHTTPBinding for REST which doesn't use authentication or security method.
In IIS, I have the application set to allow anonymous which is set to impersonate "IUSER_<machine_name>" account. In the application pool, I have it set to use the Network Service identity. Both users are setup to write access temp folders as well as the .net framework folders. I've setup WCF tracing, but the logs are blank. I'm banging my head against the wall. Can someone please help?
System.ServiceModel portion of the web.config:
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="web">
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="default">
<serviceMetadata />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="default" name="GTKK.ServiceLibrary.GTKKService">
<endpoint address="" behaviorConfiguration="web" binding="webHttpBinding"
bindingConfiguration="" name="web" contract="GTKK.ServiceLibrary.IGTKKService" />
<endpoint address="mex" binding="mexHttpBinding" bindingConfiguration=""
name="mex" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:1173/GTKKService" />
</baseAddresses>
</host>
</service>
</services>
<diagnostics>
<messageLogging logMalformedMessages="true" logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="true" />
</diagnostics>
</system.serviceModel>
Here's my Service contract:
using GTKK.DTO;
using System.ServiceModel.Web;
namespace GTKK.ServiceLibrary
{
[ServiceContract(SessionMode=SessionMode.Allowed)]
public interface IGTKKService
{
[WebGet(UriTemplate = "artist/{id}/json", BodyStyle = WebMessageBodyStyle.Wrapped, ResponseFormat = WebMessageFormat.Json)]
[OperationContract]
ArtistDTO GetArtistByID(string id);
[WebGet(UriTemplate = "artists/json?namefilter={namefilter}", BodyStyle = WebMessageBodyStyle.Wrapped, ResponseFormat = WebMessageFormat.Json)]
[OperationContract]
List<ArtistDTO> GetArtistListByNameFilter(string nameFilter);
[WebGet(UriTemplate = "localevents/json?search={searchText}", BodyStyle = WebMessageBodyStyle.Wrapped, ResponseFormat = WebMessageFormat.Json)]
[OperationContract]
List<EventDTO> GetLocalEventsBySearchLocationJson(string searchText);
[WebGet(UriTemplate = "localevents/xml?search={searchText}", BodyStyle = WebMessageBodyStyle.Wrapped, ResponseFormat = WebMessageFormat.Xml)]
[OperationContract]
List<EventDTO> GetLocalEventsBySearchLocationXml(string searchText);
}
}
In browser, I use the following URL for testing in my dev environment using VS2008 web server and it works:
http://localhost:1173/GTKKService/localevents/xml?search=98101
After publishing to IIS and use the following url, I get the bad request page:
http://<host_name>/service.svc/localevents/xml?search=98101
I know that the url should be correct as if I put in a faulty url after the .svc part, I'll get an endpoint not found error, which is working the way it should. For example:
http://<host_name>/service.svc/anythinghere
The IIS server box has .net 2, 3.0, and 3.5 installed. The IIS web application is setup to use .net 2 (which will use .net 3.5). I've also ran serviceModelReg /i /x as well as with /ia to make sure WCF is installed and registered. The thing about the "Bad Request" error page is that it's not the IIS error page, it's HTML formatted like a WCF error page with the navy blue bar across the top with the white title "Request Error", followed by the message "The server encountered an error processing the request. See server logs for more details."
Please help.
Problem fixed. Since the error page is WCF generated, I figure that the request must of made it to the service host. But I had event log logging for any error and there were none in the event log. This kinda bugged me. So I added another OperationContract that simply returns the assembly name and version number and no processing of any kind. When called in the browser, the new operation returned the assembly data. Hmmm. So this is working. What is wrong with the other operations? In order to see what's wrong with the data processing for the others, I had to install remote debugging and started the remote debugging process. Came to find out it was the database connection string that's giving the login failure error. I was using Integrated Security for the database connection. I thought it would use the Network Service acct that was setup for the app pool. But to my surprise that when using webHTTPBinding with no security setup, it uses the hidden domain computer acct. Once I got the data connection issue squared away, all operations ran just fine. Also, I found out that my event log logging wasn't working either due to lack of permission to log to the event log. So I never got anything in the event log. That's what threw me off the track to begin with. Well, I'm now a happy camper. :)