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

Thanks for describing these cases now. I had not thought of them.

If everyone's sold on reprioritization, then let's go ahead and do this and
have the debate about ditching HEADERS+PRIORITY or not. I want to keep it.
I don't like the idea of sending a PRIORITY frame first. Is sending a
PRIORITY frame going to trigger stream state allocation at the receiver?
What's the expectation? And if you don't have a priority for the HEADERS,
then you have the race that Roberto described.


On Tue, May 21, 2013 at 2:09 PM, Patrick McManus <pmcmanus@mozilla.com>wrote:

>
> 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
>
>
>