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
>