>>>>> 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
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 34 Business days til JavaOne 2015
| 49 Business days til DOAG 2015