Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY

On Tue, May 21, 2013 at 12:32 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

>
> I support adding a new additional PRIORITY frame for stream
> reprioritization.
>

me too. Specifically I support this as a mechanism for the client to be
able to explicitly prioritize an open pushed stream. I can wait for more
evidence about re-prioritizing, but in cases where the client hasn't ever
explicitly set the stream's priority I think we have evidence that its time
to do something.

>
> Unless there's a reason this needs to be in the current http/2 draft
> sooner rather than later, I'd rather punt on this discussion until we have
> implementation experience that can guide this debate.
>

I think there is experience here specifically related to push.

e.g. You can easily configure mod_spdy to push images when html is pulled.
but you can't effectively dictate the relative priorities of those two
things.

Sure, you can define an explicit priority for those images but priority
implementations are all about relative levels and the client set the
priority of the html.

You can argue that mod_spdy should have defined relative priorities (+/-
the associated stream) instead of constants.. that would be better but the
client still has no way to make sure those streams are at a higher priority
than a "save as" background stream (I've seen this one happen as mod_spdy
defaults to lowest priority when pushing), or a lower priority than a
real-time video stream..

plus there is no scale for the server to work with.. it might set a +2
priority for pushed images but the client might be using +3 for pulled
images causing a mismatch in something that was intended to be equally
weighted.

at least with a priority frame the client can make those adjustments in a
RTT.

Cheefully,
-Patrick