I agree with Stuart and Shing that there is probably very little value in
exposing priorities.
The whole priority mechanism in HTTP2 is kind of experimental and very
untested. It was a point of a lot of criticism that it was included in
the first place. I also believe that most server implementations are
going to essentially ignore it, because while it is a valid use-case for
browsers to have dynamic changing relative priorities as tabs/windows are
exposed/hidden, there is actually very little that most scalable servers
can do about it.
If a server receives requests A, B, C & D in that order then it is likely
to handle them either in parallel or approximate the order of receipt (give
or take some blocking). Receiving a message that request D is now higher
priority than B is very hard to handle if the contain has already
dispatched A & B and is waiting for available threads/buffer/JDBC
connections before handling C & D. The server simply cannot preempt B
without allocating more resources to D, which if it does so exposes the
server to a DOS attack vector as a connection can keep inverting higher and
higher priorities which request more and more parallelism.
Jetty is ignoring priority.
cheers
On 18 September 2015 at 10:12, Stuart Douglas <sdouglas_at_redhat.com> wrote:
> Personally I am leaning towards not exposing it. Once the resources have
> been allocated to handle the request there is likely not a great deal that
> the user code can do with this information, and due to the tree structure
> that expresses priority in terms of other streams there is no simple way to
> present it to the user.
>
> Unless there are concrete use cases and actual user demand I think it
> would should leave this out. If it turns out there are some cases where it
> is necessary we can always add it in a later revision.
>
> Stuart
>
> ----- Original Message -----
> > From: "Shing Wai Chan" <shing.wai.chan_at_oracle.com>
> > To: jsr369-experts_at_servlet-spec.java.net
> > Sent: Friday, 18 September, 2015 9:26:35 AM
> > Subject: [jsr369-experts] HTTP 2 Stream Priority
> >
> > In section 5.3 of RFC 7540 (HTTP/2), steam priority is defined.
> > It is assigned by "client" in order to recommend how the endpoint should
> > allocate resources
> > while managing concurrent streams.
> >
> > As discussed in the comments of
> > https://java.net/jira/browse/SERVLET_SPEC-138, the priority
> > information can be set in a priority frame, which is not a HTTP request.
> > If applications/frameworks want to use priority information, they would
> > need to keep the
> > priority "tree" information.
> > This seems to be quite low level, likely handled in transport/network
> layer.
> >
> > Is there value in exposing this in the Servlet API for applications to
> use?
> > This seems more to be a HTTP client side API feature.
> > Is there any concrete interesting use cases that EG experts have in mind?
> >
> > Shing Wai Chan
> >
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com