Re: Stream State and PRIORITY Frames

On Tue, Jan 17, 2017 at 7:42 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

>
> On 17 Jan 2017, at 08:38, Benedikt Christoph Wolters <
> benedikt.wolters@rwth-aachen.de> wrote:
>
> This question reminds me of a similiar issue we had a while ago at
> mitmproxy: https://github.com/mitmproxy/mitmproxy/issues/1498
>
> As far as I understand this, sending PRIORITY does not initiate a
> stream or change the stream state.
> HEADERS and PUSH_PROMISE initiate a stream. PRIORITY can be sent and
> received in any stream state.
>
>
> In fact, I think it’s the same issue. Scott linked to
> https://github.com/summerwind/h2spec/pull/67, which is referenced from
> and opened by the same person who opened https://github.com/h2o/
> h2o/pull/1136, which links to https://github.com/mitmprox
> y/mitmproxy/issues/1824, which is related to
> https://github.com/mitmproxy/mitmproxy/issues/1498 because both cases
> were sites deployed behind Fastly.
>
> For those who want background and don’t want to follow all those links,
> mitmproxy bumped into problems with sites deployed behind Fastly. mitmproxy
> encountered these because it was forwarding on traffic from Firefox, which
> would on connection-setup send a whole bunch of PRIORITY frames. hyper-h2
> (which powers mitmproxy’s HTTP/2 support) would allow this. h2o would not.
>
>
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..)