implement servlet upgrade for ee10 and ee11

[lachlan-roberts]

Implement Servlet upgrade for ee10 and ee11 which is required for the TCK.

Replaces #10128

[lachlan-roberts]

The TCK fully passes after the changes in this branch.
See https://jenkins.webtide.net/job/tck/job/tck-servlet-arquillian/job/jetty-12-ee11/64/

[olamy]

The TCK fully passes after the changes in this branch. See https://jenkins.webtide.net/job/tck/job/tck-servlet-arquillian/job/jetty-12-ee11/64/

YEAHHHH

[gregw]

I think it should be possible to do this without making HttpConnection public. We already have some upgrade related interfaces, so use them or create a new one to abstract away from the implementation.

[gregw]

Can you explain why this move is necessary?

Is it so that ServletAPIRequest can do:

        HttpConnection httpConnection = (HttpConnection)_servletContextRequest.getConnectionMetaData().getConnection();
        httpConnection.getParser().servletUpgrade();
        outputStream.flush(); // commit the 101 response
        httpConnection.getGenerator().servletUpgrade(); // tell the generator it can send data as-is

We already have interfaces: Connection.UpgradeFrom, Connection.UpgradeTo to abstract away from specific connection types. so can't you use them instead? Get those methods to flip the parser and generator states?

[lachlan-roberts]

Is it so that ServletAPIRequest can do:

Yes, this is why it was necessary.

We already have interfaces: Connection.UpgradeFrom, Connection.UpgradeTo to abstract away from specific connection types. so can't you use them instead? Get those methods to flip the parser and generator states?

These interfaces are already implemented on HttpConnection, I think for the HTTP/2 upgrade.

So I think the options are (unless you have a better idea)

1. make HttpConnection public
2. create a new Upgrade interface and implement it on the HttpConnection
3. add a new method to the Connection interface.

[gregw]

Option 2

[gregw]

I'd like to keep HttpConnection internal

[lachlan-roberts]

@gregw nudge

[gregw]

This is not correct (nor was it before). It is actually looking for Connection.class.getName()

[gregw]

Sorry, but I've changed my mind about the naming here. This is not really upgrade, it would be more accurate to call these methods tunnel or openTunnel or startTunnel.

The description would be to convert the connection over which the current protocol us running to a tunnel, but without replacing the connection (as is done by our real upgrade mechanism). This can be used for upgrade within a connection, but it is not really an upgrade for this connection, as the connection remains and just tunnels data to/from its endpoint.