RE: HTTP2: Connections abruptly closed by sending GOAWAY

2020-09-15 Thread Arshiya Shariff
Hi All , 
Any update on this please .

Thanks and Regards
Arshiya Shariff

-Original Message-
From: Arshiya Shariff  
Sent: Wednesday, September 9, 2020 6:49 PM
To: Tomcat Users List 
Subject: RE: HTTP2: Connections abruptly closed by sending GOAWAY

Hi All,



Can you please help us understand this behavior .

The following is the sequence of events that is happening for a few streams .
Initially when the stream is opened , it processes fine , but beyond some time 
tomcat does not process the headers, for which the client is sending RST_STREAM 
(ERROR: NO_ERROR) and then tomcat closes the stream with GOAWAY (An error 
occurred during processing that was fatal to the connection).
Other connection streams during the same time are working fine .



Please find the link to the images : img2 has GOAWAY packet 
https://protect2.fireeye.com/v1/url?k=85ab1ff6-db0bff6f-85ab5f6d-8682aaa22bc0-561cdc1c5bb5b447=1=47308773-70b3-4fac-9ca3-96f35ff17679=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffolders%2F11r6rnbciayHIMNCLXDm4JFUowHJqp8ox


Please help us analyze under which cases this happens .

Embedded tomcat:9.0.22



Thanks and Regards

Arshiya Shariff





-Original Message-
From: Mark Thomas mailto:ma...@apache.org>>
Sent: Monday, September 7, 2020 10:21 PM
To: users@tomcat.apache.org
Subject: Re: HTTP2: Connections abruptly closed by sending GOAWAY



On 07/09/2020 09:29, Arshiya Shariff wrote:

> Hi All,

> Tomcat is closing connections abruptly by sending GOAWAY with reason

> Connection [5309], Stream [57,359], An error occurred during processing that 
> was fatal to the connection .

>

> Just trying to understand in what scenarios this happens. Can you please help 
> us.



An unhandled InterruptedIOException during I/O.



I/O exception writing an intermediate 100 response for a request with an 
expectation.



I/O exception trying to initiate a push request.



I/O exception committing, flushing or closing a stream.



So, generally, any I/O exception that indicates the connection between the 
client and the server is broken.



Mark



-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org

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



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



Re: Unable to get http redirect to https on Apache Tomcat 8.5.57

2020-09-15 Thread Lee Jarvis


 Original message From: Mark Thomas  Date: 
9/14/20  3:30 PM  (GMT-05:00) To: users@tomcat.apache.org Subject: Re: Unable 
to get http redirect to https on Apache Tomcat 8.5.57 On 14/09/2020 20:22, Lee 
Jarvis wrote:> Hi all,>  > I’m trying to implement SSL and have defined a 
connector on ports 8080 and 8443. I can connect to either port, but I want any 
incoming HTTP on 8080 to be redirected to the HTTPS port on 8443, but that’s 
not happening as I have things configured below. What> am I missing?>  > 
   
  connectionTimeout="6">     redirectPort="8443">     
relaxedQueryChars='^{}[]|' />>  >  >      
protocol="org.apache.coyote.http11.Http11NioProtocol">     
connectionTimeout="6">     port="8443">     maxThreads="200">     
scheme="https">     secure="true">     SSLEnabled="true">     
keystoreFile="///C:/apache-tomcat-8.5.57/webapps/cmms/WEB-INF/classes/keystore.jks">
     keystorePass="">     clientAuth="false">     
sslProtocol="TLSv1.2">     relaxedQueryChars='^{}[]|' />>  > Thanks & 
regards,Lee JarvisIn the configuration above, there is nothing to configure a 
redirectfrom http to https. You'd normally do this with a transport guarantee 
inweb.xml (other solutions are 
available).Mark‐-Thanks Mark!I added 
transport guarantee to the web.xml and now I'm seeing the expected redirect 
behavior, but another problem has popped up.When the redirect occurs to https, 
my web application just hangs - and I find a "javax.net.ssl.SSLException: 
Received fatal alert: unexpected_message"Prior to adding the transport 
guarantee, I was able to access the web app via http or https and all worked 
fine, but once the redirect took effect - nothing.Thanks for your patient 
help!Lee J.

Re: Unable to get http redirect to https on Apache Tomcat 8.5.57

2020-09-15 Thread Lee Jarvis


 Original message From: Mark Thomas  Date: 
9/14/20  3:30 PM  (GMT-05:00) To: users@tomcat.apache.org Subject: Re: Unable 
to get http redirect to https on Apache Tomcat 8.5.57 On 14/09/2020 20:22, Lee 
Jarvis wrote:> Hi all,>  > I’m trying to implement SSL and have defined a 
connector on ports 8080 and 8443. I can connect to either port, but I want any 
incoming HTTP on 8080 to be redirected to the HTTPS port on 8443, but that’s 
not happening as I have things configured below. What> am I missing?>  > 
   
  connectionTimeout="6">     redirectPort="8443">     
relaxedQueryChars='^{}[]|' />>  >  >      
protocol="org.apache.coyote.http11.Http11NioProtocol">     
connectionTimeout="6">     port="8443">     maxThreads="200">     
scheme="https">     secure="true">     SSLEnabled="true">     
keystoreFile="///C:/apache-tomcat-8.5.57/webapps/cmms/WEB-INF/classes/keystore.jks">
     keystorePass="">     clientAuth="false">     
sslProtocol="TLSv1.2">     relaxedQueryChars='^{}[]|' />>  > Thanks & 
regards,Lee JarvisIn the configuration above, there is nothing to configure a 
redirectfrom http to https. You'd normally do this with a transport guarantee 
inweb.xml (other solutions are 
available).Mark‐-Thanks Mark!I added 
transport guarantee to the web.xml and now I'm seeing the expected redirect 
behavior, but another problem has popped up.When the redirect occurs to https, 
my web application just hangs - and I find a "javax.net.ssl.SSLException: 
Received fatal alert: unexpected_message"Prior to adding the transport 
guarantee, I was able to access the web app via http or https and all worked 
fine, but once the redirect took effect - nothing.Thanks for your patient 
help!Lee J.

Re: Re: [OT] Replacing the standard JspWriter

2020-09-15 Thread Adam Rauch

On 9/14/2020 6:19 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 9/11/20 19:30, Adam Rauch wrote:

I have implemented a custom JspWriter and registered it for use by
our JSPs using the approach described here:
https://stackoverflow.com/questions/29508245/jsp-using-a-delegate-for-

out-jspwriter-with-jsp-includes-to-change-the-beh



I created a custom JspFactory that returns a custom JspContext
that returns my custom JspWriter. I then replaced the standard
JspFactory by calling JspFactory.setDefaultFactory(). This works,
though it results in some undesired behavior. I also note that the
setDefaultFactory() JavaDoc seems to claim that my approach is
"illegal".

So, is there a preferred way for my web application to provide a
custom JspWriter for my JSPs to use?

(If you're curious, our JspWriter HTML encodes all strings that
aren't designated as safe-to-render, like React and other modern
JavaScript frameworks do. The usual JSP approach is too susceptible
to XSS vulnerabilities, IMO.)

Really?

Seems like  should work just fine. You prefer
this?

<%= myVar %>

How do you mark variables as being "HTML-safe"?

If you don't trust your JSP programmers to do this correctly, maybe
JSP isn't the right technology for your team. (I happen to think that
JSP needs to go away, but that's just me).

- -chris

Thanks, Chris. I don't particularly love JSPs either, and we target 
React for most UI work these days, but we maintain a large system that 
includes ~1,000 existing JSPs. We also have many third party developers 
building their own code on our platform and we like the system to 
enforce best practices as much as possible. Our JSP base class makes it 
trivial to encode Strings (<%=h(myString)%>); the challenge is 
distinguishing Strings that contain well-formed HTML (produced by helper 
methods or commonly used builders) from those that don't. We have 
introduced a SafeToRender interface to mark Objects that are allowed to 
render themselves without encoding (i.e., their toString() must render 
well-formed HTML or JavaScript). HtmlString and JavaScriptFragment are 
String wrappers that implement SafeToRender, and are used to safely 
build ad hoc content. Likewise, builders for common HTML elements and 
JSON. While I trust my developers, this approach allows for 
straightforward verification and security auditing.


Adam


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



RE: [OT] RE: How to get the tag name from within a taglib class ?

2020-09-15 Thread Berneburg, Cris J. - US
Thanks Chris!

CS> IMO, the JSP effort was a stepping-stone on a path to better
CS> technologies like Velocity, FreeMarker, and others. If I were
CS> king, JSP would just go away. Just my POV of course [...]

cjb> what do you like better about Velocity, FreeMarker, etc.
cjb> more than JSP?

CS> I started using Velocity years ago [...] It definitely has its
CS> warts but it's relatively actively maintained, and anything I
CS> need I can get in and do myself, submit patches, etc.
CS>
CS> Advantages over JSP (IMHO):
CS>
CS> - Can't execute direct Java code, ever
CS> - Non-verbose syntax
CS> - No limit on template length [...]
CS> - Easy to install POJO "tools" which just expose Java objects
CS>   to the runtime so you can $tool.doSomething() [...]
CS> - Can load templates from anywhere (disk, DB, URL, etc.)

Good to know!  I also see that it is an ASF project.

Is Velocity interpreted or compiled like JSP?  I'm thinking of performance 
impacts, like during loops.

Answering my own question, the Velocity FAQ says, "Velocity doesn't compile 
your templates. They are parsed into an AST (abstract syntax tree) and that is 
what gets cached."

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.


Re: Low throughput with HTTP2

2020-09-15 Thread Rémy Maucherat
On Tue, Sep 15, 2020 at 5:08 PM Martin Grigorov 
wrote:

> Hi Mark,
>
> On Tue, Sep 15, 2020 at 3:34 PM Mark Thomas  wrote:
>
> > On 15/09/2020 12:46, Martin Grigorov wrote:
> > > On Tue, Sep 15, 2020 at 2:37 PM Martin Grigorov 
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I am running some load tests on Tomcat and I've noticed that when
> HTTP2
> > is
> > >> enabled the throughput drops considerably.
> > >>
> > >> Here are the steps to reproduce:
> > >>
> > >> 1) Enable HTTP2, e.g. by commenting out this connector:
> > >>
> > >>
> >
> https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f317c135d9d/conf/server.xml#L103-L112
> > >>
> > >> 2) Download Vegeta load tool from:
> > >> https://github.com/tsenart/vegeta/releases/
> > >>
> > >> 3) Run the load tests:
> > >>
> > >> 3.1) HTTP/1.1
> > >> echo -e '{"method": "GET", "url": "http://localhost:8080/examples/"}'
> |
> > >> vegeta attack -format=json  -rate=0 -max-workers=1000 -duration=10s |
> > >> vegeta encode > /tmp/http1.json; and vegeta report -type=json
> > >> /tmp/http1.json | jq .
> > >>
> > >> 3.2) HTTP2
> > >> echo -e '{"method": "GET", "url": "https://localhost:8443/examples/
> "}'
> > |
> > >> vegeta attack -format=json -http2 -rate=0 -max-workers=1000 -insecure
> > >> -duration=10s | vegeta encode > /tmp/http2.json; and vegeta report
> > >> -type=json /tmp/http2.json | jq .
> > >>
> > >> As explained at https://github.com/tsenart/vegeta#-rate -rate=0 means
> > >> that Vegeta will try to send as many requests as possible with the
> > >> configured number of workers.
> > >> I use '-insecure' because I use self-signed certificate.
> > >>
> > >> On my machine I get around 14-15K reqs/sec for HTTP1.1 with only
> > responses
> > >> with code=200 .
> > >> But for HTTP2 Tomcat starts returning such kind of errors:
> > >>
> > >>  "errors": [
> > >> "Get \"https://localhost:8443/examples/\": http2: server sent
> > GOAWAY
> > >> and closed the connection; LastStreamID=9259, ErrCode=PROTOCOL_ERROR,
> > >> debug=\"Stream [9,151] has been closed for some time\"",
> > >> "http2: server sent GOAWAY and closed the connection;
> > >> LastStreamID=9259, ErrCode=PROTOCOL_ERROR, debug=\"Stream [9,151] has
> > been
> > >> closed for some time\"",
> > >> "Get \"https://localhost:8443/examples/\": http2: server sent
> > GOAWAY
> > >> and closed the connection; LastStreamID=239, ErrCode=PROTOCOL_ERROR,
> > >> debug=\"Stream [49] has been closed for some time\""
> > >>   ]
> > >>
> > >> when I ask for more than 2000 reqs/sec, i.e. -rate=2000/1s
> >
> > That indicates that the client has sent a frame associated with a stream
> > that the server closed previously and that that stream has been removed
> > from the Map of known streams to make room for new ones. See
> > Http2UpgardeHandler.pruneClosedStreams()
> >
> > It looks like the client is making assumptions about server behaviour
> > that go beyond the requirements of RFC 7540, section 5.3.4.
> >
>
> This is possible!
> I've just tested with two more HTTP2 impls:
>
> 1) Node.js
>
> http2-server.js
> ===
> const http2 = require('http2');
> const fs = require('fs');
>
> const server = http2.createSecureServer({
> key: fs.readFileSync('/path/to/server.key'),
> cert: fs.readFileSync('/path/to/server.crt')
> });
> server.on('error', (err) => console.error(err));
>
> server.on('stream', (stream, headers) => {
> // stream is a Duplex
> stream.respond({
> 'content-type': 'text/plain; charset=utf-8',
> ':status': 200
> });
> stream.end('Hello world!');
> });
>
> server.listen(18080);
> ===
>
> run with: node http2-server.js
>
> Runs fine with -rate=0 and gives around 8K reqs/sec
>
> 2) Rust
>
> Cargo.toml
> ===
> [package]
> name = "my-http2-server"
> version = "0.0.1"
> publish = false
> authors = ["Martin Grigorov "]
> license = "MIT/Apache-2.0"
> description = "Load test HTTP/2 "
> repository = "https://github.com/martin-g/http2-server-rust;
> keywords = ["http2"]
> edition = "2018"
>
> [dependencies]
> actix-web = { version = "3", features = ["openssl"] }
> openssl = { version = "0.10", features = ["v110"] }
> ===
>
> src/main.rs
> ===
> use actix_web::{web, App, HttpRequest, HttpServer, Responder};
> use openssl::ssl::{SslAcceptor, SslFiletype, SslMethod};
>
> async fn index(_req: HttpRequest) -> impl Responder {
> "Hello world!"
> }
>
> #[actix_web::main]
> async fn main() -> std::io::Result<()> {
> let mut builder =
> SslAcceptor::mozilla_intermediate(SslMethod::tls()).unwrap();
> builder
> .set_private_key_file("/path/to/server.key", SslFiletype::PEM)
> .unwrap();
> builder.set_certificate_chain_file("/path/to/server.crt").unwrap();
>
> HttpServer::new(|| App::new().route("/", web::get().to(index)))
> 

Re: Low throughput with HTTP2

2020-09-15 Thread Martin Grigorov
Hi Chris,

On Tue, Sep 15, 2020 at 5:09 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Martin,
>
> On 9/15/20 07:37, Martin Grigorov wrote:
> > I am running some load tests on Tomcat and I've noticed that when
> > HTTP2 is enabled the throughput drops considerably.
> >
> > Here are the steps to reproduce:
> >
> > 1) Enable HTTP2, e.g. by commenting out this connector:
> > https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f31
> 7c135d9d/conf/server.xml#L103-L112
> 
> >
> >  2) Download Vegeta load tool from:
> > https://github.com/tsenart/vegeta/releases/
> >
> > 3) Run the load tests:
> >
> > 3.1) HTTP/1.1 echo -e '{"method": "GET", "url":
> > "http://localhost:8080/examples/"}' | vegeta attack -format=json
> > -rate=0 -max-workers=1000 -duration=10s | vegeta encode >
> > /tmp/http1.json; and vegeta report -type=json /tmp/http1.json | jq
> > .
> >
> > 3.2) HTTP2 echo -e '{"method": "GET", "url":
> > "https://localhost:8443/examples/"}' | vegeta attack -format=json
> > -http2 -rate=0 -max-workers=1000 -insecure -duration=10s | vegeta
> > encode > /tmp/http2.json; and vegeta report -type=json
> > /tmp/http2.json | jq .
>
> You are using HTTP with 1.1 and HTTPS with h2. Maybe you are seeing
> CPU slowdown for the (probably double encryption) taking place on the
> same host?
>

I've tested against HTTPS without H2 - it makes 13K reqs/sec here, i.e. 2-3
K less than HTTP.
The above numbers are when I use the examples' index.html page as a target.
When I use

=
package load.servlet;

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.nio.charset.StandardCharsets;

@WebServlet(urlPatterns = PlainTextServlet.URL_PATTERN)
public class PlainTextServlet extends HttpServlet {

  static final String URL_PATTERN = "/servlet/plaintext";
  private static final String CONTENT_TYPE = "text/plain;charset=UTF-8";
  private static final byte[] CONTENT = "Hello
world!".getBytes(StandardCharsets.UTF_8);
  private static final int CONTENT_LENGTH = CONTENT.length;

  @Override
  protected void doGet(final HttpServletRequest req, final
HttpServletResponse resp) throws IOException {
resp.setContentType(CONTENT_TYPE);
resp.setContentLength(CONTENT_LENGTH);
resp.getOutputStream().write(CONTENT);
  }
}
=

I can get 33-35 K reqs/sec with HTTP



>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9gyyIACgkQHPApP6U8
> pFiNUxAAnUQVU73nNitIyn6zD9t4JfkLIv/AKTlds4/W/p6TRtIQgTX7nIJjGDfw
> BOKznCHmieMJon4rMZ3d8GFhmUP8CawQlJHpqABeITBzLZZ5x9fuOf22G6HJb3r+
> +k0qDoKzFTWlJuWLwaLZHy6fO9ugi4OPAW0G0efa2T6sTDZzImGnjmoZ5PWBExoz
> mXmYWnZeP7R+3QkAWUYArJh9yPEJyIb9nFX1YKZ1l5Erzrn0F9uEYFgWT/UkQoKM
> L65AMh/qEvzJhP2wHOLm4NfAiNO4OgTmo+nm4F/SIMGFNURPFi2sl/jTUHVAzEa4
> mAqlJqX1swimyjjsunlfhbU/bApvVFsYSPuSYcZmLN1lkmaQOAuWHnZdd4e9h+tt
> rhoKXipk8OairYzwQsPVnzCTHaiAhOXJ3MSE966YwlvhSMOoqDsN3y7ySrboresD
> iC0cDo+43/wR3IQlOJYFxcFX+tI2Y29ZjrX/IwnJXuVyU095YZWmRFC2JgRfzBtI
> toM2ofpqnSBaS22ZBTbqp+q1QxRZfC3r0vuvuiXK620QRcbk1Ya0+U17LOIEYnuY
> URY94kL80upiADQMIdryq4ubRAma2t0s5c6JuO/QqsXVjJfawlRGQA5arORgfE2J
> yDCscyyFCHitEGTglIJUXW/KfFPtraWnON3TSCm7dQ55EmInxpc=
> =76Zf
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Low throughput with HTTP2

2020-09-15 Thread Martin Grigorov
Hi Mark,

On Tue, Sep 15, 2020 at 3:34 PM Mark Thomas  wrote:

> On 15/09/2020 12:46, Martin Grigorov wrote:
> > On Tue, Sep 15, 2020 at 2:37 PM Martin Grigorov 
> > wrote:
> >
> >> Hi,
> >>
> >> I am running some load tests on Tomcat and I've noticed that when HTTP2
> is
> >> enabled the throughput drops considerably.
> >>
> >> Here are the steps to reproduce:
> >>
> >> 1) Enable HTTP2, e.g. by commenting out this connector:
> >>
> >>
> https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f317c135d9d/conf/server.xml#L103-L112
> >>
> >> 2) Download Vegeta load tool from:
> >> https://github.com/tsenart/vegeta/releases/
> >>
> >> 3) Run the load tests:
> >>
> >> 3.1) HTTP/1.1
> >> echo -e '{"method": "GET", "url": "http://localhost:8080/examples/"}' |
> >> vegeta attack -format=json  -rate=0 -max-workers=1000 -duration=10s |
> >> vegeta encode > /tmp/http1.json; and vegeta report -type=json
> >> /tmp/http1.json | jq .
> >>
> >> 3.2) HTTP2
> >> echo -e '{"method": "GET", "url": "https://localhost:8443/examples/"}'
> |
> >> vegeta attack -format=json -http2 -rate=0 -max-workers=1000 -insecure
> >> -duration=10s | vegeta encode > /tmp/http2.json; and vegeta report
> >> -type=json /tmp/http2.json | jq .
> >>
> >> As explained at https://github.com/tsenart/vegeta#-rate -rate=0 means
> >> that Vegeta will try to send as many requests as possible with the
> >> configured number of workers.
> >> I use '-insecure' because I use self-signed certificate.
> >>
> >> On my machine I get around 14-15K reqs/sec for HTTP1.1 with only
> responses
> >> with code=200 .
> >> But for HTTP2 Tomcat starts returning such kind of errors:
> >>
> >>  "errors": [
> >> "Get \"https://localhost:8443/examples/\": http2: server sent
> GOAWAY
> >> and closed the connection; LastStreamID=9259, ErrCode=PROTOCOL_ERROR,
> >> debug=\"Stream [9,151] has been closed for some time\"",
> >> "http2: server sent GOAWAY and closed the connection;
> >> LastStreamID=9259, ErrCode=PROTOCOL_ERROR, debug=\"Stream [9,151] has
> been
> >> closed for some time\"",
> >> "Get \"https://localhost:8443/examples/\": http2: server sent
> GOAWAY
> >> and closed the connection; LastStreamID=239, ErrCode=PROTOCOL_ERROR,
> >> debug=\"Stream [49] has been closed for some time\""
> >>   ]
> >>
> >> when I ask for more than 2000 reqs/sec, i.e. -rate=2000/1s
>
> That indicates that the client has sent a frame associated with a stream
> that the server closed previously and that that stream has been removed
> from the Map of known streams to make room for new ones. See
> Http2UpgardeHandler.pruneClosedStreams()
>
> It looks like the client is making assumptions about server behaviour
> that go beyond the requirements of RFC 7540, section 5.3.4.
>

This is possible!
I've just tested with two more HTTP2 impls:

1) Node.js

http2-server.js
===
const http2 = require('http2');
const fs = require('fs');

const server = http2.createSecureServer({
key: fs.readFileSync('/path/to/server.key'),
cert: fs.readFileSync('/path/to/server.crt')
});
server.on('error', (err) => console.error(err));

server.on('stream', (stream, headers) => {
// stream is a Duplex
stream.respond({
'content-type': 'text/plain; charset=utf-8',
':status': 200
});
stream.end('Hello world!');
});

server.listen(18080);
===

run with: node http2-server.js

Runs fine with -rate=0 and gives around 8K reqs/sec

2) Rust

Cargo.toml
===
[package]
name = "my-http2-server"
version = "0.0.1"
publish = false
authors = ["Martin Grigorov "]
license = "MIT/Apache-2.0"
description = "Load test HTTP/2 "
repository = "https://github.com/martin-g/http2-server-rust;
keywords = ["http2"]
edition = "2018"

[dependencies]
actix-web = { version = "3", features = ["openssl"] }
openssl = { version = "0.10", features = ["v110"] }
===

src/main.rs
===
use actix_web::{web, App, HttpRequest, HttpServer, Responder};
use openssl::ssl::{SslAcceptor, SslFiletype, SslMethod};

async fn index(_req: HttpRequest) -> impl Responder {
"Hello world!"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
let mut builder =
SslAcceptor::mozilla_intermediate(SslMethod::tls()).unwrap();
builder
.set_private_key_file("/path/to/server.key", SslFiletype::PEM)
.unwrap();
builder.set_certificate_chain_file("/path/to/server.crt").unwrap();

HttpServer::new(|| App::new().route("/", web::get().to(index)))
.bind_openssl("127.0.0.1:18080", builder)?
.run()
.await
}
===

run with: cargo run
Again no errors, throughput: 3K reqs/sec

I will test with Netty tomorrow too, but so far it looks like only Tomcat
fails under load.



> >> All the access logs look like:
> >>
> >> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] 

Re: Low throughput with HTTP2

2020-09-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 9/15/20 07:37, Martin Grigorov wrote:
> I am running some load tests on Tomcat and I've noticed that when
> HTTP2 is enabled the throughput drops considerably.
>
> Here are the steps to reproduce:
>
> 1) Enable HTTP2, e.g. by commenting out this connector:
> https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f31
7c135d9d/conf/server.xml#L103-L112
>
>  2) Download Vegeta load tool from:
> https://github.com/tsenart/vegeta/releases/
>
> 3) Run the load tests:
>
> 3.1) HTTP/1.1 echo -e '{"method": "GET", "url":
> "http://localhost:8080/examples/"}' | vegeta attack -format=json
> -rate=0 -max-workers=1000 -duration=10s | vegeta encode >
> /tmp/http1.json; and vegeta report -type=json /tmp/http1.json | jq
> .
>
> 3.2) HTTP2 echo -e '{"method": "GET", "url":
> "https://localhost:8443/examples/"}' | vegeta attack -format=json
> -http2 -rate=0 -max-workers=1000 -insecure -duration=10s | vegeta
> encode > /tmp/http2.json; and vegeta report -type=json
> /tmp/http2.json | jq .

You are using HTTP with 1.1 and HTTPS with h2. Maybe you are seeing
CPU slowdown for the (probably double encryption) taking place on the
same host?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9gyyIACgkQHPApP6U8
pFiNUxAAnUQVU73nNitIyn6zD9t4JfkLIv/AKTlds4/W/p6TRtIQgTX7nIJjGDfw
BOKznCHmieMJon4rMZ3d8GFhmUP8CawQlJHpqABeITBzLZZ5x9fuOf22G6HJb3r+
+k0qDoKzFTWlJuWLwaLZHy6fO9ugi4OPAW0G0efa2T6sTDZzImGnjmoZ5PWBExoz
mXmYWnZeP7R+3QkAWUYArJh9yPEJyIb9nFX1YKZ1l5Erzrn0F9uEYFgWT/UkQoKM
L65AMh/qEvzJhP2wHOLm4NfAiNO4OgTmo+nm4F/SIMGFNURPFi2sl/jTUHVAzEa4
mAqlJqX1swimyjjsunlfhbU/bApvVFsYSPuSYcZmLN1lkmaQOAuWHnZdd4e9h+tt
rhoKXipk8OairYzwQsPVnzCTHaiAhOXJ3MSE966YwlvhSMOoqDsN3y7ySrboresD
iC0cDo+43/wR3IQlOJYFxcFX+tI2Y29ZjrX/IwnJXuVyU095YZWmRFC2JgRfzBtI
toM2ofpqnSBaS22ZBTbqp+q1QxRZfC3r0vuvuiXK620QRcbk1Ya0+U17LOIEYnuY
URY94kL80upiADQMIdryq4ubRAma2t0s5c6JuO/QqsXVjJfawlRGQA5arORgfE2J
yDCscyyFCHitEGTglIJUXW/KfFPtraWnON3TSCm7dQ55EmInxpc=
=76Zf
-END PGP SIGNATURE-

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



Re: [OT] RE: How to get the tag name from within a taglib class ?

2020-09-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 9/14/20 15:04, Berneburg, Cris J. - US wrote:
> Hey Chris
>
> CS> IMO, the JSP effort was a stepping-stone on a path to better
> CS> technologies like Velocity, FreeMarker, and others. If I were
> CS> king, JSP would just go away. Just my POV of course, you are
> CS> welcome to fall in love with JSP. :)
>
> Seeing as I am ever on the trailing edge of learning new or even
> dated technologies, what do you like better about Velocity,
> FreeMarker, etc. more than JSP?

I started using Velocity years ago because it was bundled with Turbine
which was being used by a project I got pulled-into. We eventually
ripped everything else out, but Velocity survived.

I looked at FreeMarker when doing a book review for Apache Struts 2
and it looked very interesting, but I discovered that the guy running
the project was ... difficult to work with. SO I've stuck with
Velocity for a long time.

It definitely has its warts but it's relatively actively maintained,
and anything I need I can get in and do myself, submit patches, etc.

Advantages over JSP (IMHO):

- - Can't execute direct Java code, ever
- - Non-verbose syntax
- - No limit on template length (JSP eventually hits the "Method too
long" problem which is very inconvenient)
- - Easy to install POJO "tools" which just expose Java objects to the
runtime so you can $tool.doSomething() and it'll do whatever that is,
converting the result to a String and dropping it into the output
- - Can load templates from anywhere (disk, DB, URL, etc.)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9gyksACgkQHPApP6U8
pFi2og//TI//2oxfo4iE3q0B1f4sMN8fT8K9EVT89EME1jfUHontVRXtrX+tke2f
t/3Os9veBJROAO5jOJvBCkefq7V2Lqij2289Vc7qVuuap+UqO/a+UCyOjxmVAHGh
TrMeuxRLV8V1GPhDo0pftoJEWXg6SnDEqo7TF/1kGAmcaHEkWUEYrOPLfE92GbHJ
8bNySZFEleXX3decZj1mBdAoL+SMV7jbSvONGrMDds0saAddUmYMpdP9VPnCnKfG
YS5Ec1Hx/1hshUisC1qOuarNCXH+84MLV98yM1pECoYCzx+2rTZ9RdoLwDnHjJB2
wJrc66P0yHOXyBfMamfpaxsUvTj2PON6RwBcbC7gaDMLIefGWM8TUROXMf7Odd40
TDZ+uJvyZBApeCnHkKrY/ipEvT4qb5sF0pVZTV9N6EBfqhKwBXgNqxTpCnAOkYFq
egXYO1JGShxCdnHfAgNHyMoZ61PLltwe5msW6ZTlAqex3teZkmIrVfXXINy/JEbs
lcRxe/V1EPBk9JxPJMy+hgDx4RBk6/ocepJbT2BR8nA9R1LBvA5h7wMr9iQw091S
pbBr7xuKnIncMuCqTTyjiPZV/+7fBRYZgGAqZX+2pNGJkZ+kNMm3FAPqz9pjw/LD
2DZyK7gqXmFCWGGdlWxLfPOpNb6ajv3slc3fMXxvdBNNpW1AYg8=
=AwcX
-END PGP SIGNATURE-

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



Re: Microsoft Edge (Chromium based) not prompting for logons

2020-09-15 Thread Dave Ford
On Mon, 2020-09-14 at 09:12 -0400, Christopher Schultz wrote:
> Are you using HTTP or HTTPS?

HTTPS.


> TLDR: visit edge://policy in Edge and look for AuthSchemes. If the
> value doesn't include "basic", add it and re-try.

Yeah, that was it - I wasn't able to change our edge settings - that's
locked down by others.  Finding out where to change the authentication
methods at the tomcat end was a bit harder than I hoped - I'd assumed
it was in the tomcat server area, rather than th eapplication itself,
which explains why I wasn't able to find much in the documentation - I
was looking at the wrong place.

Thanks very much - got a route forward throug this now 
Thanks
Dave



Re: Low throughput with HTTP2

2020-09-15 Thread Mark Thomas
On 15/09/2020 12:46, Martin Grigorov wrote:
> On Tue, Sep 15, 2020 at 2:37 PM Martin Grigorov 
> wrote:
> 
>> Hi,
>>
>> I am running some load tests on Tomcat and I've noticed that when HTTP2 is
>> enabled the throughput drops considerably.
>>
>> Here are the steps to reproduce:
>>
>> 1) Enable HTTP2, e.g. by commenting out this connector:
>>
>> https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f317c135d9d/conf/server.xml#L103-L112
>>
>> 2) Download Vegeta load tool from:
>> https://github.com/tsenart/vegeta/releases/
>>
>> 3) Run the load tests:
>>
>> 3.1) HTTP/1.1
>> echo -e '{"method": "GET", "url": "http://localhost:8080/examples/"}' |
>> vegeta attack -format=json  -rate=0 -max-workers=1000 -duration=10s |
>> vegeta encode > /tmp/http1.json; and vegeta report -type=json
>> /tmp/http1.json | jq .
>>
>> 3.2) HTTP2
>> echo -e '{"method": "GET", "url": "https://localhost:8443/examples/"}' |
>> vegeta attack -format=json -http2 -rate=0 -max-workers=1000 -insecure
>> -duration=10s | vegeta encode > /tmp/http2.json; and vegeta report
>> -type=json /tmp/http2.json | jq .
>>
>> As explained at https://github.com/tsenart/vegeta#-rate -rate=0 means
>> that Vegeta will try to send as many requests as possible with the
>> configured number of workers.
>> I use '-insecure' because I use self-signed certificate.
>>
>> On my machine I get around 14-15K reqs/sec for HTTP1.1 with only responses
>> with code=200 .
>> But for HTTP2 Tomcat starts returning such kind of errors:
>>
>>  "errors": [
>> "Get \"https://localhost:8443/examples/\": http2: server sent GOAWAY
>> and closed the connection; LastStreamID=9259, ErrCode=PROTOCOL_ERROR,
>> debug=\"Stream [9,151] has been closed for some time\"",
>> "http2: server sent GOAWAY and closed the connection;
>> LastStreamID=9259, ErrCode=PROTOCOL_ERROR, debug=\"Stream [9,151] has been
>> closed for some time\"",
>> "Get \"https://localhost:8443/examples/\": http2: server sent GOAWAY
>> and closed the connection; LastStreamID=239, ErrCode=PROTOCOL_ERROR,
>> debug=\"Stream [49] has been closed for some time\""
>>   ]
>>
>> when I ask for more than 2000 reqs/sec, i.e. -rate=2000/1s

That indicates that the client has sent a frame associated with a stream
that the server closed previously and that that stream has been removed
from the Map of known streams to make room for new ones. See
Http2UpgardeHandler.pruneClosedStreams()

It looks like the client is making assumptions about server behaviour
that go beyond the requirements of RFC 7540, section 5.3.4.

>> All the access logs look like:
>>
>> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
>> 1126
>> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
>> 1126
>> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
>> 1126
>> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
>> 1126
>> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
>> 1126
>> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
>> 1126
>>
>> i.e. there are no error codes, just 200.
>> Vegeta reports the error with status code = 0. I think this just means
>> that it didn't get a proper HTTP response but just TCP error.
>> There are no errors in catalina.out.
>>
>> Are there any settings I can tune to get better throughput with HTTP2 ?
>>
>> Tomcat 10.0.0-M8.

If you really want to maximise throughput then you need to reduce the
number of concurrent requests to (or a little above) the number of cores
available on the server. Go higher and you'll start to see throughput
tail off due to context switching.

If you want to demonstrate throughput with a large number of clients
you'll probably need to experiment with both maxThreads,
maxConcurrentStreams and maxConcurrentStreamExecution.

If I had to guess, I'd expect maxConcurrentStreams ==
maxConcurrentStreamExecution and low numbers for all of them to give the
best results.

Mark


> Forgot to mention that I've also tested with JMeter +
> https://github.com/Blazemeter/jmeter-http2-plugin but there it fails with
> OOM if I use more than 2000 virtual users. Increasing the memory still does
> not give such good results as Vegeta for HTTP/1.1. Also JMeter uses
> sequential model.
> 
> For comparison, I've also tested with a simple Golang based HTTP2 server:
> 
> http2-server.go:
> ==
> package main
> 
> import (
> "fmt"
> "log"
> "net/http"
> "os"
> )
> 
> func main() {
> 
> port := 8080
> if port == "" {
>   log.Fatal("Please specify the HTTP port as environment variable, e.g.
> env PORT=8081 go run http-server.go")
> }
> 
> tls_root := "/path/to/certs/"
> srv := {Addr: ":" + port, Handler: http.HandlerFunc(handle)}
> log.Fatal(srv.ListenAndServeTLS(tls_root + "server.crt", tls_root +
> "server.key"))
> }
> 
> func handle(w http.ResponseWriter, r *http.Request) 

Re: Low throughput with HTTP2

2020-09-15 Thread Martin Grigorov
On Tue, Sep 15, 2020 at 2:37 PM Martin Grigorov 
wrote:

> Hi,
>
> I am running some load tests on Tomcat and I've noticed that when HTTP2 is
> enabled the throughput drops considerably.
>
> Here are the steps to reproduce:
>
> 1) Enable HTTP2, e.g. by commenting out this connector:
>
> https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f317c135d9d/conf/server.xml#L103-L112
>
> 2) Download Vegeta load tool from:
> https://github.com/tsenart/vegeta/releases/
>
> 3) Run the load tests:
>
> 3.1) HTTP/1.1
> echo -e '{"method": "GET", "url": "http://localhost:8080/examples/"}' |
> vegeta attack -format=json  -rate=0 -max-workers=1000 -duration=10s |
> vegeta encode > /tmp/http1.json; and vegeta report -type=json
> /tmp/http1.json | jq .
>
> 3.2) HTTP2
> echo -e '{"method": "GET", "url": "https://localhost:8443/examples/"}' |
> vegeta attack -format=json -http2 -rate=0 -max-workers=1000 -insecure
> -duration=10s | vegeta encode > /tmp/http2.json; and vegeta report
> -type=json /tmp/http2.json | jq .
>
> As explained at https://github.com/tsenart/vegeta#-rate -rate=0 means
> that Vegeta will try to send as many requests as possible with the
> configured number of workers.
> I use '-insecure' because I use self-signed certificate.
>
> On my machine I get around 14-15K reqs/sec for HTTP1.1 with only responses
> with code=200 .
> But for HTTP2 Tomcat starts returning such kind of errors:
>
>  "errors": [
> "Get \"https://localhost:8443/examples/\": http2: server sent GOAWAY
> and closed the connection; LastStreamID=9259, ErrCode=PROTOCOL_ERROR,
> debug=\"Stream [9,151] has been closed for some time\"",
> "http2: server sent GOAWAY and closed the connection;
> LastStreamID=9259, ErrCode=PROTOCOL_ERROR, debug=\"Stream [9,151] has been
> closed for some time\"",
> "Get \"https://localhost:8443/examples/\": http2: server sent GOAWAY
> and closed the connection; LastStreamID=239, ErrCode=PROTOCOL_ERROR,
> debug=\"Stream [49] has been closed for some time\""
>   ]
>
> when I ask for more than 2000 reqs/sec, i.e. -rate=2000/1s
>
>
> All the access logs look like:
>
> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
> 1126
> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
> 1126
> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
> 1126
> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
> 1126
> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
> 1126
> 127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
> 1126
>
> i.e. there are no error codes, just 200.
> Vegeta reports the error with status code = 0. I think this just means
> that it didn't get a proper HTTP response but just TCP error.
> There are no errors in catalina.out.
>
> Are there any settings I can tune to get better throughput with HTTP2 ?
>
> Tomcat 10.0.0-M8.
>

Forgot to mention that I've also tested with JMeter +
https://github.com/Blazemeter/jmeter-http2-plugin but there it fails with
OOM if I use more than 2000 virtual users. Increasing the memory still does
not give such good results as Vegeta for HTTP/1.1. Also JMeter uses
sequential model.

For comparison, I've also tested with a simple Golang based HTTP2 server:

http2-server.go:
==
package main

import (
"fmt"
"log"
"net/http"
"os"
)

func main() {

port := 8080
if port == "" {
  log.Fatal("Please specify the HTTP port as environment variable, e.g.
env PORT=8081 go run http-server.go")
}

tls_root := "/path/to/certs/"
srv := {Addr: ":" + port, Handler: http.HandlerFunc(handle)}
log.Fatal(srv.ListenAndServeTLS(tls_root + "server.crt", tls_root +
"server.key"))
}

func handle(w http.ResponseWriter, r *http.Request) {
//log.Printf("Got connection: %s", r.Proto) // prints HTTP/2.0
fmt.Fprintf(w, "Hello World")
}
==

Here Vegeta makes around 13K reqs/sec without error responses.

To run this app do: go run http2-server.go


> Regards,
> Martin
>


Low throughput with HTTP2

2020-09-15 Thread Martin Grigorov
Hi,

I am running some load tests on Tomcat and I've noticed that when HTTP2 is
enabled the throughput drops considerably.

Here are the steps to reproduce:

1) Enable HTTP2, e.g. by commenting out this connector:
https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f317c135d9d/conf/server.xml#L103-L112

2) Download Vegeta load tool from:
https://github.com/tsenart/vegeta/releases/

3) Run the load tests:

3.1) HTTP/1.1
echo -e '{"method": "GET", "url": "http://localhost:8080/examples/"}' |
vegeta attack -format=json  -rate=0 -max-workers=1000 -duration=10s |
vegeta encode > /tmp/http1.json; and vegeta report -type=json
/tmp/http1.json | jq .

3.2) HTTP2
echo -e '{"method": "GET", "url": "https://localhost:8443/examples/"}' |
vegeta attack -format=json -http2 -rate=0 -max-workers=1000 -insecure
-duration=10s | vegeta encode > /tmp/http2.json; and vegeta report
-type=json /tmp/http2.json | jq .

As explained at https://github.com/tsenart/vegeta#-rate -rate=0 means that
Vegeta will try to send as many requests as possible with the configured
number of workers.
I use '-insecure' because I use self-signed certificate.

On my machine I get around 14-15K reqs/sec for HTTP1.1 with only responses
with code=200 .
But for HTTP2 Tomcat starts returning such kind of errors:

 "errors": [
"Get \"https://localhost:8443/examples/\": http2: server sent GOAWAY
and closed the connection; LastStreamID=9259, ErrCode=PROTOCOL_ERROR,
debug=\"Stream [9,151] has been closed for some time\"",
"http2: server sent GOAWAY and closed the connection;
LastStreamID=9259, ErrCode=PROTOCOL_ERROR, debug=\"Stream [9,151] has been
closed for some time\"",
"Get \"https://localhost:8443/examples/\": http2: server sent GOAWAY
and closed the connection; LastStreamID=239, ErrCode=PROTOCOL_ERROR,
debug=\"Stream [49] has been closed for some time\""
  ]

when I ask for more than 2000 reqs/sec, i.e. -rate=2000/1s


All the access logs look like:

127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
1126
127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
1126
127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
1126
127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
1126
127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
1126
127.0.0.1 - - [15/Sep/2020:13:59:24 +0300] "GET /examples/ HTTP/2.0" 200
1126

i.e. there are no error codes, just 200.
Vegeta reports the error with status code = 0. I think this just means that
it didn't get a proper HTTP response but just TCP error.
There are no errors in catalina.out.

Are there any settings I can tune to get better throughput with HTTP2 ?

Tomcat 10.0.0-M8.

Regards,
Martin


Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-09-15 Thread Martin Grigorov
hi,

On Tue, Sep 15, 2020 at 8:20 AM Pratik Shrestha  wrote:

> Hi Guys,
>
> Just wanted to know if anyone found an idea on fixing it or a workaround.
>

Did you find what is the expected behavior by Qualis ?


>
> Thanks
>
> Pratik.
>
> On Fri, Aug 28, 2020 at 10:46 AM Pratik Shrestha 
> wrote:
>
> > Hi Chris
> >
> >
> >
> >
> > *This wasn't the case for httpd for many years. I don't know what itdoes
> > these days, but it used to reply with a nice "400 Bad Request"error just
> > like Tomcat is doing. The difference is that httpd has richconfiguration
> > options to allow you to override that behavior. *
> >
> > Correct. By default HTTP also gives 400 Bad Request message. But we can
> > override this behavior by using ErrorDocument directive to redirect to
> > https URL. Currently in Tomcat this feature is not available. Tomcat has
> > RewriteValve but it does not work in this case.
> >
> > On Fri, Aug 28, 2020 at 12:30 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Merka,
> >>
> >> On 8/27/20 06:32, Phoenix, Merka wrote:
> >> > I think what the Qualys scan is trying to flag is that the server
> >> > (Tomcat) is listening for both secured and unsecured traffic on
> >> > the _same_ TCP port when the server should be listening for just
> >> > one of the two options (unsecured or secured), not both.
> >> This actually might be a semi-legitimate test. If the client says "Our
> >> policy is to only communicate using encrypted connections" and the
> >> test says "well, here's a non-encrypted connection right here!" then
> >> it makes some small amount of sense. In that case, it's all driven by
> >> policy, and the policy can say "we have a carve-out for TLS handshake
> >> failures" and then allow that particular test to pass.
> >>
> >> > The error message returned by the Tomcat service, while certainly
> >> > helpful to the remote client, is returning more information than
> >> > it should (from a security-viewpoint).
> >> Not really.
> >>
> >> > If the default behavior for Tomcat is to return this "helpful"
> >> > message for misconfigured clients, would it be reasonable for the
> >> > Connector to have an option (attribute) for turning off this
> >> > feature and simply reject with a TLS error any unsecured traffic on
> >> > the port? This would address the security concern without imposing
> >> > too much "bloat" to the Tomcat side.
> >> I think this might actually be better/easier than implementing a
> >> redirect. It's a simple flag that says "return nice errors on
> >> plaintext-over-TLS connection attempts" (or similar) and the only
> >> thing that changes is that we STOP trying to be nice to the client if
> >> the setting is set to "fail" versus "be-nice".
> >>
> >> > For most other web servers (Apache httpd, NGINX, etc.) that offer
> >> > https, the normal behavior is that when an http client tries to
> >> > speak http to server expecting https, the client sees some garbled
> >> > text (the server's TLS response to the connection attempt).
> >> This wasn't the case for httpd for many years. I don't know what it
> >> does these days, but it used to reply with a nice "400 Bad Request"
> >> error just like Tomcat is doing. The difference is that httpd has rich
> >> configuration options to allow you to override that behavior.
> >>
> >> - -chris
> >> -BEGIN PGP SIGNATURE-
> >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >>
> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9H7ZkACgkQHPApP6U8
> >> pFgOng/8DtMJkQc+MYLRm1iuCD7GZ2f2S7oQ59vFeCGAbmkiUjESvQ42QRGqIMy8
> >> 47giFc3ERm84DxyyyU7O/YDFxinOnCrC/v9A6RzpYKlZBSOq9Oy6732xTUAqGGIw
> >> +3QGPXvyjE2Vcg1iavW+7cUKN1Q9R1NGcDRRBpBL0KRQMA3NV9pxGU71/In8TQvi
> >> VZ51f7VTNXaJ2l+w6G23XBJkKQk3csFixevVzr4Xr56FLfqPxUc3m6QNu4BaHmgb
> >> c95hceV/N7tkR9yHdaRtahpZq0lhGqXbNXfqjf7kElSkRmeAZ3MSsdnFD4fBHThn
> >> xvz204xffSE71Z4W24W9gx23+Bg0y2EfPRo1CWC93rEvNRKMK6ILzLczTRA0w6QW
> >> 9zP1XC+VwC25LQOGFDgFukQVupPYiMoNSb6DRey5ZUhur6v25nevwbhM0QsAm/oO
> >> oZpreKaUMy+ZoixwGhaZ+UFiZRav7DRLSj85BjK9PqcP4VdPzFR9MarvMqLPxRoq
> >> YxL/jNet4L+29Z2tDkZv4gfGJqI7oWkfXUsBFBjj5JgXrqE94Q8PzAK87pLeU80y
> >> p3IL4krovHbu01j1fE3/aDotEvBu/wxWTCWze9+vL09a82PuTT2pihyCVqFuP9rS
> >> kP0DtVTfbaUMyD2dryjyw4q1NdLYht4y/HHkyU/3cPopCbxEopU=
> >> =4F4z
> >> -END PGP SIGNATURE-
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
>


[ANN] Apache Tomcat 10.0.0-M8 available

2020-09-15 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.0-M8.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is under development to aid
this process.

Apache Tomcat 10.0.0-M8 is a milestone release of the 10.0.x
branch and has been made to provide users with early access to the new
features in Apache Tomcat 10.0.x so that they may provide feedback. The
notable changes compared to 10.0.0-M7 include:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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