Bryce Anderson

This is up next on the docket. The big question is: do we bring it all the way back, or just provide a path forward for http4s?

Indeed, my first order idea I was a `Command` will be pushed down the pipeline since this is not a HTTP only feature. In my minds eye, the alternative is...

Indeed, this is a problem. I don't think the line noted above my @jfwilson is actually a problem: a `ClientParser` alone cannot know the nature of the request for which...

I'm excited to get someone familiar with this code, so I'm happy to help as I can. My first inclination would be to thread a flag (something to the spirit...

I'm happy that the original issue is solved in http4s propper, but this is still technically a bug for the blaze library. Specifically, the same exact changes need to be...

It's only reproducible when running the tests `test-only *ServerSpec` in the `blaze-http` package, and it seems to pop every time. This consists of two different tests, `Http1ServerSpec` and `Http2ServerSpec`, both...

A particularly interesting thing about that trace is that it seems that the `ThreadLocalTrampoline` has become re-entrant somehow.

It looks like the exception is happening on the client side of things: moving the server to NIO1 still shows the stack trace originating in nio2.

And since it's happening in those two tests, the HTTP/1 test uses the async-client, so it must be happening in the HTTP/2 client.

I've been able to change the `ExecutionContext` to `directec` in `PriorKnowledgeHandshaker` and get it to register in the stacktrace. There are a lot of `flatMap` operations in there so it...