Re: HTTP/1.x broken with Tomcat 9, Java 11 and Http11NioProtocol

2019-03-27 Thread Jason Rivard
On Wed, Mar 27, 2019 at 11:21 AM Mark Thomas  wrote:
> > Don't know yet. Just started looking.
[snip]
> That didn't take long.
> The fix will be in the next set of releases (expected towards the end of
> next week).
[snip]

Wow, that was fast!  Thanks for the quick response!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



HTTP/1.x broken with Tomcat 9, Java 11 and Http11NioProtocol

2019-03-26 Thread Jason Rivard
I'm trying to get the following configuration working:

- Tomcat 9.0.17 (also tested with 9.0.16)
- AdoptOpenJDK Java 11.0.2 on Linux (also tested on Windows)
- Http11NioProtocol Connector
- Http2Protocol ProtocolUpgrade

I'm using the following connector config:


  


With the UpgradeProtocol in place, HTTP/2.0 works fine, but when I
attempt a pure HTTP/1.0 or HTTP/1.1 request the server closes the
connection before responding.  This breaks any non-HTTP2.0 client.

My first question is: Should this configuration work?

My second is: Why is it broken?  :)

Thanks!

Output from curl for reference:

Working: curl -kv --http2 https://127.0.0.1:8443/examples/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=Example; L=Example; O=Example; OU=Example; CN=Example
*  start date: Mar 13 13:39:10 2019 GMT
*  expire date: Jun 11 13:39:10 2019 GMT
*  issuer: C=US; ST=Example; L=Example; O=Example; OU=Example; CN=Example
*  SSL certificate verify result: self signed certificate (18),
continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x558883950900)
> GET /examples/ HTTP/2
> Host: 127.0.0.1:8443
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< accept-ranges: bytes
< etag: W/"1156-1552393515275"
< last-modified: Tue, 12 Mar 2019 12:25:15 GMT
< content-type: text/html
< content-length: 1156
< date: Wed, 27 Mar 2019 03:42:56 GMT
<

--snip--

* Connection #0 to host 127.0.0.1 left intact



Not working:  curl -kv --http1.0 https://127.0.0.1:8443/examples/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; ST=Example; L=Example; O=Example; OU=Example; CN=Example
*  start date: Mar 13 13:39:10 2019 GMT
*  expire date: Jun 11 13:39:10 2019 GMT
*  issuer: C=US; ST=Example; L=Example; O=Example; OU=Example; CN=Example
*  SSL certificate verify result: self signed certificate (18),
continuing anyway.
> GET /examples/ HTTP/1.0
> Host: 127.0.0.1:8443
> User-Agent: curl/7.58.0
> Accept: */*
>
* TLSv1.2 (IN), TLS alert, Client hello (1):
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
curl: (52) Empty reply from server

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8.0.29-30 context root redirect changes break application

2015-12-18 Thread Jason Rivard
On Fri, Dec 18, 2015 at 4:36 PM, Mark Thomas  wrote:

> On 18 December 2015 20:21:12 GMT+00:00, Jason Rivard 
> wrote:

[snip]
>

> You can use sessionCookiePathUsesTrailingSlash on the Context to fix the
> session problem but be aware of the security risks if you have contexts
> with common prefixes.
>
> We might need to rethink the defaults of these inter-related Context
> options to get a set that it self-consistent and secure.
>
> Mark


Yes, I'm pretty sure that would fix the problem as well, but has the
security risks you mention.  From my perspective, this is more an issue
about the default behavior changing.  My existing binary app releases are
broken when a newer version of tomcat is used - and that shouldn't happen.
Should I open a bug for this?


Tomcat 8.0.29-30 context root redirect changes break application

2015-12-18 Thread Jason Rivard
I'm not sure if I'm posting this in the right place, but I thought I would
start here.  It seems that changes to tomcat 8.0.29-30 partially described
in the following bug break my application, and probably others:

https://bz.apache.org/bugzilla/show_bug.cgi?id=58660

And here is my test application:

https://github.com/jrivard/tomcat-root-redir-test

Behaviors seen:

The issue is that in 8.0.28, a request to the application context
"/context" would result in a redirect to "/context/".  This handling was
handed in a way that was invisible to the application code.

In 8.0.29, this request is processed and the application generates a
response.

In 8.0.30, this request is processed by the application, but generates a
302 to "/context/"

8.0.29-30 both break my test application in similar but distinct ways.  The
issue is that the application processes the initial request in a filter,
modifies the session object, and then issues a redirect to itself.  Because
the JSESSION cookie path is set to "/context/" and not "/context", the
session seen on the subsequent handling of the redirect does not have
access to the same session object as on the first request.  In a real
application that depends on similar behavior this breaks the application in
significant ways.

Another way to think of this is that it shouldn't be possible for the
application to access an HttpSession that doesn't match the browser's
session cookie.  As of 8.0.30 this implied contract is broken because on
the initial request to the "/context" url, application code has access to
an effectively bogus HttpSession instance.

I understand this can be worked around by setting context parameters
('mapperContextRootRedirectEnabled' for example), but it seems to me the
default behavior shouldn't break existing apps - unless there is a
significant security reason - which I don't think is the case here.
Perhaps this new behavior could be reverted in 8.x and prior, and only
adopted in 9.x.

If I've posted this in the wrong place, or if I should open a bug, please
advise.