net::ERR_SPDY_PROTOCOL_ERROR 200

[TehWardy]

I have these entity types ...

[Table("Packages", Schema = "Packaging")]
public class Package
{
    [Key]
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public Guid Id { get; set; }

    [Required]
    [StringLength(100)]
    public string Name { get; set; }

    [Required]
    [StringLength(500)]
    public string Description { get; set; }

    [Required]
    [StringLength(100)]
    public string Category { get; set; }

    [Required]
    [StringLength(200)]
    public string SourceApi { get; set; }

    public virtual ICollection<PackageItem> Items { get; set; }

    public Package() { }

    public Package(string name) { Name = name; }
}

[Table("PackageItems", Schema = "Packaging")]
public class PackageItem
{
    [Key]
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public Guid Id { get; set; }

    [ForeignKey("Package")]
    public Guid PackageId { get; set; }

    // used to determine T for data
    public string Type { get; set; }

    // JSON of the object being imported
    public string Data { get; set; }

    public virtual Package Package { get; set; }

    public T Unpack<T>() { return JsonConvert.DeserializeObject<T>(Data); }
}

And this method in my OData controller ...

[HttpGet]
[EnableQuery]
public IActionResult Export([FromODataUri]int key)
{
    var result = Service.Export(key);
    return Ok(result);
}

When I request it with ...

HTTP GET ~/Api/Controller/Export()?$expand=Items

I get the response ...

net::ERR_SPDY_PROTOCOL_ERROR 200

... The response body appears to be empty.

In the older .Net 4.6 implementation of this same request the response comes back fine.
I'd like some guidance on debugging or fixing this.

I'm using the latest "not preview" builds from github for netcore 2.2 for the aspnet stack and the OData libs and has the following using directives (on top of my own internal dependencies) ...

using Microsoft.AspNet.OData;
using Microsoft.AspNet.OData.Query;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using System.Threading.Tasks;

...

Which have come from Nuget packages ...

Microsoft.NetCore.App 2.2.0
Microsoft.AspNetCore.App 2.2.0
Microsoft.AspNetCore.Razor.Design 2.2.0
Microsoft.AspNetCore.OData 7.1.0

Hopefully this is relevant here as opposed to the OData side but happy to repost there or reference if you guys think this is an OData specific issue.

From the API tester tool in our platform (does what postman does using ajax calls) this is what the .Net 4.6 version does for comparison and ultimately what I would expect form the same code in netcore ...

... Interestingly i notice that there is a response coming back but it appears to be incomplete ...

{"@odata.context":"https://mydomain/Core/$metadata#packages","value":[{"Id":"00000000-0000-0000-0000-000000000000","Name":"Roles"

... It appears to be cutting the response short for some reason (presumably due to some sort of serialization failure and the frameworks resulting behavior from the framework must then be to just end the response.

Is there any way I can catch internal exceptions / issues in the framework to help with this?

I do already have this in my startup ...

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var ex = context.Features.Get<IExceptionHandlerPathFeature>();
        log.Error(ex.Error.Message + "\n" + ex.Error.StackTrace);

        context.Response.StatusCode = ex.Error.GetType() == typeof(SecurityException) ? 401 : 500;
        context.Response.ContentType = "application/json";
        await context.Response.WriteAsync("{ \"error\": \"" + ex.Error.Message.Replace("\"", "\'") + "\" }");
    });
});

... but it's not logging anything which suggests that this might be intended behavior for some reason.

Further information ....

• I have discounted it being a client issue as this happens from multiple browsers.
• I have discounted this as being an EF / ORM issue as the data is computed and contains no actual entities managed by the EF context (although the data has come from EF).
• The code runs completely right through to beyond the Ok() call in the controller which returns a Package[] (see type data above).

[TehWardy]

So I have an extension method in my web stack that I can use to call in to newtonsofts json serializer for any object, it turns out when I do this ....

[HttpGet]
[EnableQuery]
public IActionResult Export([FromODataUri]int key)
{
    var result = Service.Export(key);
    return Ok(result.ToJson());
}

And change this in the OData model builder to ...

Builder.EntityType<App>().Function("Export").Returns<string>();

... it works.
This is essentially pointing to an issue in the serialization process employed by the framework from what i can tell.

Some hints (as i can't really share the data) as to what the issue might be ....

The package items can contain objects in the Data field serialized to a block of json already but those items in a few cases could contain blocks of HTML or javascript which in turn could contain json.

I think this is an issue with nested serialization in json that contains json.

[jkotalik]

In your webhost, are you using Kestrel or IIS? If you are using Kestrel, do you have Http2 enabled?

[TehWardy]

Is Http2 not enabled by default ?
Seems like an odd thing to not do for new framework.

I'm using Kestrel.

[jkotalik]

it isn't enabled by default in 2.2. Will be on by default in 3.0.

[analogrelay]

@TehWardy is it possible an exception is being thrown in your response? If an exception is raised after headers have been sent, you can get something like this since ASP.NET Core can't change the response into a 500 at that point. Server logs should show an error if one is occurring.

Can you provide a runnable sample project that reproduces the issue?

[TehWardy]

@anurse No it's not possible the issue is in my response.
If I use the newtonsoft json serializer to serialize the response object and tell the framework that it's returning a string it works, the whole request and response.

This issue is in the frameworks response handling for complex data.
I can't provide you the full details of the request because it's corporate secure data but I have found the issue is in a response object that contains string properties on either the object or child objects returned.

In my case I have a page object that contains a collection of content objects which are literally containers for some html and some javascript (separate string properties.

The issue I hit was when the javascript / html blocks in the content object contained blocks of json.
It seems to confuse the serializer but the newtonsoft one is able to solve it.

[analogrelay]

So are you getting an exception or not? It's not clear from your description if there is an exception being emitted when rendering your object. Even if that exception is coming from the framework, we would need to know what is being thrown so that we can get a clear idea of what's going on.

I can't provide you the full details of the request because it's corporate secure data but I have found the issue is in a response object that contains string properties on either the object or child objects returned.

Can you share a sample object that reproduces the issue with secure data removed/renamed/replaced? What happens if you serialize this object in a simple Console application? If we can isolate a repro like that, we can report it to the corefx team that owns System.Text.Json.

It seems to confuse the serializer but the newtonsoft one is able to solve it.

There are definitely limitations with the System.Text.Json serializer. Newtonsoft.Json has a number of features that System.Text.Json does not have. If Newtonsoft works for your scenario, you can certainly continue using it.

[TehWardy]

if I do ...

var result = DoSomeBusinesLogic();
return Ok(result);

... then it begins responding and stops about 100 characters in to the json response.
The server literally just ends the response there.

If I do ...

var result = DoSomeBusinesLogic();
return Ok(result.ToJson());

... it returns normally as i would expect but i need it to work without the .ToJson() call.

My business logic runs perfectly fine on both occasions the failure is happening in the framework code after the return of the controller action.

[analogrelay]

That's exactly what I'd expect from a serialization problem. ToJson is provided by Newtonsoft.Json I believe, so it would be using a different serializer. What is the structure of the object you are sending?

Also, I'm still not clear on if an exception is thrown in the first case. I'd expect an exception if the response is being ended abruptly. That exception would have details. Is anything showing up in the logs (either Console if you're using Kestrel or in the "ASP.NET Core Web Server" tab of the Output Window in VS if you're using IIS).

[TehWardy]

@anurse object structure is in the first post of the thread.
As I have said repeatedly ... the response simply stops as if it's done ... i get nothing beyond those first few chars from the json response.

I got married on sunday and i'm about to go off on my honeymoon so i will likely be a bit unresponsive for a bit ... honestly I think this is an issue with encoding complex responses, just make an object that has a string property and put a block of javascript in it or something that deserialzes a block of json (like you might do on a web page) and try that.

If you really can't reproduce it i'll see if i can get you the sample I've had issues with on my return to the office.

[analogrelay]

I built a possible repro and see an exception on the server logs exactly as I'd expect in this circumstance:

System.Text.Json.JsonException: CurrentDepth (32) is equal to or larger than the maximum allowed depth of 32. Cannot write the next JSON object or array.
   at System.Text.Json.ThrowHelper.ThrowJsonException_DepthTooLarge(Int32 currentDepth, WriteStack& writeStack, JsonSerializerOptions options)
   at System.Text.Json.JsonSerializer.Write(Utf8JsonWriter writer, Int32 originalWriterDepth, Int32 flushThreshold, JsonSerializerOptions options, WriteStack& state)
   at System.Text.Json.JsonSerializer.WriteAsyncCore(Stream utf8Json, Object value, Type type, JsonSerializerOptions options, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Mvc.Formatters.SystemTextJsonOutputFormatter.WriteResponseBodyAsync(OutputFormatterWriteContext context, Encoding selectedEncoding)
   at Microsoft.AspNetCore.Mvc.Formatters.SystemTextJsonOutputFormatter.WriteResponseBodyAsync(OutputFormatterWriteContext context, Encoding selectedEncoding)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResultFilterAsync>g__Awaited|29_0[TFilter,TFilterAsync](ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResultExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.ResultNext[TFilter,TFilterAsync](State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeResultFilters()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

The issue I see is that you have a recursive structure where the package item contains a back-reference.

  public virtual Package Package { get; set; }

This is not supported automatically by System.Text.Json (which is why Newtonsoft.Json works). The problem even repros trivially with a sample in a Console application.

You either need to remove this recursive reference, or tell the serializer not to serialize this value by applying the JsonIgnore attribute:

  [JsonIgnore]
  public virtual Package Package { get; set; }

Unless I'm missing something in my repro, that seems to be the source of the problem. I'm surprised you see no exceptions in the server log as it's very clear in my repro. The response will not show an exception because of the issue I mentioned above (the exception occurs after parts of the response have been written). However, there should have been something in the server console logs. Can you share the full server console output/logs as I described above to help investigate why the exception isn't appearing?