Re: Stream State and PRIORITY Frames

[Cory Benfield <[e-mail]>]

> On 19 Jan 2017, at 15:51, Patrick McManus <[e-mail]> wrote:
> 
> Hey Cory, this is a bit of a back alley - but can you help me understand the scenario here. Priority is not an end to end concept - the dependencies are clearly connection based and only make sense relevant to each other. So is hyper-h2 just forwarding client Priority frames directly? How would that work? (I know its not your project.. you just seem to grok what's going on..)

Definitely a side-alley: I suspect we may want to take this off-list.

The short version is that mitmproxy is an intercepting web proxy. This means it has slightly different goals than most intermediaries do: in particular, it wants to be able to understand the content of a HTTP connection without manipulating it. It doesn’t do connection coalescing, or caching, or any of the things that would require that it actually do anything with priorities: it just logs the data and presents it in a handy-dandy debuggable form. Incidentally, it also does connection-replay and a whole host of other fun stuff.

As a result, it handles the bytestream of a HTTP/2 connection a bit weirdly. Specifically, as far as I understand it, when it receives a HTTP/2 connection it sets up a data pipe between the client and server, essentially forwarding their data onto each other. But, in addition to that, it runs a pair of HTTP/2 stacks as basically a B2BUA: it treats itself as the server for the client and it treats itself as the client for the server. This is mostly a correctness concern, helping it make semantic sense of the HTTP/2 connection. However, the HTTP/2 stack it uses (mine) tries to be fastidious about correctness, so I tend to get tagged in on bug reports when connections go awry. That included this one.

Does that clarify, or did I just make it all murkier?

Cory