>
> 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.
I also don't think this is an application level concern. This is really
a protocol level concern, and the underlying container is in a much
better position to manage it.
On a related note I have seen some serious performance problems with
flow controlled protocols on high latency connections if the flow
control window is too small. If we put the window size in the hands of
the application developer I think we will see lots of applications that
suffer from these sorts of issues.
>
>
> 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.
I think this could be useful, and would also be applicable to HTTP/1.1
persistent connections.
>
>
> 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.
We may also need some way to indicate that a header should never be indexed.
Stuart
>
> cheers
>
>
> --
> Greg Wilkins <gregw_at_intalio.com <mailto: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.