WebApiContrib / WebApiContrib.Formatting.ProtoBuf

Web API formatter based on ProtoBuf
http://nuget.org/packages/WebApiContrib.Formatting.ProtoBuf
MIT License
30 stars 19 forks source link

Does not serialize HttpError #2

Closed kwaclaw closed 8 years ago

kwaclaw commented 11 years ago

Assuming content negotiation selects protobuf, then a HttpError object would need to be serialized accordingly. This scenario gets triggered when I return an error response like this:

Request.CreateErrorResponse(System.Net.HttpStatusCode.BadRequest, errMsg);

The problem is that HttpError cannot be serialized by protobuf-net as it has "object" as type parameter, and surrogates cannot be used, because HttpError derives from Dictionary and protobuf-net does not allow surrogates for collections.

Not sure how to fix this.

kwaclaw commented 11 years ago

I tried implementing an ExceptionFilterAttribute that catches most exceptions and turns them into serializable responses. The problem is, a WebApi exception filter is not called for HttpResponseExceptions (which contain HttpError obejcts): see http://www.asp.net/web-api/overview/web-api-routing-and-actions/exception-handling .

I think this is a showstopper.

panesofglass commented 10 years ago

Interesting. I hadn't seen that behavior before. Web API 2 may address this better. I'm not entirely sure how to fix this at the moment.

JaredProske commented 9 years ago

This is an issue for me too. Any ideas how to fix it?

kczyk commented 9 years ago

I've had the same problem. InvalidOperationException raised when WebApi controller returned HttpError from method.

I've solved it by copying ProtoBufFormatter class to my project and changing function:

private static bool CanReadTypeCore(Type type)
{
    return true;
}

to

private static bool CanReadTypeCore(Type type)
{
    if (type == typeof(System.Web.Http.HttpError))
        return false;
    return true;
}

In effect ProtoBufFormatter skips serializing HttpError object and it's passed to next available formatter.

I'm not sure if its full solution to this problem. It works for now.

JaredProske commented 9 years ago

We did something similar.

filipw commented 8 years ago

this is resolved in #7

ProtoContractAttribute is mandatory on the return type

hastarin commented 7 years ago

This is closed but no new NuGet package has been published. Is there any chance we'll get a new one with this fix included?

hastarin commented 7 years ago

NOTE: I copied the current code into my project and now a simple List within a type prevents it from being available.

I have personally settled on the solution shown here for the time being: http://stackoverflow.com/a/34532406