Re: Extensible Priorities and Reprioritization

On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <patmeenan@gmail.com> wrote:

> Eric's download example is a great one for exposing the risks that would
> come for an implementation that supported prioritization but not
> reprioritization.
>
> Take the trivial example of an anchor link that links to a download (say,
> a 200MB installer of some kind):
> - When the user clicks on the link, the browser assumes it is doing a
> navigation and issues the request with the "HTML" priority (relatively
> high, possibly non-incremental
> - When the response starts coming back, it has the content-disposition to
> download to a file.
> - At this point, the 200MB download will block every other lower-priority
> request on the same connection (or possibly navigation if it is
> non-incremental)
> - The user clicks on another page on the same site and gets nothing or a
> broken experience until the 200MB download completes
>
> Without reprioritization the browser will effectively have to burn the
> existing QUIC connection and issue any requests on a new connection (and
> repeat for each new download).
>
> Implementing prioritization without reprioritization in this case is worse
> than having no prioritization support at all.
>

Thanks Eric for presenting this case, and Patrick for breaking it down.
That does seem like a pretty bad outcome.

Is this a good candidate for a test case? IIUC correctly the problem might
occur today with HTTP/2 depending on how exclusive priorities are used. I'm
curious if browsers can share any more information about what they do
already. How does Firefox manage such a resource with it's priority groups?

Cheers
Lucas