Hi,
+1 for no need to expose WINDOWS_UPDATE
+1 for possible usefulness of connection ID
Best regards,
Eugene Chung (Korean : 정의근)
On Fri, Sep 12, 2014 at 7:57 AM, Stuart Douglas <sdouglas_at_redhat.com> wrote:
>
>
>> 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.
>>
>