I am trying to throw an HttpResponseException(HttpStatusCode.NotFound) and I am getting the following error
The response message returned by the Response property of this exception should be immediately returned to the client. No further handling of the request message is required.
I have removed all of the code in my method and I am just throwing the exception like this
[WebGet]
public MyData Get()
{
throw new HttpResponseException(HttpStatusCode.NotFound);
}
If I change my method to return a HttpResponseMessage I can get it to work correctly, however it does not solve the issue and I am unable to get my authentication operation handler to work without being able to throw a HttpResponseException.
Try using a WebFaultException for returning HTTP Status codes in WCF...
throw new WebFaultException(HttpStatusCode.NotFound);
Related
I can't seem to figure out how to handle NULL (404 Not Found) on the client when calling an OData function for a given Entity.
Ex> calling service like "Context.Objects.ByKey(1).SomeFunction().GetValue()"
I want to get "NULL" from the service but instead on the client it throws a 404 Not Found exception.
If I alter the service to return "NULL" then I will receive a serialization exception on the server and if I tell the server to return "OK(null)" I will also get a serialization exception.
Here is the server code for the controller
[HttpGet]
public IHttpActionResult SomeFunction([FromODataUri] int key)
{
string something = null;
// Do some check and adjust the variable "something"
if (string.IsNullOrWhiteSpace(something))
{
return NotFound();
}
else
{
return Ok(something);
}
}
And here is the WebApiConfig code
builder.EntityType<SomeObject>().Function("SomeFunction").Returns<string>();
I can't seem to find the "proper" way of handling null values from the odata service when using Microsoft OData client.
Maybe I can wire into the client "ReceivingResponse" event to handle the 404 Not Found some how? Any suggestions...
The default behavior of the OData client is to throw an exception when the OData service returns a 404 File Not Found.
To get around this there is a property on the OData Client generated code called "IgnoreResourceNotFoundException".
Set this property to true and it with not throw an exception.
I'm creating an HTTP API using ASP.NET Web API. I've noticed that if an exception occurs that I haven't handled, that behaviour is very different to if I deliberately throw an HttpResponseException. This will make it hard for clients to reliably handle an error and display the "reason" message.
Eg consider this code:
[HttpPost]
public void ThisWillThrowAnError()
{
try
{
var i = 0;
var b = 1 / i; // cause divide by zero exception for testing
}
catch (Exception ex)
{
HttpResponseMessage message = new HttpResponseMessage();
message.ReasonPhrase = "Error: " + ex.Message;
throw new HttpResponseException(message);
}
}
This creates a response which has the error in an HTTP header and the response code set to 500:
Error: This request could not be processed. Attempted to divide by zero.
The actual response body is empty.
However if I remove the try/catch block, or if an exception occurs for which I do not manually throw an HttpResponseException, I get totally different behaviour. Although the status code is still 500, the header message just says "Internal Server Error" and the message is encoded in a JSON format like this:
{
"Message": "An error has occurred.",
"ExceptionMessage": "Attempted to divide by zero.",
"ExceptionType": "System.DivideByZeroException",
"StackTrace": " at ProjectName.Controllers (etc....)"
}
I think I prefer the latter as it gives you more info for debugging but it removes the ability to customise the message or provide a user-readable message for the problem.
Why is WebAPI inconsistent with how it handles exceptions? Am I doing something myself to cause this inconsistency? It just seems rather messy and difficult to work with and may mean that the calling application will have to be coded to handle two different types of error response :(
When creating error responses, consider using HttpRequestMessage.CreateErrorResponse to create error responses that are consistent with the ones WebAPI sends.
This blog post should hopefully help:
http://blogs.msdn.com/b/youssefm/archive/2012/06/28/error-handling-in-asp-net-webapi.aspx
I would use message handlers. A message handler is a class that receives an HTTP request and returns an HTTP response. So you can basically change response structure in one place, and have same response for success and failure, and for all requests in your Web Api. You can read about it in my blog post: https://www.vladopandzic.com/asp-net-web-api/building-consistent-responses-asp-net-web-api/
Scenario is a Silverlight client using Wcf service & custom authentication. To mitigate the 500/200 status code problem (avoid EndPointNotFound exception) I've applied the SilverLightFaultBehaviour. However, this does not work with UserNamePasswordValidator - When a FaultException is thrown from Validate(), it is not caught by the SilverLightFaultMessageInspector's implementation of BeforeSendReply.
So far, the only workaround I've found is using the alternative client stack instead ( WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);), but there are complications with using it which can no longer be ignored as a lot of our clients are on virtual machines, the silverlight client keeps crashing ( Silverlight 5 - Debugging npctrl.dll crash , http://communities.vmware.com/thread/394306?tstart=0 ).
My primary motivation is that I want to be able to distinguish a failed login from a connection error (the following code is from a client-side async callback method, and only works with the Client stack):
if (e.Error is MessageSecurityException)
{
this.HasLoginFailed.Value = Captions.Login_FailedLogin;
}
else
{
this.HasLoginFailed.Value = Captions.Login_FailedConnection;
}
Is there any other way of modifying the message sent when throwing a FaultException from UserNamePasswordValidator? Or any conceptually different way of doing custom authentication rather than what I am using which enables me to modify the message status or to keep it 200, or just to be able to distinguish a connection failure from bad credentials?
my server-side code for usernamepassword reg:
var serviceCredential = host.Description.Behaviors.Find<ServiceCredentials>();
serviceCredential.UserNameAuthentication.UserNamePasswordValidationMode =
UserNamePasswordValidationMode.Custom;
serviceCredential.UserNameAuthentication.CustomUserNamePasswordValidator =
new MyValidator();
When you throw a FaultException from MyValidator, it is wrapped as the InnerException of a MessageSecurityException, that's probably why you weren't able to catch it directly as a FaultException.
To add some information to the fault you are throwing, what you can do is adding a FaultCode:
throw new FaultException(
"Invalid user name or bad password.",
new FaultCode("BadUserNameOrPassword")
);
Then, catch the exception client-side and retrieve your FaultCode:
try { ... }
catch (MessageSecurityException e)
{
FaultException fault = (FaultException) e.InnerException;
String faultCode = fault.Code.Name;
// you can now display a meaningful error with the faultCode
}
I hope it will help!
I'm using the WebChannelFactory<> to create a channel and interact with a WCF REST Service.
When there is an error, I want to retrieve the response from the channel to read the error message from the body of the response. But I cannot figure out how to get the response stream.
Here is my code:
using (var cf = new WebChannelFactory<T>(new Uri(url)))
{
var channel = cf.CreateChannel();
using (new OperationContextScope(channel as IContextChannel))
{
WebOperationContext.Current.OutgoingRequest.Headers
.Add("x-st-authtoken", HttpUtility.UrlDecode(Constants.General_AuthorizedToken));
WebOperationContext.Current.OutgoingRequest.Headers
.Add("x-st-tesskey", HttpUtility.UrlDecode(Constants.General_SessionKey));
try
{
a(channel);
}
catch (Exception ex)
{
throw new Exception("Status: " + ((int)WebOperationContext.Current.IncomingResponse.StatusCode).ToString());
}
}
}
In the catch statement, I want to include the data from the Response body...
It seems like an obvious thing, but I can't seem to find any information on the internet or anything.
Is there any specific reason for you to use ChannelFactory to interact with the REST service. I think it is easier to use HttpWebRequest object to invoke the REST service and there you can get the respone stream when an error is throw on the server.
Also check out RestSharp API through which you can achieve your task to read the response stream.
I believe it will throw a WebException.
so if you explicitly catch that type you can get use the WebException.Response property (which is an HttpWebReponse) on the exception and you can get the content from its stream.
I have a WCF service configured to use custom UserName validation via the overriden Validate() method of the System.IdentityModel.Selectors.UserNamePasswordValidator class.
All methods of the contract have been decorated with the FaultContractAttribute to specify a custom SOAP fault as being returnable.
When throwing FaultException<T>, where T is the type specified in the FaultContractAttribute, everything behaves as expected and I get the custom fault in the response XML.
However, if I try and throw FaultException<T> in the overriden Validate() method of the username authentication class, I get a generic SOAP fault with the following reason:
"The creator of this fault did not specify a Reason."
However, if I change the code to throw the general SOAP fault as in:
throw new FaultException("Authentication failed.");
I will at least get "Authentication failed." in the reason element.
My questions are:
Why aren't the FaultException<T> exceptions treated the same if they're thrown in the Validate() as they are within the service implementation?
Is it possible to have exceptions thrown in the Validate() method conform to the FaultContractAttribute specified on the contract methods?
Any help greatly appreciated. My own guess is that the authentication comes before the message is associated with any method of the contract, and therefore, is not associated with the FaultContractAttribute, but any article confirming this and giving a workaround would be very useful.
Tali
It's a bit annoying but I got round it by doing this:
SecurityTokenValidationException stve
= new SecurityTokenValidationException("Invalid username or password");
throw new FaultException<SecurityTokenValidationException>(stve, stve.Message);
Including the message additionally means that you don't get the silly "did not specify a reason" message.
The problem is that the custom validation code is running outside of the context of any specific OperationContract, so there is no FaultContract is place for WCF to handle. So the short answer is no, you cannot get the exceptions thrown from your custom validator to honor the FaultContract.
You have a few options here. The one I prefer is to throw the non-generic FaultException and provide a pre-determined FaultCode; this way my catch blocks can differentiate contract faults from "plumbing" faults. Note that any exception you throw from a custom validator should come back as a MessageSecurityException, as shown below:
// Custom Validator:
public override void Validate(string userName, string password)
{
throw new FaultException(
"Invalid username or password.",
new FaultCode("AUTHENTICATION_FAILURE"));
}
// Client Code:
try
{
client.DoSomething();
}
catch ( MessageSecurityException ex )
{
var inner = ex.InnerException as FaultException;
if (inner != null && inner.Code.Name.Equals("AUTHENTICATION_FAILURE"))
{
// Security failure.
}
}
catch ( FaultException<SomethingFault> ex )
{
// Exception from the method itself.
}