On 12 September 2014 04:45, Edward Burns <edward.burns_at_oracle.com> wrote:
> Hello Experts,
>
> While discussing the design of the HTTP/2.0 client in Java SE 9 [1] we
> came upon the question of what HTTP/2.0 specific configuration
> parameters we need to expose in the API. So far Shing-Wai and I have
> just come up with
>
> Stream priority
>
I really wish the h2 stream priority was expressed in non protocol specific
terms, as it would make a lot more sense to expose to the application if it
was not so transport dependent. But regardless it is something that we
need to expose... perhaps we can translate from h2 stream relative terms to
an absolute priority that will have more chance of being correct long term
as transports continue to change.
> WINDOW_UPDATE
>
I'm not sure this needs to be exposed? We already have a signal to the
application for when a window is consumed - namely a blocking IO operation
will block or an asynchronous one will not receive a
onWritePossible()/onDataAvailable() callback.
Containers will need to configure window sizes, just as they do buffer
sizes, but I'm not sure that should be visible to the application.
Algorithms for controlling the window sizes are going to evolve over time
and are difficult for servers to get absolutely correct. If there is
information that an application can make available to help with this (more
than content-length) then perhaps we can make this visible, but I'm
cautious about letting the application get involved.
Are there any others you think should be exposed in the Servlet 4.0 API?
>
Do we want to expose some kind of connection ID, so that we can know if two
requests come from the same connection or not. I can't think offhand of a
specific usage for this, but at the very least it would be useful for
logging.
The other thing we could consider is augmenting security constraints to
indicate if the web resources matched are compressible or not, and if they
should have their headers padded or not. I'm not that keen on the h2
security "features" in this regard, but if they remain in the protocol,
then the server definitely needs some hints from the application for which
headers and content need to be protected.
cheers
--
Greg Wilkins <gregw_at_intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.