jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [138-StreamPriority] recommend WONTFIX (was HTTP 2 Stream Priority

From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
Date: Fri, 18 Sep 2015 10:32:39 -0700

I have marked the issue as "Won't Fix" in jira.

Shing Wai Chan

On 9/18/15, 9:41 AM, Edward Burns wrote:
>>>>>> On Thu, 17 Sep 2015 16:26:35 -0700, Shing Wai Chan<shing.wai.chan_at_oracle.com> said:
> SWC> In section 5.3 of RFC 7540 (HTTP/2), steam priority is defined.
> SWC> It is assigned by "client" in order to recommend how the endpoint should
> SWC> allocate resources
> SWC> while managing concurrent streams.
>
> SWC> As discussed in the comments of
> SWC> https://java.net/jira/browse/SERVLET_SPEC-138, the priority
> SWC> information can be set in a priority frame, which is not a HTTP
> SWC> request. If applications/frameworks want to use priority
> SWC> information, they would need to keep the priority "tree"
> SWC> information. This seems to be quite low level, likely handled in
> SWC> transport/network layer.
>
> SWC> Is there value in exposing this in the Servlet API for applications
> SWC> to use? This seems more to be a HTTP client side API feature. Is
> SWC> there any concrete interesting use cases that EG experts have in
> SWC> mind?
>
>>>>>> On Thu, 17 Sep 2015 20:12:25 -0400 (EDT), Stuart Douglas<sdouglas_at_redhat.com> said:
> SD> Personally I am leaning towards not exposing it. Once the resources
>
> SD> Unless there are concrete use cases and actual user demand I think
> SD> it would should leave this out. If it turns out there are some cases
> SD> where it is necessary we can always add it in a later revision.
>
>>>>>> On Fri, 18 Sep 2015 10:42:48 +1000, Greg Wilkins<gregw_at_webtide.com> said:
> GW> I agree with Stuart and Shing that there is probably very little value in
> GW> exposing priorities.
>
> GW> The whole priority mechanism in HTTP2 is kind of experimental and very
> GW> untested. It was a point of a lot of criticism that it was included in
> GW> the first place. I also believe that most server implementations are
> GW> going to essentially ignore it, because while it is a valid use-case for
> GW> browsers to have dynamic changing relative priorities as tabs/windows are
> GW> exposed/hidden, there is actually very little that most scalable servers
> GW> can do about it.
>
> GW> If a server receives requests A, B, C& D in that order then it is likely
> GW> to handle them either in parallel or approximate the order of receipt (give
> GW> or take some blocking). Receiving a message that request D is now higher
> GW> priority than B is very hard to handle if the contain has already
> GW> dispatched A& B and is waiting for available threads/buffer/JDBC
> GW> connections before handling C& D. The server simply cannot preempt B
> GW> without allocating more resources to D, which if it does so exposes the
> GW> server to a DOS attack vector as a connection can keep inverting higher and
> GW> higher priorities which request more and more parallelism.
>
> On balance I think the right thing to do is close this as WONTFIX,
> though I always thought the "web framework wants to use priorities when
> serving up resources" was a compelling use case for at least being able
> to read the priorities.
>
> I'll leave it up to Shing-wai to weigh and decide what to do on this one.
>
> Ed
>