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

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Sun, 15 Feb 2015 21:42:55 -0500 (EST)

----- 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.

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?


> Mark