Re: Stream State and PRIORITY Frames

On Tue, Jan 17, 2017 at 7:42 AM, Cory Benfield <> wrote:

> On 17 Jan 2017, at 08:38, Benedikt Christoph Wolters <
>> wrote:
> This question reminds me of a similiar issue we had a while ago at
> mitmproxy:
> 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
>, which is referenced from
> and opened by the same person who opened
> h2o/pull/1136, which links to
> y/mitmproxy/issues/1824, which is related to
> 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

Received on Thursday, 19 January 2017 15:52:20 UTC