[Bug 64606] New: Note The full stack trace of the root cause is available in the server logs.

[bugzilla]

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

Bug ID: 64606
   Summary: Note The full stack trace of the root cause is
available in the server logs.
   Product: Tomcat 9
   Version: 9.0.35
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet
  Assignee: dev@tomcat.apache.org
  Reporter: 13218138...@163.com
  Target Milestone: -

HTTP Status 400 – Bad Request

Type Exception Report

Message Invalid character found in the request target. The valid characters are
defined in RFC 7230 and RFC 3986

Description The server cannot or will not process the request due to something
that is perceived to be a client error (e.g., malformed request syntax, invalid
request message framing, or deceptive request routing).

Exception

java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:489)
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:748)

Note The full stack trace of the root cause is available in the server logs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 64606] Note The full stack trace of the root cause is available in the server logs.

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Mark Thomas  ---
Bugzilla is not a support forum. Please use the users mailing list.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 64606] Note The full stack trace of the root cause is available in the server logs.

[bugzilla]

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

--- Comment #2 from mengjisheng <13218138...@163.com> ---
(In reply to Mark Thomas from comment #1)
> Bugzilla is not a support forum. Please use the users mailing list.

When a user enters an incorrect URL on the page, Tomcat displays the abnormal
stack on the page for external users. External users can obtain the call chain
information of our services. Therefore, we consider this a security
vulnerability.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Native Image - Reflectionless Concept

[Rémy Maucherat]

On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:

> for discussion, all feedback and questions welcome:
>
>
> I've created a concept of having Apache Tomcat, embedded, run without
> reflection in a native image.
> This concept creates a jar, tomcat-embedded-programmatic.jar, that can be
> fine tuned to only include what is needed in a default configuration when
> an embedded tomcat instance is used and configured programatically.
>
> Steps to run Apache Tomcat using Java 8 without reflection
>
>1. Make sure you have native-image (from the graal installation) on
>your path
>2. git clone -b feature/embed-minimal-programmatic-jar-file-master
>g...@github.com:fhanik/tomcat.git
>3. cd tomcat/res/graal/
>4. ./build-tomcat-native-image.sh && ./graal-measure.sh
>
> Should yield an output similar to (Graal 20.1):
> SUCCESS: the servlet is working
> RSS memory: 20.7M
> Image size: 20.5M
>
>
> or using an older graal, 19.2
> SUCCESS: the servlet is working
> RSS memory: 18.0M
> Image size: 16.7M
>
>
> This also leaves a file named ${java.io.tmpdir}/
> XReflectionIntrospectionUtils.java so that you can review the solution to
> IntrospectionUtils.java
>
> Goals of this concept
>
>1. Do not break anything
>2. Create a new and optimized for size artifact,
>tomcat-embedded-programmatic
>3. Remove reflection by introspecting classes that are currently
>passed into IntrospectionUtils.set/getProperty by generating
>setters/getters at build time
>
> How it's done
>
>1. I've build out a small introspection tool in the package
>org.apache.tomcat.util.xreflect
>2. During build time, it analyses a set of known classes that are used
>with IntrospectionUtils.java, and generates
>XReflectionIntrospectionUtils.java
>3. When it packages tomcat-embed-programmatic.jar it uses the
>generated code when calling setProperty and getProperty
>
> A PR would look like this:
>
> https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1
>
>
Well, this is a bit complex and hard to maintain (like, for example,
storeconfig), so that's a downside.

So starting with Tomcat and its initial server.xml, the process would be:
server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat embedded
code with custom IntrospectionUtils code
The concrete benefits may be limited though.

I looked at more code generation for web.xml since the digester is nice for
that, but the benefit becomes even more questionable. It is harder to
manage, and the generated classes have to be loaded dynamically [unless
even more code is generated]. If there are tons of fragments, there is a
good intuitive reason why it becomes useless. so I didn't want to do it. I
prefer if things remain a bit EE-ish, ultimately.

Rémy

Re: Native Image - Reflectionless Concept

[Romain Manni-Bucau]

Hi everyone,

I think the generation is the sanest option since code stay clean but it
shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
(mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
This build phase would dump the descriptors in plain java and would load
them with an unique - ie single for the whole webapp - plain SPI -
ServiceLoader - maybe?
This kind of build tool assumes you have all the runtime state in the build
- which is typically the case for graalvm - so you can completely dump
StandardContext state after start phase there and just reload it from the
precomputed model.
Only trick is about file paths which must either be recomputed or be
configurable to another base but it does not sound crazy.

The less tool-ed option would be to extract all "reflectionfull" code in
methods and use graalvm substitutions to drop them and use plain java
instead (with a good naming convention, it can be generated as well).
Keeps the duplication but at least the main code stays clean and
optimizations stays together.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a écrit :

> On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:
>
>> for discussion, all feedback and questions welcome:
>>
>>
>> I've created a concept of having Apache Tomcat, embedded, run without
>> reflection in a native image.
>> This concept creates a jar, tomcat-embedded-programmatic.jar, that can be
>> fine tuned to only include what is needed in a default configuration when
>> an embedded tomcat instance is used and configured programatically.
>>
>> Steps to run Apache Tomcat using Java 8 without reflection
>>
>>1. Make sure you have native-image (from the graal installation) on
>>your path
>>2. git clone -b feature/embed-minimal-programmatic-jar-file-master
>>g...@github.com:fhanik/tomcat.git
>>3. cd tomcat/res/graal/
>>4. ./build-tomcat-native-image.sh && ./graal-measure.sh
>>
>> Should yield an output similar to (Graal 20.1):
>> SUCCESS: the servlet is working
>> RSS memory: 20.7M
>> Image size: 20.5M
>>
>>
>> or using an older graal, 19.2
>> SUCCESS: the servlet is working
>> RSS memory: 18.0M
>> Image size: 16.7M
>>
>>
>> This also leaves a file named ${java.io.tmpdir}/
>> XReflectionIntrospectionUtils.java so that you can review the solution
>> to IntrospectionUtils.java
>>
>> Goals of this concept
>>
>>1. Do not break anything
>>2. Create a new and optimized for size artifact,
>>tomcat-embedded-programmatic
>>3. Remove reflection by introspecting classes that are currently
>>passed into IntrospectionUtils.set/getProperty by generating
>>setters/getters at build time
>>
>> How it's done
>>
>>1. I've build out a small introspection tool in the package
>>org.apache.tomcat.util.xreflect
>>2. During build time, it analyses a set of known classes that are
>>used with IntrospectionUtils.java, and generates
>>XReflectionIntrospectionUtils.java
>>3. When it packages tomcat-embed-programmatic.jar it uses the
>>generated code when calling setProperty and getProperty
>>
>> A PR would look like this:
>>
>> https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1
>>
>>
> Well, this is a bit complex and hard to maintain (like, for example,
> storeconfig), so that's a downside.
>
> So starting with Tomcat and its initial server.xml, the process would be:
> server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat
> embedded code with custom IntrospectionUtils code
> The concrete benefits may be limited though.
>
> I looked at more code generation for web.xml since the digester is nice
> for that, but the benefit becomes even more questionable. It is harder to
> manage, and the generated classes have to be loaded dynamically [unless
> even more code is generated]. If there are tons of fragments, there is a
> good intuitive reason why it becomes useless. so I didn't want to do it. I
> prefer if things remain a bit EE-ish, ultimately.
>
> Rémy
>
>

Re: Native Image - Reflectionless Concept

[Filip Hanik]

Thanks for reviewing and engaging.

On 7/16/20 5:31 AM, Rémy Maucherat wrote:
On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik > wrote:


for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded, run
without reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar, that
can be fine tuned to only include what is needed in a default
configuration when an embedded tomcat instance is used and
configured programatically.

Steps to run Apache Tomcat using Java 8 without reflection

 1. Make sure you have native-image (from the graal installation)
on your path
 2. git clone -b
feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
 3. cd tomcat/res/graal/
 4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M


This also leaves a file named
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that you
can review the solution to IntrospectionUtils.java

Goals of this concept

 1. Do not break anything
 2. Create a new and optimized for size artifact,
tomcat-embedded-programmatic
 3. Remove reflection by introspecting classes that are currently
passed into IntrospectionUtils.set/getProperty by generating
setters/getters at build time

How it's done

 1. I've build out a small introspection tool in the package
org.apache.tomcat.util.xreflect
 2. During build time, it analyses a set of known classes that are
used with IntrospectionUtils.java, and generates
XReflectionIntrospectionUtils.java
 3. When it packages tomcat-embed-programmatic.jar it uses the
generated code when calling setProperty and getProperty

A PR would look like this:

https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1


Well, this is a bit complex and hard to maintain (like, for example, 
storeconfig), so that's a downside.


It is keeping track of one more artifact, tomcat-embed-programmatic.

Right now, it is manually maintaining the list of classes that it 
generates setProperty/getProperty for. I derived this list by running 
the test suite. There is of course an option to fully automate this.




So starting with Tomcat and its initial server.xml, the process would be:
server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat 
embedded code with custom IntrospectionUtils code

The concrete benefits may be limited though.
The goal of this artifact is to actually strip all non programmatic code 
and bring down the code base to minimum bare essentials.


That means, it's not for applications that want to deploy a WAR file, or 
do XML based configuration. My primary use case, is a Spring Boot 
application where the framework servlets and filters are configured 
programmatically, easy for the AOT compiler to work with, and everything 
else is then handled by the framework.


There wouldn't be support by this artifact to handle EE style XML 
configurations, including fragments. That is already done by 
tomcat-embed-core, which is almost 50% larger generated native image 
size in order to support all use cases and features.




I looked at more code generation for web.xml since the digester is 
nice for that, but the benefit becomes even more questionable. It is 
harder to manage, and the generated classes have to be loaded 
dynamically [unless even more code is generated]. If there are tons of 
fragments, there is a good intuitive reason why it becomes useless. so 
I didn't want to do it. I prefer if things remain a bit EE-ish, 
ultimately.


I believe that tomcat-embed-core.jar with its META-INF GraalVM metadata 
files does support the EE feature set quite well, even though, those are 
manually maintained as well.


My primary goal was to create a leaner alternative, targeting images 
that specifically are looking to optimize image size and memory usage.



Thanks for chiming in,

Filip

[Bug 64609] New: Tomcat Error parsing encrypted HTTP request header

[bugzilla]

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

Bug ID: 64609
   Summary: Tomcat Error parsing encrypted HTTP request header
   Product: Tomcat 9
   Version: 9.0.37
  Hardware: Other
OS: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: jeff_z...@yahoo.com
  Target Milestone: -

There are two types of errors that start with "Error parsing HTTP request
header"
1) Invalid character found in the HTTP protocol
2) Invalid character found in method name.
Providing a record of the Http Request Error, Tomcat does not send any response
back to the client.
The socked is not closed and one more Open File added to LFOS (log for open
files).
Eventually number of open files is increased to the limit and Tomcat stops
responding at all.
This situation is covered for regular HTTP request but not for encrypted HTTPS
requests. I am using HTTPS via AWS Cloud Front, worked with AWS support team,
but we could not find a solution. AWS support sincerely tried to help me but
unfortunately failed.
I tried recommended configurations in server.xml and catalina.properties (see
below).
I also tried almost all Tomcat 8.5 versions and the latest Tomcat 9.0.37.

I established ServletFilter class, but it does not help because the error
happens before the filter, in the Tomcat layer. Tomcat has some provisioning
for accepting different character coding in HTTP, but not in HTTPS/encrypted
request.
I highly appreciate anyone who can help here.

Thank you,
Jeff

This is the extract from the standard server.xml



This is the additional two lines in the standard catalina.properties:

# Allow for changes to HTTP request validation
# WARNING: Using this option may expose the server to CVE-2016-6816
tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org