[jsr369-experts] Re: [servlet-spec users] Re: Upgrade is done?

From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
Date: Tue, 17 Feb 2015 10:05:05 -0800

On 2/15/15, 6:42 PM, Stuart Douglas wrote:
> ----- Original Message -----
>> From: "Mark Thomas"<markt_at_apache.org>
>> To: jsr369-experts_at_servlet-spec.java.net
>> Sent: Thursday, 12 February, 2015 5:40:14 AM
>> Subject: [servlet-spec users] [jsr369-experts] Re: Upgrade is done?
>> On 11/02/2015 05:08, Greg Wilkins wrote:
>>> All,
>>> Jetty currently doesn't implement the standard upgrade mechanism and I'm
>>> currently looking to fix that. The spec says:
>>> When the upgrade processing is done, HttpUpgradeHandler.destroy will
>>> be invoked.
>>> What does "is done" mean? Does it mean both input and output streams
>>> have been closed?
>> Tomcat took that to mean if either of those streams was closed. Tomcat
>> ensures both streams are closed and then calls destroy().
> In Undertow we will not call destroy() until a connection is fully closed.
+1. This agrees with the javadoc: It is called when the client is

Shing Wai Chan
> The idea behind upgrade is to allow the use of arbitrary protocols over what is basically a raw TCP connection, and destroying the connection once it becomes half closed does not match TCP semantics.
> There are some protocols that rely on being able to send data after reading -1, and it will not be possible to implement these if we say the connection has to be destroyed once one side is closed.
>>> I also note that the spec says async IO can be used, so I assume that
>>> means that startAsync must be called before returning after the
>>> request.upgrade call?
>> Tomcat took that to mean that you could set a ReadListener and a
>> WriteListener on the Streams if you wanted to use non-blocking.
> We also implemented this the same way (no startAsync required).
>> The main reasons for the above choices were:
>> - the choices looked to be consistent with the spec
>> - the choices worked for Tomcat's WebSocket on top of Servlet API impl
> I don't see how the 'closing one stream closes both' behaviour is consistent with the spec?
> Stuart
>> Mark