Re: Invalid character found in the request target

[Mark Thomas]

On 04/06/2024 15:37, Christopher Schultz wrote:

On 6/4/24 09:10, Chuck Caldarale wrote:





The problem is the { and } characters.

My reading of RFC 7230 is that { and } /should/ be allowed, but 
Tomcat's code rejects them by default.


My reading is as follows:

RFC 9110:

http-URI = "http" "://" authority path-abempty [ "?" query ]

RFC 3968:

path-abempty  = *( "/" segment )
segment   = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
  / "*" / "+" / "," / ";" / "="

Neither '{' nor '}' are included in unreserved or sub-delims The are not 
pct-encoded. Nor are they ':' or '@'. Therefore, there are not valid for 
use in a segment. If you want to use them, they need to be pct-encoded.


While some of the text of RFC 3968, section 2.3 could be read as 
suggesting other characters are included in unreserved, my reading of 
that section is that the intended definition of unreserved is the 
explicit definition I quoted above.


Mark

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

Re: Invalid character found in the request target

[Christopher Schultz]

Chuck,

On 6/4/24 09:10, Chuck Caldarale wrote:



On Jun 4, 2024, at 06:07, Christopher Schultz  
wrote:







04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
header
  Note: further occurrences of HTTP request parsing errors will be logged at 
DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in the 
request target [/sra_{xxx0---yy}/ ]. The valid 
characters are defined in RFC 7230 and RFC 3986


The problem is the { and } characters.

My reading of RFC 7230 is that { and } /should/ be allowed, but Tomcat's code 
rejects them by default.



I think it depends on which part of RFC 3986 one looks at. Appendix A should 
have the precise URI syntax, where the reserved and unreserved sets are defined 
as follows:

unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved  = gen-delims / sub-delims
gen-delims= ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
  / "*" / "+" / "," / ";" / "="

Some ASCII characters, notably braces, are simply left out of either set here. 
However, section 2.3 declares:

Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved.  These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.

The use of “include” would seem to imply “not limited to”, but that’s not 
explicitly stated here.

Nothing like a little ambiguity to keep things interesting…


Yup. RFC 3986 does not include the { character anywhere in the text. RFC 
7230 mentions it as a character not allowed in "field values" which I 
think only applies to headers unless you consider the "request line" 
to be "header 0" or somesuch.


At any rate, characters such as { and } could be considered "dangerous" 
and so, while I would argue the RFC doesn't prohibit them, Tomcat's 
refusal to accept them under a default configuration is a reasonable 
one... especially because you can simply re-enable them if your 
application needs them.


-chris

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

Re: Invalid character found in the request target

[Chuck Caldarale]

> On Jun 4, 2024, at 06:07, Christopher Schultz  
> wrote:





>> 04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6] 
>> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
>> header
>>  Note: further occurrences of HTTP request parsing errors will be logged at 
>> DEBUG level.
>> java.lang.IllegalArgumentException: Invalid character found in the 
>> request target [/sra_{xxx0---yy}/ ]. The valid 
>> characters are defined in RFC 7230 and RFC 3986
> 
> The problem is the { and } characters.
> 
> My reading of RFC 7230 is that { and } /should/ be allowed, but Tomcat's code 
> rejects them by default.


I think it depends on which part of RFC 3986 one looks at. Appendix A should 
have the precise URI syntax, where the reserved and unreserved sets are defined 
as follows:

   unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
   reserved  = gen-delims / sub-delims
   gen-delims= ":" / "/" / "?" / "#" / "[" / "]" / "@"
   sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
 / "*" / "+" / "," / ";" / "="

Some ASCII characters, notably braces, are simply left out of either set here. 
However, section 2.3 declares:

   Characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include uppercase and lowercase
   letters, decimal digits, hyphen, period, underscore, and tilde.

The use of “include” would seem to imply “not limited to”, but that’s not 
explicitly stated here.

Nothing like a little ambiguity to keep things interesting…

  - Chuck


> You can override this behavior by using the relaxedPathChars configuration 
> attribute on your [1].
> 
> -chris
> 
> [1] https://tomcat.apache.org/tomcat-9.0-doc/config/http.html

Re: Invalid character found in the request target

[Christopher Schultz]

Christoph,

On 6/4/24 05:49, Christoph Kukulies wrote:

I'm getting these when startig tomcat9:


This is a request, not startup. But it's not important.


04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
header
  Note: further occurrences of HTTP request parsing errors will be logged at 
DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in the 
request target [/sra_{xxx0---yy}/ ]. The valid 
characters are defined in RFC 7230 and RFC 3986
 at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:502)
 at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:271)
 at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
 at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1735)
 at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
 at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
 at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
 at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.base/java.lang.Thread.run(Thread.java:829)

Any clues?


The problem is the { and } characters.

My reading of RFC 7230 is that { and } /should/ be allowed, but Tomcat's 
code rejects them by default.


You can override this behavior by using the relaxedPathChars 
configuration attribute on your [1].


-chris

[1] https://tomcat.apache.org/tomcat-9.0-doc/config/http.html

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

Invalid character found in the request target

[Christoph Kukulies]

I'm getting these when startig tomcat9:


04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
header
 Note: further occurrences of HTTP request parsing errors will be logged at 
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the 
request target [/sra_{xxx0---yy}/ ]. The valid 
characters are defined in RFC 7230 and RFC 3986
at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:502)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:271)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1735)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:829)

Any clues?

System is Ubuntu 64 22.04.

TIA,

Christoph


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

Re: How to access the request URL in a custom valve implementation?

[Tim Funk]

See AbstractAccessLogValve (which AccessLogValve overrides)

Then you could override AbstractAccessLogValve.createAccessLogElement()
which has
case 'q':
return new QueryElement();

To possible do doing something like
case 'q':
return new ObfuscatedQueryElement();

Where ObfuscatedQueryElement is much like the existing QueryElement with
your additional requirements.
 They both would implement AccessLogElement which has access to the
Request object

-Tim

On Fri, Jan 26, 2024 at 7:58 AM Manak Bisht  wrote:

> I want to obfuscate values of query params for certain URLs, however, I
> would still like to log the request. Therefore, I cannot use the existing
> conditionif/conditionunless attributes that AccessLogValve provides.
>
>

Re: How to access the request URL in a custom valve implementation?

[Manak Bisht]

I want to obfuscate values of query params for certain URLs, however, I
would still like to log the request. Therefore, I cannot use the existing
conditionif/conditionunless attributes that AccessLogValve provides.

Sincerely,
Manak Bisht

On Fri, Jan 26, 2024 at 6:18 PM Mark Thomas  wrote:

> On 26/01/2024 10:46, Manak Bisht wrote:
> > Hi,
> > I am trying to extend the AccessLogValve to modify logging behaviour for
> > certain URLs. However, I don't have access to the request object in the
> > AccessLogValve API. So, I am left with regex matching on the
> CharArrayWriter
> > message object. Is there a better way to do this?
>
> It depends what you are trying to do - which you haven't explained.
>
> You have direct access to the request object in the invoke() method.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: How to access the request URL in a custom valve implementation?

[Mark Thomas]

On 26/01/2024 10:46, Manak Bisht wrote:

Hi,
I am trying to extend the AccessLogValve to modify logging behaviour for
certain URLs. However, I don't have access to the request object in the
AccessLogValve API. So, I am left with regex matching on the CharArrayWriter
message object. Is there a better way to do this?


It depends what you are trying to do - which you haven't explained.

You have direct access to the request object in the invoke() method.

Mark

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

Re: How to access the request URL in a custom valve implementation?

[Tim Funk]

My bad - AccessLogValve also supports that feature too

   - *%{xxx}r* write value of ServletRequest attribute with name xxx (escaped
   if required, value ?? if request is null)

https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Logging

-Tim


On Fri, Jan 26, 2024 at 7:23 AM Tim Funk  wrote:

> It depends on what you are trying to accomplish. ExtendedAccessLogValve is
> a
> little more flexible where you can write out arbitrary request
> attributes but still format the request like the standard access
> log. So you could have a filter set the value and not need to
> write your own access logger.
>
> -Tim
>
> On Fri, Jan 26, 2024 at 5:47 AM Manak Bisht 
> wrote:
>
>> Hi,
>> I am trying to extend the AccessLogValve to modify logging behaviour for
>> certain URLs. However, I don't have access to the request object in the
>> AccessLogValve API. So, I am left with regex matching on the
>> CharArrayWriter
>> message object. Is there a better way to do this?
>>
>

Re: How to access the request URL in a custom valve implementation?

[Tim Funk]

It depends on what you are trying to accomplish. ExtendedAccessLogValve is
a
little more flexible where you can write out arbitrary request
attributes but still format the request like the standard access
log. So you could have a filter set the value and not need to
write your own access logger.

-Tim

On Fri, Jan 26, 2024 at 5:47 AM Manak Bisht  wrote:

> Hi,
> I am trying to extend the AccessLogValve to modify logging behaviour for
> certain URLs. However, I don't have access to the request object in the
> AccessLogValve API. So, I am left with regex matching on the
> CharArrayWriter
> message object. Is there a better way to do this?
>

How to access the request URL in a custom valve implementation?

[Manak Bisht]

Hi,
I am trying to extend the AccessLogValve to modify logging behaviour for
certain URLs. However, I don't have access to the request object in the
AccessLogValve API. So, I am left with regex matching on the CharArrayWriter
message object. Is there a better way to do this?

Sincerely,
Manak Bisht

RE: JAVA -tomcat- Request header is too large

[Amit Pande]

Thank you, Chris.

Right now, we're on 9.x line. But this is a very important and useful field for 
debugging which we should be aware of.

Thanks,
Amit

-Original Message-
From: Christopher Schultz  
Sent: Monday, December 11, 2023 2:02 PM
To: users@tomcat.apache.org
Subject: Re: JAVA -tomcat- Request header is too large


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



Amit,

On 12/11/23 11:32, Amit Pande wrote:
> Mark, Chris,
>
> What request ID we're referring to here? Perhaps, I missed some documentation?
>
> How do we enable it?

Request-id is available in Tomcat 11.0 and 10.1 at the moment. Are you using 
either of those?

I'm not seeing any documentation in the AccessLogValve for reporting that value 
anywhere...

-chris

> -Original Message-
> From: Mark Thomas 
> Sent: Monday, December 11, 2023 3:06 AM
> To: users@tomcat.apache.org
> Subject: Re: JAVA -tomcat- Request header is too large
>
>
> CAUTION: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. If you believe this is a phishing email, use the Report to 
> Cybersecurity icon in Outlook.
>
>
>
> On 08/12/2023 22:01, Christopher Schultz wrote:
>
> 
>
>> Are request-ids always allocated, or only if they are "enabled"?
>
> Always allocated.
>
>> I think adding the request-id to this exception detail message might 
>> be helpful, even if the request-id hasn't been enabled in the access-log.
>>
>> WDYT?
>
> Good point. More widely, we should probably be adding the request ID to every 
> request related error message.
>
> 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
>

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

Re: JAVA -tomcat- Request header is too large

[Christopher Schultz]

Amit,

On 12/11/23 11:32, Amit Pande wrote:

Mark, Chris,

What request ID we're referring to here? Perhaps, I missed some documentation?

How do we enable it?


Request-id is available in Tomcat 11.0 and 10.1 at the moment. Are you 
using either of those?


I'm not seeing any documentation in the AccessLogValve for reporting 
that value anywhere...


-chris


-Original Message-
From: Mark Thomas 
Sent: Monday, December 11, 2023 3:06 AM
To: users@tomcat.apache.org
Subject: Re: JAVA -tomcat- Request header is too large


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



On 08/12/2023 22:01, Christopher Schultz wrote:




Are request-ids always allocated, or only if they are "enabled"?


Always allocated.


I think adding the request-id to this exception detail message might
be helpful, even if the request-id hasn't been enabled in the access-log.

WDYT?


Good point. More widely, we should probably be adding the request ID to every 
request related error message.

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



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

RE: JAVA -tomcat- Request header is too large

[Amit Pande]

Mark, Chris,

What request ID we're referring to here? Perhaps, I missed some documentation?

How do we enable it? 

Thanks,
Amit

-Original Message-
From: Mark Thomas  
Sent: Monday, December 11, 2023 3:06 AM
To: users@tomcat.apache.org
Subject: Re: JAVA -tomcat- Request header is too large


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



On 08/12/2023 22:01, Christopher Schultz wrote:



> Are request-ids always allocated, or only if they are "enabled"?

Always allocated.

> I think adding the request-id to this exception detail message might 
> be helpful, even if the request-id hasn't been enabled in the access-log.
>
> WDYT?

Good point. More widely, we should probably be adding the request ID to every 
request related error message.

Mark

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

Re: JAVA -tomcat- Request header is too large

[Mark Thomas]

On 08/12/2023 22:01, Christopher Schultz wrote:




Are request-ids always allocated, or only if they are "enabled"?


Always allocated.

I think adding the request-id to this exception detail message might be 
helpful, even if the request-id hasn't been enabled in the access-log.


WDYT?


Good point. More widely, we should probably be adding the request ID to 
every request related error message.


Mark

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

Re: JAVA -tomcat- Request header is too large

[Christopher Schultz]

Mark,

On 12/8/23 06:50, Mark Thomas wrote:

On 08/12/2023 09:27, Ivano Luberti wrote:


Il 07/12/2023 17:51, Mark Thomas ha scritto:

On 07/12/2023 15:37, Ivano Luberti wrote:

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like 
this:


... />


Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception 
was raised?


Match the timestamp in the logs with the timestamp in the access logs 
of the associated 400 response.


Mark


Thank you Mark.

Finding the exception in log files led me to think there was noting in 
the access log.


Is there any way to log the header content so I can find what is 
causing the issue?


You can try enabling debug logging for 
org.apache.coyote.http11.Http11InputBuffer


Are request-ids always allocated, or only if they are "enabled"?

I think adding the request-id to this exception detail message might be 
helpful, even if the request-id hasn't been enabled in the access-log.


WDYT?

-chris

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

Re: JAVA -tomcat- Request header is too large

[Mark Thomas]

On 08/12/2023 09:27, Ivano Luberti wrote:


Il 07/12/2023 17:51, Mark Thomas ha scritto:

On 07/12/2023 15:37, Ivano Luberti wrote:

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like 
this:


... />


Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception was 
raised?


Match the timestamp in the logs with the timestamp in the access logs 
of the associated 400 response.


Mark


Thank you Mark.

Finding the exception in log files led me to think there was noting in 
the access log.


Is there any way to log the header content so I can find what is causing 
the issue?


You can try enabling debug logging for 
org.apache.coyote.http11.Http11InputBuffer


Mark

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

Re: JAVA -tomcat- Request header is too large

[Ivano Luberti]

Il 07/12/2023 17:51, Mark Thomas ha scritto:

On 07/12/2023 15:37, Ivano Luberti wrote:

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like 
this:


... />


Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception was 
raised?


Match the timestamp in the logs with the timestamp in the access logs 
of the associated 400 response.


Mark


Thank you Mark.

Finding the exception in log files led me to think there was noting in 
the access log.


Is there any way to log the header content so I can find what is causing 
the issue?



--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 
<http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf>


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: JAVA -tomcat- Request header is too large

[Mark Thomas]

On 07/12/2023 15:37, Ivano Luberti wrote:

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like this:



Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception was 
raised?


Match the timestamp in the logs with the timestamp in the access logs of 
the associated 400 response.


Mark

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

JAVA -tomcat- Request header is too large

[Ivano Luberti]

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like this:



Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception was 
raised?





--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 
<http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf>


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Christopher Schultz]

Graham,

On 11/28/23 14:11, Graham Leggett wrote:

On 28 Nov 2023, at 18:42, Christopher Schultz  
wrote:


In your debugger, when you break-on-exception, what happens if you allow the 
exception to propagate up to the first exception-handler? Does Tomcat swallow 
the exception? Or it it caught elsewhere?


The exception eventually ends up inside ErrorReportValve, but I’m debugging a 
remote box and don’t have any of the source code tied up - will do further 
digging.


When you say you have an "unmarshalling problem"... do you mean in your own application? 
Or something in Tomcat? (I can't think of anything in Tomcat we'd call "unmarshalling", 
but I figure I'd ask.)


I’m in dependency hell - java8 to java17, JAXB as used by Jersey2 broke. No 
idea why, but an internal Oracle implementation is hardcoded somewhere.


Might I recommend a more modest upgrade first, like to Java 11? I know 
it seems like a "bad thing" (Java 17 is more better, and if we are gonna 
move, let's move to the latest... uh, okay next-to-latest) but you may 
find that fewer things break at once and you can fix those fewer things 
more easily than if you break 10 things at once and have a harder time 
figuring out which things are broken for which reasons and not for other 
reasons which are breaking other things :)


(At $work, we recently had 3 semi-unrelated enhancement requests and the 
testers kept re-opening ALL THREE any time one of them had an issue 
because, workflow-wise, there was overlap. So if one of them was broken 
because of (A), they would re-open all 3 of them even though it was only 
(A) broken and affecting those other things. I finally had to stop 
claiming that more than one was RESOLVED at a time because the (digital) 
paperwork was driving me mad.)


-chris

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

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Christopher Schultz]

Graham,

On 11/29/23 05:01, Graham Leggett wrote:

On 28 Nov 2023, at 21:10, Graham Leggett  wrote:


So the reason we get a 400 Bad Request with no error detail is that we arrive 
at this line with throwable set to null:

https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L129

With no throwable we are eventually led here, which is our generic “an error 
has occurred, not telling you what it is” page:

https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L169


I think I've figured out what is happening, I've not yet figured out why it is 
happening, but we’ve got further.

In my case, a jersey-client v3 API is generating a big non-pretty blob of XML 
on one line (no newlines), and is passing this in a POST request to tomcat9 
listening on a unix domain socket.

If I hijack the unix domain socket with socat, I only see 4096-ish bytes being 
received of a body of size approx 1/4MB (from Content-Length, not chunked). 
This looks suspiciously like the size of one write. Why that’s happening is a 
jersey-client question.

In tomcat9 however, it appears that tomcat is seeing 4096-ish bytes, a closed 
and truncated connection (we have a Content-Length so tomcat9 knows it’s 
truncated), tomcat9 is correctly picking up the request body is too small, and 
is correctly returning 400 Bad Request, but there is no exception or detail 
string, so the admin has no idea this is what’s wrong.



Good sleuthing so far.

Are you able to test this with tomcat 9 listening on a TCP/IP connection 
instead of the UNIX domain socket? That capability is fairly new and 
it's possible there are some implementation bugs in there.


The (missing) newlines (not) in the XML are probably not a problem: 
Tomcat doesn't care, anyway. "Fixing" the format of the XML probably 
won't change a thing.


It would be great to get the /actual/ size of that 4096-ish-byte stream 
you are able to see... even if you have to copy/paste the string into a 
file and count the bytes yourself.


Can you tell if the client is trying to write more than that first 4096 
bytes?


Back to the actual error message: so... Tomcat 9 is detecting the bogus 
request (Content-Type and actual bytes-on-the-wire seem to be 
mismatched) and so there is no exception; just a vanilla 400 error with 
nothing the administrator can use for debugging.


Did Mark's instructions yield any useful information (e.g. "Tomcat has 
detected that the Content-Type and actual-request-length don't match so, 
400 goodbye!")?


-chris

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

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 21:10, Graham Leggett  wrote:

> So the reason we get a 400 Bad Request with no error detail is that we arrive 
> at this line with throwable set to null:
> 
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L129
> 
> With no throwable we are eventually led here, which is our generic “an error 
> has occurred, not telling you what it is” page:
> 
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L169

I think I've figured out what is happening, I've not yet figured out why it is 
happening, but we’ve got further.

In my case, a jersey-client v3 API is generating a big non-pretty blob of XML 
on one line (no newlines), and is passing this in a POST request to tomcat9 
listening on a unix domain socket.

If I hijack the unix domain socket with socat, I only see 4096-ish bytes being 
received of a body of size approx 1/4MB (from Content-Length, not chunked). 
This looks suspiciously like the size of one write. Why that’s happening is a 
jersey-client question.

In tomcat9 however, it appears that tomcat is seeing 4096-ish bytes, a closed 
and truncated connection (we have a Content-Length so tomcat9 knows it’s 
truncated), tomcat9 is correctly picking up the request body is too small, and 
is correctly returning 400 Bad Request, but there is no exception or detail 
string, so the admin has no idea this is what’s wrong.

Regards,
Graham
—


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

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 29 Nov 2023, at 07:18, Thomas Hoffmann (Speed4Trade GmbH) 
 wrote:

>> I’m in dependency hell - java8 to java17, JAXB as used by Jersey2 broke. No
>> idea why, but an internal Oracle implementation is hardcoded somewhere.
>> 
>> java.lang.ClassNotFoundException: oracle.xml.jaxp.JXSAXParserFactory
> 
> I think you got trapped in the javax-jakarta hell after upgrading.
> As a general recommendation, you should upgrade all libraries in your app.
> Mostly all new versions have switched to using Jakarta.

I have indeed.

I have learned that tomca9 (which I’m stuck on) requires jersey2 (fair enough), 
which in turn requires a lot of code in the javax namespace that is packaged in 
jars in the jakarta namespace.

> Do you use and build system like gradle or maven? 
> They should take care of the new dependencies. Otherwise you have to look it 
> up.
> 
> If some libraries don’t support Jakarta package yet, you have to add the 
> legacy jaxb libs:
> https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl

Maven is being used, but many of the dependencies are optional, and it is not 
clear which versions are required (the latest jakarta versions are too new). 
The advice that I was given was to use the exact same pinned versions of 
everything used by the particular jersey release:

https://github.com/eclipse-ee4j/jersey/blob/2.x/pom.xml#L2313

Regards,
Graham
—

AW: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Graham,

> -Ursprüngliche Nachricht-
> Von: Graham Leggett 
> Gesendet: Dienstag, 28. November 2023 20:12
> An: Tomcat Users List 
> Betreff: Re: 400 Bad Request - where do I find the detailed reason for the
> bad request so I can fix it?
> 
> On 28 Nov 2023, at 18:42, Christopher Schultz 
> wrote:
> 
> > In your debugger, when you break-on-exception, what happens if you
> allow the exception to propagate up to the first exception-handler? Does
> Tomcat swallow the exception? Or it it caught elsewhere?
> 
> The exception eventually ends up inside ErrorReportValve, but I’m
> debugging a remote box and don’t have any of the source code tied up - will
> do further digging.
> 
> > When you say you have an "unmarshalling problem"... do you mean in your
> own application? Or something in Tomcat? (I can't think of anything in Tomcat
> we'd call "unmarshalling", but I figure I'd ask.)
> 
> I’m in dependency hell - java8 to java17, JAXB as used by Jersey2 broke. No
> idea why, but an internal Oracle implementation is hardcoded somewhere.
> 
> java.lang.ClassNotFoundException: oracle.xml.jaxp.JXSAXParserFactory

I think you got trapped in the javax-jakarta hell after upgrading.
As a general recommendation, you should upgrade all libraries in your app.
Mostly all new versions have switched to using Jakarta.

Do you use and build system like gradle or maven? 
They should take care of the new dependencies. Otherwise you have to look it up.

If some libraries don’t support Jakarta package yet, you have to add the legacy 
jaxb libs:
https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl

> Regards,
> Graham
> —

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 19:11, Graham Leggett  wrote:

>> In your debugger, when you break-on-exception, what happens if you allow the 
>> exception to propagate up to the first exception-handler? Does Tomcat 
>> swallow the exception? Or it it caught elsewhere?
> 
> The exception eventually ends up inside ErrorReportValve, but I’m debugging a 
> remote box and don’t have any of the source code tied up - will do further 
> digging.

So the reason we get a 400 Bad Request with no error detail is that we arrive 
at this line with throwable set to null:

https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L129

With no throwable we are eventually led here, which is our generic “an error 
has occurred, not telling you what it is” page:

https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L169

Regards,
Graham
—

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 18:42, Christopher Schultz  
wrote:

> In your debugger, when you break-on-exception, what happens if you allow the 
> exception to propagate up to the first exception-handler? Does Tomcat swallow 
> the exception? Or it it caught elsewhere?

The exception eventually ends up inside ErrorReportValve, but I’m debugging a 
remote box and don’t have any of the source code tied up - will do further 
digging.

> When you say you have an "unmarshalling problem"... do you mean in your own 
> application? Or something in Tomcat? (I can't think of anything in Tomcat 
> we'd call "unmarshalling", but I figure I'd ask.)

I’m in dependency hell - java8 to java17, JAXB as used by Jersey2 broke. No 
idea why, but an internal Oracle implementation is hardcoded somewhere.

java.lang.ClassNotFoundException: oracle.xml.jaxp.JXSAXParserFactory

Regards,
Graham
—

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Christopher Schultz]

Graham,

On 11/28/23 12:12, Graham Leggett wrote:

On 28 Nov 2023, at 09:41, Mark Thomas  wrote:


What do I need to do to see the exception that generated the bad request, so 
that I know specifically what’s wrong and can fix it?


Enabling debug logging for

org.apache.coyote.http11.Http11Processor may help.

It is probably the tightening up of the HTTP parsing that is triggering the 400 
response.


I eventually attached a remote debugger and stopped on all exceptions to get 
it. A problem with unmarshalling was being triggered then replaced with a 
generic 400. We’re now stuck on another bug, same symprom, this time a 500 with 
no exception.

What I’m finding is that the following valve on v9.0.65 has no effect:

 

Instead of rendering the exception in the output, we get the following:

HTTP Status 500 – Internal Server Errorbody {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}HTTP Status 500 – Internal Server ErrorType Status ReportMessage Internal Server ErrorDescription The server encountered an unexpected condition that prevented it from fulfilling the request.Apache Tomcat/9.0.65

Is this a known problem?


In your debugger, when you break-on-exception, what happens if you allow 
the exception to propagate up to the first exception-handler? Does 
Tomcat swallow the exception? Or it it caught elsewhere?


When you say you have an "unmarshalling problem"... do you mean in your 
own application? Or something in Tomcat? (I can't think of anything in 
Tomcat we'd call "unmarshalling", but I figure I'd ask.)


-chris

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

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 09:41, Mark Thomas  wrote:

>> What do I need to do to see the exception that generated the bad request, so 
>> that I know specifically what’s wrong and can fix it?
> 
> Enabling debug logging for
> 
> org.apache.coyote.http11.Http11Processor may help.
> 
> It is probably the tightening up of the HTTP parsing that is triggering the 
> 400 response.

I eventually attached a remote debugger and stopped on all exceptions to get 
it. A problem with unmarshalling was being triggered then replaced with a 
generic 400. We’re now stuck on another bug, same symprom, this time a 500 with 
no exception.

What I’m finding is that the following valve on v9.0.65 has no effect:



Instead of rendering the exception in the output, we get the following:

HTTP Status 500 – Internal Server 
Errorbody {font-family:Tahoma,Arial,sans-serif;} 
h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} 
.line 
{height:1px;background-color:#525D76;border:none;}HTTP 
Status 500 – Internal Server ErrorType Status 
ReportMessage Internal Server ErrorDescription The 
server encountered an unexpected condition that prevented it from fulfilling 
the request.Apache Tomcat/9.0.65

Is this a known problem?

Regards,
Graham
—

[SECURITY] CVE-2023-46589 Apache Tomcat - Request Smuggling

[Mark Thomas]

CVE-2023-46589 Apache Tomcat - Request Smuggling

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M10
Apache Tomcat 10.1.0-M1 to 10.1.15
Apache Tomcat 9.0.0-M1 to 9.0.82
Apache Tomcat 8.5.0 to 8.5.95

Description:
Tomcat did not correctly parse HTTP trailer headers. A specially crafted 
trailer header that exceeded the header size limit could cause Tomcat to 
treat a single request as multiple requests leading to the possibility 
of request smuggling when behind a reverse proxy.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M11 or later
- Upgrade to Apache Tomcat 10.1.16 or later
- Upgrade to Apache Tomcat 9.0.83 or later
- Upgrade to Apache Tomcat 8.5.96 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Norihito Aimoto (OSSTech Corporation).


History:
2023-11-28 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html

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

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Mark Thomas]

On 27/11/2023 20:09, Graham Leggett wrote:

Hi all,

Long running webapps, tomcat recently updated from tomcat7 to tomcat v9.0.65. 
One webapp sends a request to another.

The request fails with a 400 Bad Request, with the detail message "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).”

I am aware what a 400 bad request is, however the message above gives me an 
incomplete list of possible reasons for the bad request, rather than the actual 
specific reason for this specific bad request. Google is filled with generic 
results, and is of no help.

What do I need to do to see the exception that generated the bad request, so 
that I know specifically what’s wrong and can fix it?


Enabling debug logging for

org.apache.coyote.http11.Http11Processor may help.

It is probably the tightening up of the HTTP parsing that is triggering 
the 400 response.


Mark

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

400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

Hi all,

Long running webapps, tomcat recently updated from tomcat7 to tomcat v9.0.65. 
One webapp sends a request to another.

The request fails with a 400 Bad Request, with the detail message "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).”

I am aware what a 400 bad request is, however the message above gives me an 
incomplete list of possible reasons for the bad request, rather than the actual 
specific reason for this specific bad request. Google is filled with generic 
results, and is of no help.

What do I need to do to see the exception that generated the bad request, so 
that I know specifically what’s wrong and can fix it?

Regards,
Graham
—


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

Re: Possible way to avoid Tomcat from recycling the request/response on error?

[Mark Thomas]

On 27/11/2023 01:49, Adwait Kumar Singh wrote:

Hmm, this gives me an impression that the Servlet APIs expect the
request/response processing to *always *happen on the container thread.
If I attempt to perform it on a non-container thread after making the
request async, I run into the risk of the Request/Response objects being
recycled without my non-container thread being aware of it or having to
block my container thread.


The concurrency requirements for asynchronous processing are set out in 
section 2.3.3.4 of the Servlet specification.


Implementing Error handling is significantly more complicated with 
asynchronous servlets but it boils down to avoid accessing the request, 
response and associated objects after complete()/dispatch() have been 
called.


Mark



On Sat, Nov 25, 2023 at 5:42 AM Mark Thomas  wrote:


On 25/11/2023 05:30, Adwait Kumar Singh wrote:


Is there a way around this, to keep the async context open even on an

error

and not close it till complete is invoked?


No. The spec requires the error handler to call complete() in onError()
and error handler doesn't, the container must.

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: Possible way to avoid Tomcat from recycling the request/response on error?

[Adwait Kumar Singh]

Hmm, this gives me an impression that the Servlet APIs expect the
request/response processing to *always *happen on the container thread.
If I attempt to perform it on a non-container thread after making the
request async, I run into the risk of the Request/Response objects being
recycled without my non-container thread being aware of it or having to
block my container thread.

On Sat, Nov 25, 2023 at 5:42 AM Mark Thomas  wrote:

> On 25/11/2023 05:30, Adwait Kumar Singh wrote:
>
> > Is there a way around this, to keep the async context open even on an
> error
> > and not close it till complete is invoked?
>
> No. The spec requires the error handler to call complete() in onError()
> and error handler doesn't, the container must.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Possible way to avoid Tomcat from recycling the request/response on error?

[Mark Thomas]

On 25/11/2023 05:30, Adwait Kumar Singh wrote:


Is there a way around this, to keep the async context open even on an error
and not close it till complete is invoked?


No. The spec requires the error handler to call complete() in onError() 
and error handler doesn't, the container must.


Mark

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

Possible way to avoid Tomcat from recycling the request/response on error?

[Adwait Kumar Singh]

Hi,

I am trying to build a Streaming solution on top of Tomcat and using Async
servlets. What I am doing is I start an asynchronous process using
`startAsync()` and then attach a ReadListener which streams the data
forward `onDataAvailable`, the consumer consumes this on another thread.
Now the problem I am running into is if the there is a
SocketTimeoutException during the read, onError of ReadListener is
triggered and I pass that forward, however I don't call
AsyncContext.complete, because I want the async thread processing the data
to be first able to deal with the exception and then I close it on the
async thread when its done.

However what I am observing is irrespective of if my not closing the
context, it's closed by default by Tomcat and the request/response objects
are recycled. Due to this during the error handling when I am trying to
read some headers I get a IllegalStateException. I don't want to do the
clean up on the IO thread since it can be heavy and I don't want to
overwhelm the IO threads.

Is there a way around this, to keep the async context open even on an error
and not close it till complete is invoked?

Thanks,
Adwait.

[SECURITY] CVE-2023-45648 Apache Tomcat - Request Smuggling

[Mark Thomas]

CVE-2023-45648 Apache Tomcat - Request Smuggling

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M11
Apache Tomcat 10.1.0-M1 to 10.1.13
Apache Tomcat 9.0.0-M1 to 9.0.80
Apache Tomcat 8.5.0 to 8.5.93

Description:
Tomcat did not correctly parse HTTP trailer headers. A specially 
crafted, invalid trailer header could cause Tomcat to treat a single 
request as multiple requests leading to the possibility of request 
smuggling when behind a reverse proxy.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M12 or later
- Upgrade to Apache Tomcat 10.1.14 or later
- Upgrade to Apache Tomcat 9.0.81 or later
- Upgrade to Apache Tomcat 8.5.94 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Keran Mu and Jianjun Chen from Tsinghua University and Zhongguancun 
Laboratory.


History:
2023-10-10 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html

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

Re: Enhancement request?

[Christopher Schultz]

Jon,

On 9/8/23 17:09, Mcalexander, Jon J. wrote:

It would be something that combines all 4 of your items below. I
would be looking for something that can just give health status of
Tomcat and the apps being hosted by that instance. This
wouldn't/shouldn't have any "Admin" rights to do anything other than
provide info. HTML is fine, but I think from an automation and
dashboard reporting standpoint the json/xml stream/soap
response/whatever would be best.
Does the existing non-GUI Manager interface not already provide what you 
are looking for? Or maybe JMX (possibly via the JMXProxyServlet)? Direct 
access to JMX /does/ mean that the connecting client has very high 
privileges, though.



Now, in my possibly short sited view of the world, if wishes were
fishes type of thing, to ME it would be awesome if this was
automagically available via startup without having to do anything
special in the server.xml to make that app available only to
localhost on such and such port. Know what I mean? An instant
statement of health localhost URL. 
I think the term "health[y]" might mean different things to different 
people. I think if you need something to be available that reports 
healthiness of your own service and application, you should probably 
build-to-suit.


-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, September 8, 2023 3:46 PM
To: users@tomcat.apache.org
Subject: Re: Enhancement request?

Jon,

On 9/8/23 14:21, Mcalexander, Jon J. wrote:

In seeing the latest messages about the manager application, something

that I and my team would LOVE to have is just a Status app that provides all
the items status wise that the Manager app does, without any of the
"Application Management" like restarting an app, etc. I know all the pieces
are out there in Catalina.jar, but I don't have the developer knowledge to put
it together in a separate servlet that just calls the items needed from
Catalina.


Is this something that any of the guru's have thought about putting

together? I'm thinking it would be best to just be a web service, no gui, that
you can call and get the json or xml output with the data so it can be
incorporated into a dashboard.

Are you looking for...

1. Something with more limited capabilities (for less-trusted admins, or to
reduce the possibilities for hacking)

2. Something with fewer distractions

3. Something with a JSON/XML interface instead of HTML

4. Something which has fewer lines of code

?

Or some combination of the above, or something else?

-chris

-
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



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

RE: Enhancement request?

[Mcalexander, Jon J.]

It would be something that combines all 4 of your items below. I would be 
looking for something that can just give health status of Tomcat and the apps 
being hosted by that instance. This wouldn't/shouldn't have any "Admin" rights 
to do anything other than provide info. HTML is fine, but I think from an 
automation and dashboard reporting standpoint the json/xml stream/soap 
response/whatever would be best.

Now, in my possibly short sited view of the world, if wishes were fishes type 
of thing, to ME it would be awesome if this was automagically available via 
startup without having to do anything special in the server.xml to make that 
app available only to localhost on such and such port. Know what I mean? An 
instant statement of health localhost URL. 

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Christopher Schultz 
> Sent: Friday, September 8, 2023 3:46 PM
> To: users@tomcat.apache.org
> Subject: Re: Enhancement request?
> 
> Jon,
> 
> On 9/8/23 14:21, Mcalexander, Jon J. wrote:
> > In seeing the latest messages about the manager application, something
> that I and my team would LOVE to have is just a Status app that provides all
> the items status wise that the Manager app does, without any of the
> "Application Management" like restarting an app, etc. I know all the pieces
> are out there in Catalina.jar, but I don't have the developer knowledge to put
> it together in a separate servlet that just calls the items needed from
> Catalina.
> >
> > Is this something that any of the guru's have thought about putting
> together? I'm thinking it would be best to just be a web service, no gui, that
> you can call and get the json or xml output with the data so it can be
> incorporated into a dashboard.
> 
> Are you looking for...
> 
> 1. Something with more limited capabilities (for less-trusted admins, or to
> reduce the possibilities for hacking)
> 
> 2. Something with fewer distractions
> 
> 3. Something with a JSON/XML interface instead of HTML
> 
> 4. Something which has fewer lines of code
> 
> ?
> 
> Or some combination of the above, or something else?
> 
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement request?

[Christopher Schultz]

Jon,

On 9/8/23 14:21, Mcalexander, Jon J. wrote:

In seeing the latest messages about the manager application, something that I and my team 
would LOVE to have is just a Status app that provides all the items status wise that the 
Manager app does, without any of the "Application Management" like restarting 
an app, etc. I know all the pieces are out there in Catalina.jar, but I don't have the 
developer knowledge to put it together in a separate servlet that just calls the items 
needed from Catalina.

Is this something that any of the guru's have thought about putting together? 
I'm thinking it would be best to just be a web service, no gui, that you can 
call and get the json or xml output with the data so it can be incorporated 
into a dashboard.


Are you looking for...

1. Something with more limited capabilities (for less-trusted admins, or 
to reduce the possibilities for hacking)


2. Something with fewer distractions

3. Something with a JSON/XML interface instead of HTML

4. Something which has fewer lines of code

?

Or some combination of the above, or something else?

-chris

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

Enhancement request?

[Mcalexander, Jon J.]

In seeing the latest messages about the manager application, something that I 
and my team would LOVE to have is just a Status app that provides all the items 
status wise that the Manager app does, without any of the "Application 
Management" like restarting an app, etc. I know all the pieces are out there in 
Catalina.jar, but I don't have the developer knowledge to put it together in a 
separate servlet that just calls the items needed from Catalina.

Is this something that any of the guru's have thought about putting together? 
I'm thinking it would be best to just be a web service, no gui, that you can 
call and get the json or xml output with the data so it can be incorporated 
into a dashboard.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: Forwarding request to a different servlet

[Andy Pont]

Chris wrote...


So it looks like the backend service IS being called, but rejecting the request because 
of the "UserAgent" object complaining about it.

I would log the User-Agent header from the request in your front-end before the 
RequestDispatcher.forward() call, and if possible, also log it in your backend 
service just before the "return false”.
I created (copied from the internet) a logging filter implementation for 
dumping the request and everything in that looked correct.  I then went 
for the option of potentially upsetting the user base by enabling all 
logging options on all of the backend’s classes.  It appears that it was 
down to me being an idiot!


In my servlet there is code that says:

ServletContext myContext = request.getServletContext();
ServletContext backendContext = myContext.getContext(“/backend”);

When I was creating the RequestDispatcher to forward the request I was 
including the “/backend” on the front of the URL.  Turns out it wasn’t 
needed and was upsetting some URL filtering!


-Andy.

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

Re: Forwarding request to a different servlet

[Christopher Schultz]

Andy,

On 8/15/23 03:32, Andy Pont wrote:

Chris wrote…

The .forward() should keep all request headers (and many other things) 
in-tact. You might want to log some things in plugins/whatever to see 
what is being done.


You should be using the *same objects* your servlet got for the 
request and response when calling RequestDispatcher.forward(). You can 
"wrap" them if necessary to make certain modifications.
I have put the relevant parts of the source code onto PasteBin [1].  If 
anyone spots any stupid mistakes then please do let me know!


My code has some logging output in it but it doesn’t appear to be being 
added into the log files which are owned and created by the existing 
“backend”.  That is probably just down to me not having the correct 
logger context.


Yes, but I think you should not have to. What are the possible reasons 
for that specific 302 response? Are you *sure* it's complaining about 
the User-Agent string?
The log file from the backend records which Java class the mesage has 
come from so I am fairly confident I am looking in the correct class. 
There appear to be two functions that output the error in the log and 
which endup redirecting to permissionDenied.do [2].  I’m not sure which 
one is being called but the check and end result appear to be the same 
in both.


The UserAgent class that it references is complex (IMO) but as far as I 
can tell it is only looking at the “user-agent” header.


So it looks like the backend service IS being called, but rejecting the 
request because of the "UserAgent" object complaining about it.


I would log the User-Agent header from the request in your front-end 
before the RequestDispatcher.forward() call, and if possible, also log 
it in your backend service just before the "return false".


-chris

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

Re: Forwarding request to a different servlet

[Andy Pont]

Chris wrote…


The .forward() should keep all request headers (and many other things) in-tact. 
You might want to log some things in plugins/whatever to see what is being done.

You should be using the *same objects* your servlet got for the request and response when 
calling RequestDispatcher.forward(). You can "wrap" them if necessary to make 
certain modifications.
I have put the relevant parts of the source code onto PasteBin [1].  If 
anyone spots any stupid mistakes then please do let me know!


My code has some logging output in it but it doesn’t appear to be being 
added into the log files which are owned and created by the existing 
“backend”.  That is probably just down to me not having the correct 
logger context.



Yes, but I think you should not have to. What are the possible reasons for that 
specific 302 response? Are you *sure* it's complaining about the User-Agent 
string?
The log file from the backend records which Java class the mesage has 
come from so I am fairly confident I am looking in the correct class.  
There appear to be two functions that output the error in the log and 
which endup redirecting to permissionDenied.do [2].  I’m not sure which 
one is being called but the check and end result appear to be the same 
in both.


The UserAgent class that it references is complex (IMO) but as far as I 
can tell it is only looking at the “user-agent” header.


-Andy.


1 - https://pastebin.com/yGmxtx6V
2 - https://pastebin.com/4q88V7Pp


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

Re: Forwarding request to a different servlet

[Christopher Schultz]

Andy,

On 8/13/23 04:24, Andy Pont wrote:

I wrote...


Progress of sorts!  The request is now returning 302 instead of 404!

Looking in the log files for the backend, it has a message that says 
“Robot requests must be rejected” and the 302 response is due to a 
redirect to a permission denied page.


My understanding was the .forward() method didn’t change anything on 
route in either direction.

>
Using JD-GUI I have looked at the class that is generates the above 
error message and it appears as the result of a check on the 
“user-agent” setting.  I am now puzzled as what is being received by the 
backend servlet is the same as if it is called directly without me 
intercepting it.


The .forward() should keep all request headers (and many other things) 
in-tact. You might want to log some things in plugins/whatever to see 
what is being done.


You should be using the *same objects* your servlet got for the request 
and response when calling RequestDispatcher.forward(). You can "wrap" 
them if necessary to make certain modifications.


The class I looked at contains a definition of a valid non-robot 
user-agent string.  Is it possible to modify the request to use this 
before forwarding it?


Yes, but I think you should not have to. What are the possible reasons 
for that specific 302 response? Are you *sure* it's complaining about 
the User-Agent string?


If not, am I better creating a new request for 
the backend and copy HTTP header and body content around as needed?


That will be a giant pain in the neck. Could this possibly be done with 
a redirect back through the client?


-chris

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

Re: Forwarding request to a different servlet

[Andy Pont]

I wrote...


Progress of sorts!  The request is now returning 302 instead of 404!

Looking in the log files for the backend, it has a message that says “Robot 
requests must be rejected” and the 302 response is due to a redirect to a 
permission denied page.

My understanding was the .forward() method didn’t change anything on route in 
either direction.
Using JD-GUI I have looked at the class that is generates the above 
error message and it appears as the result of a check on the 
“user-agent” setting.  I am now puzzled as what is being received by the 
backend servlet is the same as if it is called directly without me 
intercepting it.


The class I looked at contains a definition of a valid non-robot 
user-agent string.  Is it possible to modify the request to use this 
before forwarding it?  If not, am I better creating a new request for 
the backend and copy HTTP header and body content around as needed?

-Andy.

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

Re: Forwarding request to a different servlet

[Andy Pont]

Mark wrote...


RequestDispatcher operates within a given ServletContext (web application).

You are trying to do a cross-context dispatch - i.e. to another web 
application. To do this you will need to:

- enable cross-context dispatch for the /plugins web application
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
  look for crossContext

- then use code something like this:

ServletContext current = request.getServletContext();
ServletContext backend = current.getContext("/backend");
RequestDispatcher rd = backend.getRequestDispatcher("/rest/abc/xx");
rd.forward(request,response);


Progress of sorts!  The request is now returning 302 instead of 404!

Looking in the log files for the backend, it has a message that says 
“Robot requests must be rejected” and the 302 response is due to a 
redirect to a permission denied page.


My understanding was the .forward() method didn’t change anything on 
route in either direction.


-Andy.

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

Re: Forwarding request to a different servlet

[Mark Thomas]

RequestDispatcher operates within a given ServletContext (web application).

You are trying to do a cross-context dispatch - i.e. to another web 
application. To do this you will need to:


- enable cross-context dispatch for the /plugins web application
  https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
  look for crossContext

- then use code something like this:

ServletContext current = request.getServletContext();
ServletContext backend = current.getContext("/backend");
RequestDispatcher rd = backend.getRequestDispatcher("/rest/abc/xx");
rd.forward(request,response);

HTH,

Mark


On 11/08/2023 08:52, Andy Pont wrote:

Hello!

We have a commercial application that runs under Tomcat 8.5.65 (on 
Windows Server 2019).  In the tomcat/webapps directory there are the 
following three directories (names changed):


backend
frontend
ROOT

The “frontend” directory contains the UI for the commercial application 
and is, as far as I can tell, all just HTML, JavaScript, etc.  The 
“backend” directory contains the parts of the system that do the bulk of 
the work and appear to be mainly .jsp files.


Amongst other things, the “backend” handles a URL 
https:///backend/rest/abc/xx where “xx” represents a number 
that tells it what to act upon.


I have started developing a new servlet which handles POST requests to 
the URL: https:///plugins/abc/xx.  In some cases (based on 
a values in the request body), the servlet will process things itself 
and generate its own response.   For certain cases it just needs to 
forward the request on to corresponding “backend” URL and then pass the 
response back.


I assumed that .forward(request, response) on a RequestDispatcher would 
be what I needed to use.  I have tried every combination of 
getServletContext() and getRequestDispatcher() I can think of or have 
found on the internet but it always fails with an HTTP error 404.  This 
is because the URL that it is being forwarded to always has a rogue 
“plugins” in it, i.e. https:///plugins/backend/rest/abc/xx.


I suspect the solution is simple but I am new to Tomcat and developing 
servlets and probably missing something obvious.  Any guidance would be 
much appreciated.


-Andy.

-
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: Forwarding request to a different servlet

[Terence M. Bandoian]

Hi, Andy-

I'd suggest looking at:
ServletContext.getContext

and comparing:
ServletContext.getRequestDispatcher with
ServletRequest.getRequestDispatcher

Hope that helps.

-Terence Bandoian

On 8/11/2023 2:52 AM, Andy Pont wrote:

Hello!

We have a commercial application that runs under Tomcat 8.5.65 (on 
Windows Server 2019).  In the tomcat/webapps directory there are the 
following three directories (names changed):


backend
frontend
ROOT

The “frontend” directory contains the UI for the commercial 
application and is, as far as I can tell, all just HTML, JavaScript, 
etc.  The “backend” directory contains the parts of the system that do 
the bulk of the work and appear to be mainly .jsp files.


Amongst other things, the “backend” handles a URL 
https:///backend/rest/abc/xx where “xx” represents a 
number that tells it what to act upon.


I have started developing a new servlet which handles POST requests to 
the URL: https:///plugins/abc/xx. In some cases (based on 
a values in the request body), the servlet will process things itself 
and generate its own response.   For certain cases it just needs to 
forward the request on to corresponding “backend” URL and then pass 
the response back.


I assumed that .forward(request, response) on a RequestDispatcher 
would be what I needed to use.  I have tried every combination of 
getServletContext() and getRequestDispatcher() I can think of or have 
found on the internet but it always fails with an HTTP error 404.  
This is because the URL that it is being forwarded to always has a 
rogue “plugins” in it, i.e. 
https:///plugins/backend/rest/abc/xx.


I suspect the solution is simple but I am new to Tomcat and developing 
servlets and probably missing something obvious.  Any guidance would 
be much appreciated.


-Andy.

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

Forwarding request to a different servlet

[Andy Pont]

Hello!

We have a commercial application that runs under Tomcat 8.5.65 (on 
Windows Server 2019).  In the tomcat/webapps directory there are the 
following three directories (names changed):


backend
frontend
ROOT

The “frontend” directory contains the UI for the commercial application 
and is, as far as I can tell, all just HTML, JavaScript, etc.  The 
“backend” directory contains the parts of the system that do the bulk of 
the work and appear to be mainly .jsp files.


Amongst other things, the “backend” handles a URL 
https:///backend/rest/abc/xx where “xx” represents a number 
that tells it what to act upon.


I have started developing a new servlet which handles POST requests to 
the URL: https:///plugins/abc/xx.  In some cases (based on 
a values in the request body), the servlet will process things itself 
and generate its own response.   For certain cases it just needs to 
forward the request on to corresponding “backend” URL and then pass the 
response back.


I assumed that .forward(request, response) on a RequestDispatcher would 
be what I needed to use.  I have tried every combination of 
getServletContext() and getRequestDispatcher() I can think of or have 
found on the internet but it always fails with an HTTP error 404.  This 
is because the URL that it is being forwarded to always has a rogue 
“plugins” in it, i.e. https:///plugins/backend/rest/abc/xx.


I suspect the solution is simple but I am new to Tomcat and developing 
servlets and probably missing something obvious.  Any guidance would be 
much appreciated.


-Andy.

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

Re: Apache Tomcat request smuggling in 9.0.68?

[Mark Thomas]

On 05/07/2023 20:15, James Boggs wrote:

Hello,

I was sent this information, I hope this meets your expectations.


Thanks. It does.

The request headers do not contain an invalid Content-Length header so 
CVE-2022-42252 is not applicable to this situation.


The requests are valid HTTP requests (unless I missed something) so 
something would have to be severely broken for there to be request 
smuggling.


I have tested the request on a clean build of Tomcat 9.0.73 and Tomcat 
correctly redirects to https://rplans.army.mil/ for both requests.


You may want to look at the proxy rather than Tomcat.

To figure out what is going on you are going to need to look at the 
network traces for both the client<->proxy link and the proxy<->tomcat link.


Mark




-----
Request 1
GET / HTTP/1.1
Host: rplans.army.mil
Accept-Encoding: gzip, deflate
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/113.0.5672.93 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="113", "Chromium";v="113"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 61
Cookie: ai_user=zah6PVBAYp+ILUaHTr/CZn|2023-06-27T16:40:26.575Z; 
ai_session=4yP6RgcdmaqsiFQJVdym6I|1687884026682|1687884026682; 
_ga=GA1.2.1707569457.1687904638; _gid=GA1.2.1713949416.1687904638; _gat=1

GET /j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp HTTP/1.1
X: kyhzap9frc
Response 1
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: https://rplans.army.mil/
Date: Wed, 28 Jun 2023 01:37:07 GMT
Connection: Keep-Alive
Request 2
GET / HTTP/1.1
Host: rplans.army.mil
Accept-Encoding: gzip, deflate
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/113.0.5672.93 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="113", "Chromium";v="113"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 61
Cookie: ai_user=zah6PVBAYp+ILUaHTr/CZn|2023-06-27T16:40:26.575Z; 
ai_session=4yP6RgcdmaqsiFQJVdym6I|1687884026682|1687884026682; 
_ga=GA1.2.1707569457.1687904638; _gid=GA1.2.1713949416.1687904638; _gat=1

GET /j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp HTTP/1.1
X: kyhzap9frc
Response 2
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: https://rplans.army.mil/j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp
Date: Wed, 28 Jun 2023 01:37:09 GMT
Connection: Keep-Alive
-

V/r,


James Boggs | Senior DBA/SA | Mobile: 571-337-0535
“Trust, Integrity, Loyalty to Our Customers, Employees and Partner”
VA Verified (SDVOSB) | SBA Certified 8(a) | SB | SDB | MBE/DBE (MD) | SWaM (VA)
ISO 9001:2015|ISO/IEC 2-1:2018|ISO/IEC 27001:2013|
CMMI-DEV Level 3 Appraised |
GSA Schedule Holder: IT-70#:GS35F237AA
GSA 8(a) STARS III#: 47QTCB21D0030
CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
CIO-SP3 Contract#: HHSN316201800054W(HUBZone)
Seaport-NXG Contract#: N00178-19-D-8420
eFAST Contract#: DTFAWA-13-A-00074


-Original Message-
From: Mark Thomas 
Sent: Wednesday, July 5, 2023 12:59 PM
To: users@tomcat.apache.org
Subject: Re: Apache Tomcat request smuggling in 9.0.68?

Without knowing which vulnerability is being tested for and how the 
vulnerability is being tested for I don't think anyone here will be able to 
help.

A (cleartext) tcpdump of the associated request(s) and response(s) would also 
be helpful.

Mark


On 05/07/2023 17:51, James Boggs wrote:

Hi,

We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s
which is has a Request Smuggling vulnerability being reported in a
BURP scan.

Here Tomcat documentation reports Request Smuggling has been fixed in
9.0.68, so we don’t understand why it would still be reported using 9.0.73.

Any insights on this?

We have been told the proxy in use only supports HTTP1, so HTTP2 is
not an option.

V/r,

James Boggs | Senior DBA/SA | Mobile: 571-337-0535 /“Trust, Integrity,
Loyalty to Our Customers, Employees and Partner”/ */VA Verified
(SDVOSB)/* | */SBA Certified 8(a)/* | */SB/* | */SDB/* | */MBE/DBE
(MD)/* | */SWaM (VA)/*
I*SO* 9001:2015|*ISO/IEC* 2-1:2018|*ISO/IEC* 27001:2013|
*CMMI-DEV* Level 3 Appraised |

GSA Sc

RE: Apache Tomcat request smuggling in 9.0.68?

[James Boggs]

Hello,

I was sent this information, I hope this meets your expectations.

-
Request 1
GET / HTTP/1.1
Host: rplans.army.mil
Accept-Encoding: gzip, deflate
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/113.0.5672.93 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="113", "Chromium";v="113"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 61
Cookie: ai_user=zah6PVBAYp+ILUaHTr/CZn|2023-06-27T16:40:26.575Z; 
ai_session=4yP6RgcdmaqsiFQJVdym6I|1687884026682|1687884026682; 
_ga=GA1.2.1707569457.1687904638; _gid=GA1.2.1713949416.1687904638; _gat=1

GET /j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp HTTP/1.1
X: kyhzap9frc
Response 1
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: https://rplans.army.mil/
Date: Wed, 28 Jun 2023 01:37:07 GMT
Connection: Keep-Alive
Request 2
GET / HTTP/1.1
Host: rplans.army.mil
Accept-Encoding: gzip, deflate
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/113.0.5672.93 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="113", "Chromium";v="113"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 61
Cookie: ai_user=zah6PVBAYp+ILUaHTr/CZn|2023-06-27T16:40:26.575Z; 
ai_session=4yP6RgcdmaqsiFQJVdym6I|1687884026682|1687884026682; 
_ga=GA1.2.1707569457.1687904638; _gid=GA1.2.1713949416.1687904638; _gat=1

GET /j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp HTTP/1.1
X: kyhzap9frc
Response 2
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: https://rplans.army.mil/j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp
Date: Wed, 28 Jun 2023 01:37:09 GMT
Connection: Keep-Alive
-

V/r,


James Boggs | Senior DBA/SA | Mobile: 571-337-0535
“Trust, Integrity, Loyalty to Our Customers, Employees and Partner”
VA Verified (SDVOSB) | SBA Certified 8(a) | SB | SDB | MBE/DBE (MD) | SWaM (VA)
ISO 9001:2015|ISO/IEC 2-1:2018|ISO/IEC 27001:2013|
CMMI-DEV Level 3 Appraised |
GSA Schedule Holder: IT-70#:GS35F237AA
GSA 8(a) STARS III#: 47QTCB21D0030
CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
CIO-SP3 Contract#: HHSN316201800054W(HUBZone) 
Seaport-NXG Contract#: N00178-19-D-8420
eFAST Contract#: DTFAWA-13-A-00074


-Original Message-
From: Mark Thomas  
Sent: Wednesday, July 5, 2023 12:59 PM
To: users@tomcat.apache.org
Subject: Re: Apache Tomcat request smuggling in 9.0.68?

Without knowing which vulnerability is being tested for and how the 
vulnerability is being tested for I don't think anyone here will be able to 
help.

A (cleartext) tcpdump of the associated request(s) and response(s) would also 
be helpful.

Mark


On 05/07/2023 17:51, James Boggs wrote:
> Hi,
> 
> We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s 
> which is has a Request Smuggling vulnerability being reported in a 
> BURP scan.
> 
> Here Tomcat documentation reports Request Smuggling has been fixed in 
> 9.0.68, so we don’t understand why it would still be reported using 9.0.73.
> 
> Any insights on this?
> 
> We have been told the proxy in use only supports HTTP1, so HTTP2 is 
> not an option.
> 
> V/r,
> 
> James Boggs | Senior DBA/SA | Mobile: 571-337-0535 /“Trust, Integrity, 
> Loyalty to Our Customers, Employees and Partner”/ */VA Verified 
> (SDVOSB)/* | */SBA Certified 8(a)/* | */SB/* | */SDB/* | */MBE/DBE 
> (MD)/* | */SWaM (VA)/*
> I*SO* 9001:2015|*ISO/IEC* 2-1:2018|*ISO/IEC* 27001:2013|
> *CMMI-DEV* Level 3 Appraised |
> 
> GSA Schedule Holder: IT-70#:GS35F237AA
> 
> GSA 8(a) STARS III#: 47QTCB21D0030
> 
> CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
> 
> CIO-SP3 Contract#: HHSN316201800054W(HUBZone)
> 
> Seaport-NXG Contract#: N00178-19-D-8420
> 
> eFAST Contract#: DTFAWA-13-A-00074
> 
> Fax: 410-814-7539 _|jbo...@rightdirectiontech.com 
> _
> 
> RightDirection Technology Solutions, LLC | 300 E. Lombard St Suite 840 
> | Baltimore, MD 21202|
> 
> www.rightdirectiontech.com <http://www.rightdirectiontech.com/>
> 
> Please Go Green! Please 

Re: Apache Tomcat request smuggling in 9.0.68?

[Mark Thomas]

Without knowing which vulnerability is being tested for and how the 
vulnerability is being tested for I don't think anyone here will be able 
to help.


A (cleartext) tcpdump of the associated request(s) and response(s) would 
also be helpful.


Mark


On 05/07/2023 17:51, James Boggs wrote:

Hi,

We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s 
which is has a Request Smuggling vulnerability being reported in a BURP 
scan.


Here Tomcat documentation reports Request Smuggling has been fixed in 
9.0.68, so we don’t understand why it would still be reported using 9.0.73.


Any insights on this?

We have been told the proxy in use only supports HTTP1, so HTTP2 is not 
an option.


V/r,

James Boggs | Senior DBA/SA | Mobile: 571-337-0535
/“Trust, Integrity, Loyalty to Our Customers, Employees and Partner”/
*/VA Verified (SDVOSB)/* | */SBA Certified 8(a)/* | */SB/* | */SDB/* | 
*/MBE/DBE (MD)/* | */SWaM (VA)/*

I*SO* 9001:2015|*ISO/IEC* 2-1:2018|*ISO/IEC* 27001:2013|
*CMMI-DEV* Level 3 Appraised |

GSA Schedule Holder: IT-70#:GS35F237AA

GSA 8(a) STARS III#: 47QTCB21D0030

CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)

CIO-SP3 Contract#: HHSN316201800054W(HUBZone)

Seaport-NXG Contract#: N00178-19-D-8420

eFAST Contract#: DTFAWA-13-A-00074

Fax: 410-814-7539 _|jbo...@rightdirectiontech.com 
_


RightDirection Technology Solutions, LLC | 300 E. Lombard St Suite 840 | 
Baltimore, MD 21202|


www.rightdirectiontech.com <http://www.rightdirectiontech.com/>

Please Go Green! Please do not print this e-mail unless necessary.


Notice of Confidentiality: This e-mail and any attachments thereto, are 
intended only for use by the addressee(s) named herein and may contain 
legally privileged and/or confidential information. If you are not the 
intended recipient of this e-mail (or the person responsible for 
delivering this document to the intended recipient), you are hereby 
notified that any dissemination, distribution, printing or copying of 
this e-mail, and any attachment thereto, is strictly prohibited. If you 
have received this e-mail in error, please respond to the individual 
sending the message, and permanently delete the original and any copy of 
any e-mail and printout thereof.




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

Apache Tomcat request smuggling in 9.0.68?

[James Boggs]

Hi,

We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s which is 
has a Request Smuggling vulnerability being reported in a BURP scan.
Here Tomcat documentation reports Request Smuggling has been fixed in 9.0.68, 
so we don't understand why it would still be reported using 9.0.73.
Any insights on this?
We have been told the proxy in use only supports HTTP1, so HTTP2 is not an 
option.

V/r,

James Boggs | Senior DBA/SA | Mobile: 571-337-0535
"Trust, Integrity, Loyalty to Our Customers, Employees and Partner"
VA Verified (SDVOSB) | SBA Certified 8(a) | SB | SDB | MBE/DBE (MD) | SWaM (VA)
ISO 9001:2015|ISO/IEC 2-1:2018|ISO/IEC 27001:2013|
CMMI-DEV Level 3 Appraised |
GSA Schedule Holder: IT-70#:GS35F237AA
GSA 8(a) STARS III#: 47QTCB21D0030
CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
CIO-SP3 Contract#: HHSN316201800054W(HUBZone)
Seaport-NXG Contract#: N00178-19-D-8420
eFAST Contract#: DTFAWA-13-A-00074
[cid:image001.png@01D9AF3F.5DD6D0E0]
[cid:image002.png@01D9AF3F.5DD6D0E0]
Fax: 410-814-7539 
|jbo...@rightdirectiontech.com
RightDirection Technology Solutions, LLC | 300 E. Lombard St Suite 840 | 
Baltimore, MD 21202 |
www.rightdirectiontech.com<http://www.rightdirectiontech.com/>

Please Go Green! Please do not print this e-mail unless necessary.

Notice of Confidentiality: This e-mail and any attachments thereto, are 
intended only for use by the addressee(s) named herein and may contain legally 
privileged and/or confidential information. If you are not the intended 
recipient of this e-mail (or the person responsible for delivering this 
document to the intended recipient), you are hereby notified that any 
dissemination, distribution, printing or copying of this e-mail, and any 
attachment thereto, is strictly prohibited. If you have received this e-mail in 
error, please respond to the individual sending the message, and permanently 
delete the original and any copy of any e-mail and printout thereof.

RE: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to 8.5.89.

[jonmcalexander]

Awesome! Thanks Mark!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Mark Thomas 
> Sent: Saturday, June 3, 2023 8:33 AM
> To: users@tomcat.apache.org
> Subject: Re: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to
> 8.5.89.
> 
> On 02/06/2023 21:00, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Good afternoon,
> >
> > Have a team that just upgraded to 8.5.89 from 8.5.72 and started getting
> these messages in the logs:
> >
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - EPMSend = SOAP
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPort = 8443
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPath =
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPURL =
> >  ...
> > [2023/06/01][17:31:01.157] : [EPMSEND] - EPMSend - Established Socket
> > to send EPM messages [2023/06/01][17:31:01.227] : [EPMSEND] - EPMSend
> > - Error not 200 OK. HTTP error: "HTTP/1.1 400 Bad Request"  See reply
> > txt message in XMLPathOut directory for
> > g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-
> 20230601080
> > 446029.xml [2023/06/01][17:31:01.380] : [INIT] - EPMSend (init) -
> > EPMSend = SOAP
> >
> > Is anyone aware of what could potentially be the cause?
> 
> Generally, Tomcat gets stricter enforcing the HTTP specification
> requirements over time. This is for a combination of reasons:
> - bugs get reported that invalid requests are not rejected
> - the HTTP specs are getting stricter over time
> - security issues get identified with handling of invalid requests
> 
> If you look in the Coyote section of the change log, you should find all of 
> the
> changes to HTTP request validation listed. A quick scan for
> 8.5.72 to 8.5.89 found:
> - stricter validation of line termination
> - reject requests with malformed content-length headers
> - allowHostHeaderMismatch now defaults to false
> - rejectIllegalHeader now defaults to true
> 
> I suspect it will be one of the last two.
> 
> If you set the system property
> org.apache.juli.logging.UserDataHelper.CONFIG to INFO_ALL you'll get an
> INFO level log message for every request that is rejected.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to 8.5.89.

[Mark Thomas]

On 02/06/2023 21:00, jonmcalexan...@wellsfargo.com.INVALID wrote:

Good afternoon,

Have a team that just upgraded to 8.5.89 from 8.5.72 and started getting these 
messages in the logs:

[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - EPMSend = SOAP
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPort = 8443
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPath =
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPURL = 
...
[2023/06/01][17:31:01.157] : [EPMSEND] - EPMSend - Established Socket to send 
EPM messages
[2023/06/01][17:31:01.227] : [EPMSEND] - EPMSend - Error not 200 OK. HTTP error: 
"HTTP/1.1 400 Bad Request"  See reply txt message in XMLPathOut directory for 
g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-20230601080446029.xml
[2023/06/01][17:31:01.380] : [INIT] - EPMSend (init) - EPMSend = SOAP

Is anyone aware of what could potentially be the cause?


Generally, Tomcat gets stricter enforcing the HTTP specification 
requirements over time. This is for a combination of reasons:

- bugs get reported that invalid requests are not rejected
- the HTTP specs are getting stricter over time
- security issues get identified with handling of invalid requests

If you look in the Coyote section of the change log, you should find all 
of the changes to HTTP request validation listed. A quick scan for 
8.5.72 to 8.5.89 found:

- stricter validation of line termination
- reject requests with malformed content-length headers
- allowHostHeaderMismatch now defaults to false
- rejectIllegalHeader now defaults to true

I suspect it will be one of the last two.

If you set the system property 
org.apache.juli.logging.UserDataHelper.CONFIG to INFO_ALL you'll get an 
INFO level log message for every request that is rejected.


Mark

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

RE: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to 8.5.89.

[jonmcalexander]

Thanks Sergent. Good catch, I'll inquire.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Rob Sargent 
> Sent: Friday, June 2, 2023 3:46 PM
> To: users@tomcat.apache.org
> Subject: Re: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to
> 8.5.89.
> 
> 
> 
> On 6/2/23 14:00, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Good afternoon,
> >
> > Have a team that just upgraded to 8.5.89 from 8.5.72 and started getting
> these messages in the logs:
> >
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - EPMSend = SOAP
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPort = 8443
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPath =
> > [2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPURL =
> >  ...
> > [2023/06/01][17:31:01.157] : [EPMSEND] - EPMSend - Established Socket
> > to send EPM messages [2023/06/01][17:31:01.227] : [EPMSEND] - EPMSend
> > - Error not 200 OK. HTTP error: "HTTP/1.1 400 Bad Request"  See reply
> > txt message in XMLPathOut directory for
> > g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-
> 20230601080
> > 446029.xml [2023/06/01][17:31:01.380] : [INIT] - EPMSend (init) -
> > EPMSend = SOAP
> >
> > Is anyone aware of what could potentially be the cause?
> >
> > Thank you.
> 
> Is there nothing useful in either
> 
> XMLPathOut
> 
> or
> 
> g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-
> 20230601080446029.xml
> 
> 
> 
> -
> 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: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to 8.5.89.

[Rob Sargent]

On 6/2/23 14:00, jonmcalexan...@wellsfargo.com.INVALID wrote:

Good afternoon,

Have a team that just upgraded to 8.5.89 from 8.5.72 and started getting these 
messages in the logs:

[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - EPMSend = SOAP
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPort = 8443
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPath =
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPURL = 
...
[2023/06/01][17:31:01.157] : [EPMSEND] - EPMSend - Established Socket to send 
EPM messages
[2023/06/01][17:31:01.227] : [EPMSEND] - EPMSend - Error not 200 OK. HTTP error: 
"HTTP/1.1 400 Bad Request"  See reply txt message in XMLPathOut directory for 
g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-20230601080446029.xml
[2023/06/01][17:31:01.380] : [INIT] - EPMSend (init) - EPMSend = SOAP

Is anyone aware of what could potentially be the cause?

Thank you.


Is there nothing useful in either

XMLPathOut

or

g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-20230601080446029.xml



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

SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to 8.5.89.

[jonmcalexander]

Good afternoon,

Have a team that just upgraded to 8.5.89 from 8.5.72 and started getting these 
messages in the logs:

[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - EPMSend = SOAP
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPort = 8443
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPPath =
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPURL = 
...
[2023/06/01][17:31:01.157] : [EPMSEND] - EPMSend - Established Socket to send 
EPM messages
[2023/06/01][17:31:01.227] : [EPMSEND] - EPMSend - Error not 200 OK. HTTP 
error: "HTTP/1.1 400 Bad Request"  See reply txt message in XMLPathOut 
directory for 
g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-20230601080446029.xml
[2023/06/01][17:31:01.380] : [INIT] - EPMSend (init) - EPMSend = SOAP

Is anyone aware of what could potentially be the cause?

Thank you.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: Get actual protocol from request

[Christopher Schultz]

Mark,

On 6/2/23 10:57, Mark Thomas wrote:

On 02/06/2023 15:31, Christopher Schultz wrote:

All,

Is it possible to get the /actual/ protocol used for communication 
with a tomcat server? I'm using AJP/13 and request.getProtocol is 
returning "HTTP/1.1" which is not 100% surprising.


I'm wondering if the request has anything in it which specifies the 
"actual" protocol which was used.


HttpServletRequest.getServletConnection().getProtocol()

(requires Servlet 6.0 / Tomcat 10.1.x onwards)


Hey, that's great.

Would it be possible to add something like this in pre-Tomcat 10 in a 
(possibly hidden) request attribute?


I have a related question about mod_proxy which I'm also using for 
testing to "merge" Via headers. I can get "Header merge" to work with a 
Via header, but the ProxyVia directive seems to do absolutely nothing.


I can't even get "ProxyVia Block" to delete Via headers set by a 
back-end Tomcat server. Any suggestions? My ProxyVia directive is in the 
 I'm using for this host.


-chris

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

Re: Get actual protocol from request

[Mark Thomas]

On 02/06/2023 15:31, Christopher Schultz wrote:

All,

Is it possible to get the /actual/ protocol used for communication with 
a tomcat server? I'm using AJP/13 and request.getProtocol is returning 
"HTTP/1.1" which is not 100% surprising.


I'm wondering if the request has anything in it which specifies the 
"actual" protocol which was used.


HttpServletRequest.getServletConnection().getProtocol()

(requires Servlet 6.0 / Tomcat 10.1.x onwards)

Mark

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

Get actual protocol from request

[Christopher Schultz]

All,

Is it possible to get the /actual/ protocol used for communication with 
a tomcat server? I'm using AJP/13 and request.getProtocol is returning 
"HTTP/1.1" which is not 100% surprising.


I'm wondering if the request has anything in it which specifies the 
"actual" protocol which was used.


-chris

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

Re: Apache httpd as reverse proxy in front of Tomcat 10.1 - Different Connectors vs. HTTP request smuggling

[Christopher Schultz]

Reg,

On 5/5/23 23:48, r.barc...@habmalnefrage.de wrote:

I have some questions about HTTP request smuggling in the context of Tomcat 
with Apache httpd as its reverse proxy.

First of all, a few words about my current setup: At the moment I have a few 
applications that are deployed this way:
I use Tomcat 10.1 as my backend server. It only activates its AJP connector (no 
HTTP(S)).
In front, there is an Apache httpd 2.4 with mod_jk as a reverse proxy for my 
Tomcat.
Apache httpd does SSL termination and HSTS redirecting and rejects some trash 
traffic before it could reach Tomcat.
mod_jk is used with the more or less default configuration, which includes 
reuse of backend AJP connections.

Question 1:
Assuming I use the up-to-date package versions in Debian 11, is this setup 
prone to HTTP request smuggling?
If that might be the case, what steps should be taken against?
Do users have to enable "JkOptions +DisableReuse" to prevent HTTP request 
smuggling?
Or is the AJP protocol somewhat "immune" against the confusion about the 
request headers Content-Length, Transfer-Encoding etc.?
I haven't found much about the topic "mod_jk + request smuggling".


mod_jk is a little less prone to mismatches between httpd and Tomcat 
interpretation of HTTP messages, which is the root of pretty much all 
request-smuggling issues. The reason is that mod_jk was built 
specifically for proxying to Tomcat and its URL-handling rules match the 
Servlet API. Compare that to mod_proxy which was designed to proxy any 
number of protocols and even when used with HTTP can be configured to 
handle URLs in several different ways.


As long as httpd doesn't get confused about what is a header, mod_jk 
will not make anything worse.


You /can/ +DisableReuse but that will kill your performance. If 
performance is not a consideration (e.g. low volume, etc.) then it's a 
great way to prevent one client from bashing requests (or, more likely, 
responses) intended for another client.



Question 2:
In a new application I will have to use websockets.
It seems websockets do not work over AJP / mod_jk.


This is correct: Websockets essentially cannot be proxied over mod_jk.


So I will have to enable Tomcat's HTTP connector and use mod_proxy_wstunnel in 
the Apache httpd reverse proxy.
Therefore, the setup probably won't use AJP / mod_jk at all, but 
mod_proxy_http, connecting to Tomcat's HTTP connector.
What steps does one have to take against HTTP request smuggling in this case?
Do we have to use "disablereuse=on keepalive=off" on the Apache httpd side?


keepalive=off will kill your performance even worse than disablereuse=on 
because even a single client cannot make multiple requests across a 
single connection.


I would read all of the various security-related configuration options 
for mod_proxy and mod_proxy_wstunnel (if there are any). Mostly, the 
pain points will be in URL handling and not really the headers, since 
httpd already does a really good job of rejecting requests whose headers 
are mangled.


You might consider using something like mod_security which looks at a 
lot of semantic stuff in requests and rejects all kinds of funny-looking 
stuff that may be spec-compliant but still ... shady-looking.



What are your experiences / best practices?

Question 3:
Do the Apache httpd and Apache Tomcat projects coordinate their header 
processing algorithms, header normalization efforts etc. to combat HTTP request 
smuggling?


To the extent possible without lock-stepping our two communities. There 
is some overlap between the committers on the projects, but mostly we 
are distinct groups. But instead of trying to coordinate our efforts, 
the Tomcat team takes the stance that the RFCs are the Source of Truth 
and should be followed, and any product (including httpd) that deviates 
from them is out-of-spec and ought to be changed.


I suspect that the httpd team takes that same stance, but I haven't 
asked for an official statement. Also, httpd has a 30-year history at 
this point and some "old behavior" needs to be preserved for 
compatibility reasons. But usually anything that violates the spec must 
be changed from the default configuration.



So is the combination of "Apache httpd + (mod_jk | mod_proxy_*) + Apache Tomcat" 
considered "HTTP request smuggling"-safe in general?


I should hope so, as a significant portion of the users of this mailing 
list are using that exact configuration. ;)


-chris

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

Apache httpd as reverse proxy in front of Tomcat 10.1 - Different Connectors vs. HTTP request smuggling

[r . barclay]

Hello,

I have some questions about HTTP request smuggling in the context of Tomcat 
with Apache httpd as its reverse proxy.

First of all, a few words about my current setup: At the moment I have a few 
applications that are deployed this way:
I use Tomcat 10.1 as my backend server. It only activates its AJP connector (no 
HTTP(S)).
In front, there is an Apache httpd 2.4 with mod_jk as a reverse proxy for my 
Tomcat.
Apache httpd does SSL termination and HSTS redirecting and rejects some trash 
traffic before it could reach Tomcat.
mod_jk is used with the more or less default configuration, which includes 
reuse of backend AJP connections.

Question 1:
Assuming I use the up-to-date package versions in Debian 11, is this setup 
prone to HTTP request smuggling?
If that might be the case, what steps should be taken against?
Do users have to enable "JkOptions +DisableReuse" to prevent HTTP request 
smuggling?
Or is the AJP protocol somewhat "immune" against the confusion about the 
request headers Content-Length, Transfer-Encoding etc.?
I haven't found much about the topic "mod_jk + request smuggling".

Question 2:
In a new application I will have to use websockets.
It seems websockets do not work over AJP / mod_jk.
So I will have to enable Tomcat's HTTP connector and use mod_proxy_wstunnel in 
the Apache httpd reverse proxy.
Therefore, the setup probably won't use AJP / mod_jk at all, but 
mod_proxy_http, connecting to Tomcat's HTTP connector.
What steps does one have to take against HTTP request smuggling in this case?
Do we have to use "disablereuse=on keepalive=off" on the Apache httpd side?

What are your experiences / best practices?

Question 3:
Do the Apache httpd and Apache Tomcat projects coordinate their header 
processing algorithms, header normalization efforts etc. to combat HTTP request 
smuggling?
So is the combination of "Apache httpd + (mod_jk | mod_proxy_*) + Apache 
Tomcat" considered "HTTP request smuggling"-safe in general?

Thanks a lot for any advice!

Reg





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

RE: HTTP2: How to check if the client aborted a request

[EXT-Denton, Sam T]

I am also interested in this.  In my case, we added an "Abort Request" link to 
the placeholder page that is displayed while the calculation is on-going, but 
naturally nobody ever clicks on it.  :O  I am solidly In favor of anything that 
fixes this.

Sam Denton (he/him)
Advisor, Solutions Architect 
Mobile (314) 827-4017
24x7 SBS Suppot (405) 312-9936

Advanced Leave Notice: NONE

-Original Message-
From: Robin Stevens  
Sent: Tuesday, March 14, 2023 4:01 AM
To: users@tomcat.apache.org
Subject: HTTP2: How to check if the client aborted a request

Use case / problem:

The frontend is doing requests that trigger heavy calculations in the backend. 
Often these requests get cancelled by the frontend before the backend has 
finished doing the calculations.

The cancellation of the requests is done by using an AbortController 
(https://developer.mozilla.org/en-US/docs/Web/API/AbortController) to abort the 
fetch (similar to this example 
https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort#examples).

When aborting a fetch that happens over HTTP2, an RST_FRAME is send to the 
server.

I'm trying to figure out how to detect in the backend that such an RST_FRAME 
has been received, and stop doing my calculation.

This is done in a Spring Boot Application using the embedded Tomcat webserver, 
but I would already be glad if I can get a pointer on how to get this 
information in Tomcat through public apis. 
I'm hopeful I can figure out the integration with Spring myself.


Investigation:

What I already found is that the RST_FRAME is received in the backend, at which 
point the state in the org.apache.coyote.http2.StreamStateMachine switches to 
CLOSED_RST_TX. 
After that state switch, the 
org.apache.coyote.http2.StreamStateMachine#canWrite method returns false which 
I think is the information I need.
After all, if the result of my calculation cannot be written to the stream, 
there is no point in doing it.

The problem is that this information is hidden behind a bunch of package 
visible/protected classes and methods so I cannot access it without relying on 
reflection and implementation details.
And I couldn't find anything in the source code that exposes this information 
publicly. 
So I'm not even sure I'm on the right track here.

Does anybody has a pointer on how to obtain this info through official APIs, or 
to some documentation related to this that I might have missed ?

Thanks,

Robin


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

Re: HTTP2: How to check if the client aborted a request

[Mark Thomas]

On 14/03/2023 09:00, Robin Stevens wrote:




Does anybody has a pointer on how to obtain this info through official APIs, or 
to some documentation related to this that I might have missed ?


The short answer is that there is no way do this via the Servlet API 
that doesn't involved trying to do I/O and then reacting to any error 
that is received.


This is an open issue for the Servlet spec. There have been a few 
discussions and proposals but no consensus so far. Servlet issue #433 is 
probably the best place to start reading up on what has been discussed 
so far:

https://github.com/jakartaee/servlet/issues/433

I currently think it is more likely than not that something to help with 
this will be introduced in the next iteration of the Servlet spec.


Mark

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

HTTP2: How to check if the client aborted a request

[Robin Stevens]

Version: Tomcat 9.0.35 (embedded in Spring Boot 2.3.0.RELEASE)

Use case / problem:

The frontend is doing requests that trigger heavy calculations in the backend. 
Often these requests get cancelled by the frontend before the backend has 
finished doing the calculations.

The cancellation of the requests is done by using an AbortController 
(https://developer.mozilla.org/en-US/docs/Web/API/AbortController) to abort the 
fetch (similar to this example 
https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort#examples).

When aborting a fetch that happens over HTTP2, an RST_FRAME is send to the 
server.

I'm trying to figure out how to detect in the backend that such an RST_FRAME 
has been received, and stop doing my calculation.

This is done in a Spring Boot Application using the embedded Tomcat webserver, 
but I would already be glad if I can get a pointer on how to get this 
information in Tomcat through public apis. 
I'm hopeful I can figure out the integration with Spring myself.


Investigation:

What I already found is that the RST_FRAME is received in the backend, at which 
point the state in the org.apache.coyote.http2.StreamStateMachine switches to 
CLOSED_RST_TX. 
After that state switch, the 
org.apache.coyote.http2.StreamStateMachine#canWrite method returns false which 
I think is the information I need.
After all, if the result of my calculation cannot be written to the stream, 
there is no point in doing it.

The problem is that this information is hidden behind a bunch of package 
visible/protected classes and methods so I cannot access it without relying on 
reflection and implementation details.
And I couldn't find anything in the source code that exposes this information 
publicly. 
So I'm not even sure I'm on the right track here.

Does anybody has a pointer on how to obtain this info through official APIs, or 
to some documentation related to this that I might have missed ?

Thanks,

Robin

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

Re: HTTP Error 414. The request URL is too long.

[Christopher Schultz]

Stefan,

On 3/10/23 02:27, Stefan Mayr wrote:

Am 10.03.2023 um 07:58 schrieb Thomas Hoffmann (Speed4Trade GmbH):
You should keep an eye on this log entry: this is a GET request as your 
SAMPLE POST already indicated. Maybe you can check back with your 
developers that they change their code to really use the POST method


+1

Large payloads should use POST.

Using GET requires the whole request to be in the URL and most web 
servers have pretty low limits (e.g. Tomcat's is 8192 bytes) on how much 
you can put into the URL. headers, etc. because of logging and other 
kinds of header-processing.


-chris


On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
wrote:


On 3/9/2023 5:47 PM, Jason Tan wrote:

Hi Seth,
One of my customer had the same error. We also tried increasing

maxHttpHeaderSize as suggested on Google.  It worked for him for a
while, but he encountered the same error again later on.

Our developers got involved and later discovered that our app was
trying

to display all his favourites and the customer somehow managed to
accumulate a huge list of favourites. So, a hotfix was created to
limit the size of the favourites that get displayed on to the browser.

I hope that helps you sort it out with the application to find what
huge

data is being push onto the url and limit it.

-Original Message-
From: Mark Thomas 
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The
request URL is too long".

I have tried adding a bunch of parameters to my server.xml file but
none of them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running
Tomcat
8.5 but his solution (maxhttpheadersize) did not work for me.  Did
something change between 8.5 and 9.0.48 that might affect things?
Is something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status
code

is originating, it isn't Tomcat. It must be in the application or in a
component before Tomcat.


Mark




SAMPLE POST (the one that fails is FAR larger than this)



http://servername/gatewayAdminTest/GatewayClient?OutputType=1

Typ
e=1=

 
    
   LSF
   01092390
   02
   
   test_promo_freeProduct
   DROP
   
   
   01092391
   WEB001232
   O
    
    
   
  39012621
  1.0
  BAG
   
    
 
  

=xxx
--



Are you sure that's POST request? I'd suggest looking at the Tomcat
access log if you can get a request that far.

-Terence Bandoian


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




--


[image: photograph]

*Seth Mayers* Chief Technology Officer
*p:*
*e:* seth.may...@petfoodexperts.com
www.petfoodexperts.com
[image: facebook icon] <https://www.facebook.com/PFExperts>  [image:
instagram icon] <https://www.instagram.com/petfoodexperts>  [image:
linkedin icon] <https://www.linkedin.com/company/pet-food-experts>  
[image:
twitter icon] <https://twitter.com/petfoodexperts>  [image: youtube 
icon]

<https://www.youtube.com/c/PetFoodExperts>


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



- Stefan

-
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: HTTP Error 414. The request URL is too long.

[Stefan Mayr]

Am 10.03.2023 um 08:27 schrieb Stefan Mayr:

Am 10.03.2023 um 07:58 schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello,


-Ursprüngliche Nachricht-
Von: Seth Mayers 
Gesendet: Freitag, 10. März 2023 01:14
An: Tomcat Users List 
Betreff: Re: HTTP Error 414. The request URL is too long.

Thanks.  Sadly I know how the data is being pushed.  It is poorly 
architected.
Developers are working to re-write it but I am looking for a short 
term solution
until they can complete that project.  I found where windows is 
logging the
error.  I am just not sure which process writes to this log or how to 
tell it to
ignore the error.  I thought I had it with a registry entry but it 
didn't fix the

problem.

C:\Windows\System32\LogFiles\HTTPERR


This looks like a windows system running IIS.
IIS also has some max-settings for requests.
Maybe you can check the IIS advanced settings for this site.


This could be an IIS with mod_jk or an ARR reverse proxy. When this is 
specific to GET requests increasing MaxFieldLength for http.sys should help


And increase MaxRequestBytes. I forgot that because we already increased 
that for our Kerberos tokens in request headers.


Reference: 
https://learn.microsoft.com/en-US/troubleshoot/developer/webapps/iis/iisadmin-service-inetinfo/httpsys-registry-windows


It might be necessary to tune other settings but those should have 
different status codes.




2023-03-09 23:55:40 192.168.103.30 56355 192.168.0.27 80 - GET - - 414 -
URL_Length -


You should keep an eye on this log entry: this is a GET request as your 
SAMPLE POST already indicated. Maybe you can check back with your 
developers that they change their code to really use the POST method



On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
wrote:


On 3/9/2023 5:47 PM, Jason Tan wrote:

Hi Seth,
One of my customer had the same error. We also tried increasing

maxHttpHeaderSize as suggested on Google.  It worked for him for a
while, but he encountered the same error again later on.

Our developers got involved and later discovered that our app was
trying

to display all his favourites and the customer somehow managed to
accumulate a huge list of favourites. So, a hotfix was created to
limit the size of the favourites that get displayed on to the browser.

I hope that helps you sort it out with the application to find what
huge

data is being push onto the url and limit it.

-Original Message-
From: Mark Thomas 
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The
request URL is too long".

I have tried adding a bunch of parameters to my server.xml file but
none of them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running
Tomcat
8.5 but his solution (maxhttpheadersize) did not work for me.  Did
something change between 8.5 and 9.0.48 that might affect things?
Is something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status
code

is originating, it isn't Tomcat. It must be in the application or in a
component before Tomcat.


Mark




SAMPLE POST (the one that fails is FAR larger than this)



http://servername/gatewayAdminTest/GatewayClient?OutputType=1

Typ
e=1=

 
    
   LSF
   01092390
   02
   
   test_promo_freeProduct
   DROP
   
   
   01092391
   WEB001232
   O
    
    
   
  39012621
  1.0
  BAG
   
    
 
  

=xxx
--



Are you sure that's POST request? I'd suggest looking at the Tomcat
access log if you can get a request that far.

-Terence Bandoian


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




--


[image: photograph]

*Seth Mayers* Chief Technology Officer
*p:*
*e:* seth.may...@petfoodexperts.com
www.petfoodexperts.com
[image: facebook icon] <https://www.facebook.com/PFExperts>  [image:
instagram icon] <https://www.instagram.com/petfoodexperts>  [image:
linkedin icon] <https://www.linkedin.com/company/pet-food-experts>  
[image:
twitter icon] <https://twitter.com/petfoodexperts>  [image: youtube 
icon]

<https://www.youtube.com/c/PetFoodExperts>


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

Re: HTTP Error 414. The request URL is too long.

[Stefan Mayr]

Am 10.03.2023 um 07:58 schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello,


-Ursprüngliche Nachricht-
Von: Seth Mayers 
Gesendet: Freitag, 10. März 2023 01:14
An: Tomcat Users List 
Betreff: Re: HTTP Error 414. The request URL is too long.

Thanks.  Sadly I know how the data is being pushed.  It is poorly architected.
Developers are working to re-write it but I am looking for a short term solution
until they can complete that project.  I found where windows is logging the
error.  I am just not sure which process writes to this log or how to tell it to
ignore the error.  I thought I had it with a registry entry but it didn't fix 
the
problem.

C:\Windows\System32\LogFiles\HTTPERR


This looks like a windows system running IIS.
IIS also has some max-settings for requests.
Maybe you can check the IIS advanced settings for this site.


This could be an IIS with mod_jk or an ARR reverse proxy. When this is 
specific to GET requests increasing MaxFieldLength for http.sys should help


Reference: 
https://learn.microsoft.com/en-US/troubleshoot/developer/webapps/iis/iisadmin-service-inetinfo/httpsys-registry-windows


It might be necessary to tune other settings but those should have 
different status codes.




2023-03-09 23:55:40 192.168.103.30 56355 192.168.0.27 80 - GET - - 414 -
URL_Length -


You should keep an eye on this log entry: this is a GET request as your 
SAMPLE POST already indicated. Maybe you can check back with your 
developers that they change their code to really use the POST method



On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
wrote:


On 3/9/2023 5:47 PM, Jason Tan wrote:

Hi Seth,
One of my customer had the same error. We also tried increasing

maxHttpHeaderSize as suggested on Google.  It worked for him for a
while, but he encountered the same error again later on.

Our developers got involved and later discovered that our app was
trying

to display all his favourites and the customer somehow managed to
accumulate a huge list of favourites. So, a hotfix was created to
limit the size of the favourites that get displayed on to the browser.

I hope that helps you sort it out with the application to find what
huge

data is being push onto the url and limit it.

-Original Message-
From: Mark Thomas 
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The
request URL is too long".

I have tried adding a bunch of parameters to my server.xml file but
none of them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running
Tomcat
8.5 but his solution (maxhttpheadersize) did not work for me.  Did
something change between 8.5 and 9.0.48 that might affect things?
Is something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status
code

is originating, it isn't Tomcat. It must be in the application or in a
component before Tomcat.


Mark




SAMPLE POST (the one that fails is FAR larger than this)



http://servername/gatewayAdminTest/GatewayClient?OutputType=1

Typ
e=1=

 

   LSF
   01092390
   02
   
   test_promo_freeProduct
   DROP
   
   
   01092391
   WEB001232
   O


   
  39012621
  1.0
  BAG
   

 
  

=xxx
--



Are you sure that's POST request? I'd suggest looking at the Tomcat
access log if you can get a request that far.

-Terence Bandoian


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




--


[image: photograph]

*Seth Mayers* Chief Technology Officer
*p:*
*e:* seth.may...@petfoodexperts.com
www.petfoodexperts.com
[image: facebook icon] <https://www.facebook.com/PFExperts>  [image:
instagram icon] <https://www.instagram.com/petfoodexperts>  [image:
linkedin icon] <https://www.linkedin.com/company/pet-food-experts>  [image:
twitter icon] <https://twitter.com/petfoodexperts>  [image: youtube icon]
<https://www.youtube.com/c/PetFoodExperts>


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



- Stefan

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

AW: HTTP Error 414. The request URL is too long.

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Seth Mayers 
> Gesendet: Freitag, 10. März 2023 01:14
> An: Tomcat Users List 
> Betreff: Re: HTTP Error 414. The request URL is too long.
> 
> Thanks.  Sadly I know how the data is being pushed.  It is poorly architected.
> Developers are working to re-write it but I am looking for a short term 
> solution
> until they can complete that project.  I found where windows is logging the
> error.  I am just not sure which process writes to this log or how to tell it 
> to
> ignore the error.  I thought I had it with a registry entry but it didn't fix 
> the
> problem.
> 
> C:\Windows\System32\LogFiles\HTTPERR

This looks like a windows system running IIS.
IIS also has some max-settings for requests.
Maybe you can check the IIS advanced settings for this site.


> 
> 2023-03-09 23:55:40 192.168.103.30 56355 192.168.0.27 80 - GET - - 414 -
> URL_Length -
> 
> On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
> wrote:
> 
> > On 3/9/2023 5:47 PM, Jason Tan wrote:
> > > Hi Seth,
> > > One of my customer had the same error. We also tried increasing
> > maxHttpHeaderSize as suggested on Google.  It worked for him for a
> > while, but he encountered the same error again later on.
> > > Our developers got involved and later discovered that our app was
> > > trying
> > to display all his favourites and the customer somehow managed to
> > accumulate a huge list of favourites. So, a hotfix was created to
> > limit the size of the favourites that get displayed on to the browser.
> > > I hope that helps you sort it out with the application to find what
> > > huge
> > data is being push onto the url and limit it.
> > > -Original Message-
> > > From: Mark Thomas 
> > > Sent: Friday, March 10, 2023 9:34 AM
> > > To: users@tomcat.apache.org
> > > Subject: Re: HTTP Error 414. The request URL is too long.
> > >
> > > On 09/03/2023 20:59, Seth Mayers wrote:
> > >> I am running Apache Tomcat Version 9.0.48.
> > >>
> > >> If I post a transaction that is very large, I get the "414; The
> > >> request URL is too long".
> > >>
> > >> I have tried adding a bunch of parameters to my server.xml file but
> > >> none of them seem to work.  I have tried:
> > >> maxHttpHeaderSize="262144"
> > >> maxSavePostSize="-1"
> > >> maxPostSize="-1"
> > >> maxHttpRequestHeaderSize="262144"
> > >>
> > >> I have someone that was able to resolve the same issue running
> > >> Tomcat
> > >> 8.5 but his solution (maxhttpheadersize) did not work for me.  Did
> > >> something change between 8.5 and 9.0.48 that might affect things?
> > >> Is something involved beyond just server.xml?
> > > Tomcat 9.0.x never returns a 414 status code. Wherever that status
> > > code
> > is originating, it isn't Tomcat. It must be in the application or in a
> > component before Tomcat.
> > >
> > > Mark
> > >
> > >
> > >>
> > >> SAMPLE POST (the one that fails is FAR larger than this)
> > >>
> > >>
> http://servername/gatewayAdminTest/GatewayClient?OutputType=1
> > >> Typ
> > >> e=1= > >> name="CreateOrder">
> > >> 
> > >> 
> > >>    
> > >>   LSF
> > >>   01092390
> > >>   02
> > >>   
> > >>   test_promo_freeProduct
> > >>   DROP
> > >>   
> > >>   
> > >>   01092391
> > >>   WEB001232
> > >>   O
> > >>
> > >>
> > >>   
> > >>  39012621
> > >>  1.0
> > >>  BAG
> > >>   
> > >>
> > >> 
> > >>  
> > >> 
> > >> =xxx
> > >> --
> > >>
> >
> > Are you sure that's POST request? I'd suggest looking at the Tomcat
> > access log if you can get a request that far.
> >
> > -Terence Bandoian
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> 
> --
> 
> 
> [image: photograph]
> 
> *Seth Mayers* Chief Technology Officer
> *p:*
> *e:* seth.may...@petfoodexperts.com
> www.petfoodexperts.com
> [image: facebook icon] <https://www.facebook.com/PFExperts>  [image:
> instagram icon] <https://www.instagram.com/petfoodexperts>  [image:
> linkedin icon] <https://www.linkedin.com/company/pet-food-experts>  [image:
> twitter icon] <https://twitter.com/petfoodexperts>  [image: youtube icon]
> <https://www.youtube.com/c/PetFoodExperts>

Re: HTTP Error 414. The request URL is too long.

[Seth Mayers]

Thanks.  Sadly I know how the data is being pushed.  It is poorly
architected.  Developers are working to re-write it but I am looking for a
short term solution until they can complete that project.  I found where
windows is logging the error.  I am just not sure which process writes to
this log or how to tell it to ignore the error.  I thought I had it with a
registry entry but it didn't fix the problem.

C:\Windows\System32\LogFiles\HTTPERR

2023-03-09 23:55:40 192.168.103.30 56355 192.168.0.27 80 - GET - - 414 -
URL_Length -

On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
wrote:

> On 3/9/2023 5:47 PM, Jason Tan wrote:
> > Hi Seth,
> > One of my customer had the same error. We also tried increasing
> maxHttpHeaderSize as suggested on Google.  It worked for him for a while,
> but he encountered the same error again later on.
> > Our developers got involved and later discovered that our app was trying
> to display all his favourites and the customer somehow managed to
> accumulate a huge list of favourites. So, a hotfix was created to limit the
> size of the favourites that get displayed on to the browser.
> > I hope that helps you sort it out with the application to find what huge
> data is being push onto the url and limit it.
> > -Original Message-
> > From: Mark Thomas 
> > Sent: Friday, March 10, 2023 9:34 AM
> > To: users@tomcat.apache.org
> > Subject: Re: HTTP Error 414. The request URL is too long.
> >
> > On 09/03/2023 20:59, Seth Mayers wrote:
> >> I am running Apache Tomcat Version 9.0.48.
> >>
> >> If I post a transaction that is very large, I get the "414; The
> >> request URL is too long".
> >>
> >> I have tried adding a bunch of parameters to my server.xml file but
> >> none of them seem to work.  I have tried:
> >> maxHttpHeaderSize="262144"
> >> maxSavePostSize="-1"
> >> maxPostSize="-1"
> >> maxHttpRequestHeaderSize="262144"
> >>
> >> I have someone that was able to resolve the same issue running Tomcat
> >> 8.5 but his solution (maxhttpheadersize) did not work for me.  Did
> >> something change between 8.5 and 9.0.48 that might affect things?  Is
> >> something involved beyond just server.xml?
> > Tomcat 9.0.x never returns a 414 status code. Wherever that status code
> is originating, it isn't Tomcat. It must be in the application or in a
> component before Tomcat.
> >
> > Mark
> >
> >
> >>
> >> SAMPLE POST (the one that fails is FAR larger than this)
> >>
> >> http://servername/gatewayAdminTest/GatewayClient?OutputType=1
> >> e=1= >> name="CreateOrder">
> >> 
> >> 
> >>
> >>   LSF
> >>   01092390
> >>   02
> >>   
> >>   test_promo_freeProduct
> >>   DROP
> >>   
> >>   
> >>   01092391
> >>   WEB001232
> >>   O
> >>
> >>
> >>   
> >>  39012621
> >>  1.0
> >>  BAG
> >>   
> >>
> >> 
> >>  
> >> 
> >> =xxx
> >> --
> >>
>
> Are you sure that's POST request? I'd suggest looking at the Tomcat
> access log if you can get a request that far.
>
> -Terence Bandoian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 


[image: photograph]

*Seth Mayers* Chief Technology Officer
*p:*
*e:* seth.may...@petfoodexperts.com
www.petfoodexperts.com
[image: facebook icon] <https://www.facebook.com/PFExperts>  [image:
instagram icon] <https://www.instagram.com/petfoodexperts>  [image:
linkedin icon] <https://www.linkedin.com/company/pet-food-experts>  [image:
twitter icon] <https://twitter.com/petfoodexperts>  [image: youtube icon]
<https://www.youtube.com/c/PetFoodExperts>

Re: HTTP Error 414. The request URL is too long.

[Terence M. Bandoian]

On 3/9/2023 5:47 PM, Jason Tan wrote:

Hi Seth,
One of my customer had the same error. We also tried increasing 
maxHttpHeaderSize as suggested on Google.  It worked for him for a while, but 
he encountered the same error again later on.
Our developers got involved and later discovered that our app was trying to 
display all his favourites and the customer somehow managed to accumulate a 
huge list of favourites. So, a hotfix was created to limit the size of the 
favourites that get displayed on to the browser.
I hope that helps you sort it out with the application to find what huge data 
is being push onto the url and limit it.
-Original Message-
From: Mark Thomas 
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The
request URL is too long".

I have tried adding a bunch of parameters to my server.xml file but
none of them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running Tomcat
8.5 but his solution (maxhttpheadersize) did not work for me.  Did
something change between 8.5 and 9.0.48 that might affect things?  Is
something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status code is 
originating, it isn't Tomcat. It must be in the application or in a component 
before Tomcat.

Mark




SAMPLE POST (the one that fails is FAR larger than this)

http://servername/gatewayAdminTest/GatewayClient?OutputType=1
e=1=


   
  LSF
  01092390
  02
  
  test_promo_freeProduct
  DROP
  
  
  01092391
  WEB001232
  O
   
   
  
 39012621
 1.0
 BAG
  
   
    
 

=xxx
--



Are you sure that's POST request? I'd suggest looking at the Tomcat 
access log if you can get a request that far.


-Terence Bandoian


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

RE: HTTP Error 414. The request URL is too long.

[Jason Tan]

Hi Seth,
One of my customer had the same error. We also tried increasing 
maxHttpHeaderSize as suggested on Google.  It worked for him for a while, but 
he encountered the same error again later on.
Our developers got involved and later discovered that our app was trying to 
display all his favourites and the customer somehow managed to accumulate a 
huge list of favourites. So, a hotfix was created to limit the size of the 
favourites that get displayed on to the browser.
I hope that helps you sort it out with the application to find what huge data 
is being push onto the url and limit it.
-Original Message-
From: Mark Thomas  
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:
> I am running Apache Tomcat Version 9.0.48.
> 
> If I post a transaction that is very large, I get the "414; The 
> request URL is too long".
> 
> I have tried adding a bunch of parameters to my server.xml file but 
> none of them seem to work.  I have tried:
> maxHttpHeaderSize="262144"
> maxSavePostSize="-1"
> maxPostSize="-1"
> maxHttpRequestHeaderSize="262144"
> 
> I have someone that was able to resolve the same issue running Tomcat 
> 8.5 but his solution (maxhttpheadersize) did not work for me.  Did 
> something change between 8.5 and 9.0.48 that might affect things?  Is 
> something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status code is 
originating, it isn't Tomcat. It must be in the application or in a component 
before Tomcat.

Mark


> 
> 
> SAMPLE POST (the one that fails is FAR larger than this)
> 
> http://servername/gatewayAdminTest/GatewayClient?OutputType=1
> e=1= name="CreateOrder">
> 
>
>   
>  LSF
>  01092390
>  02
>  
>  test_promo_freeProduct
>  DROP
>  
>  
>  01092391
>  WEB001232
>  O
>   
>   
>  
> 39012621
> 1.0
> BAG
>  
>   
>
> 
> 
> =xxx
> --
> 

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

Re: HTTP Error 414. The request URL is too long.

[Mark Thomas]

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The request URL
is too long".

I have tried adding a bunch of parameters to my server.xml file but none of
them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running Tomcat 8.5
but his solution (maxhttpheadersize) did not work for me.  Did something
change between 8.5 and 9.0.48 that might affect things?  Is
something involved beyond just server.xml?


Tomcat 9.0.x never returns a 414 status code. Wherever that status code 
is originating, it isn't Tomcat. It must be in the application or in a 
component before Tomcat.


Mark





SAMPLE POST (the one that fails is FAR larger than this)

http://servername/gatewayAdminTest/GatewayClient?OutputType=1=1=

   
  
 LSF
 01092390
 02
 
 test_promo_freeProduct
 DROP
 
 
 01092391
 WEB001232
 O
  
  
 
39012621
1.0
BAG
 
  
   


=xxx
--



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

HTTP Error 414. The request URL is too long.

[Seth Mayers]

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The request URL
is too long".

I have tried adding a bunch of parameters to my server.xml file but none of
them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running Tomcat 8.5
but his solution (maxhttpheadersize) did not work for me.  Did something
change between 8.5 and 9.0.48 that might affect things?  Is
something involved beyond just server.xml?


SAMPLE POST (the one that fails is FAR larger than this)

http://servername/gatewayAdminTest/GatewayClient?OutputType=1=1=

  
 
LSF
01092390
02

test_promo_freeProduct
DROP


01092391
WEB001232
O
 
 

   39012621
   1.0
   BAG

 
  
   

=xxx
--

Issue with request context empty after http error

[Mitch]

Hello,

I’m currently trying to resolve an issue from our customer about a tomcat 
version visible if bad characters are inserted into the URL (steps to reproduce 
is to add a ‘{‘) This produces an HTTP 400 and redirects you to the default 
tomcat error page with a stacktrace and version number.
To resolve this, I want every generic http error to redirect to a logout 
servlet which then immediately kills the session (not elegant, but sufficient 
enough for our customer). To do this I could use an ErrorReportValve, but that 
from what I understand is only able to go to static HTML pages (a jsp would’ve 
worked for me here as well bit doesn't seem possible?). Instead I should be 
able to define http errors in the web.xml. This functionality doesn’t seem to 
work for me.

Debugging my issue I find that in order for this to work, it needs to trigger a 
status(req,res) function in StandardHostValve.java. This should be done by the 
default ErrorReportValve’s invoke(req,res) . When this happens tho, the first 
step in invoke is checking if the context is null. This is always the case for 
me, because the uri never gets set because it’s an invalid uri (with an invalid 
character). If the context is null, the status function is never called, and 
thus the default error page gets generated instead.

My question is as followed. Is this a bug or is this a possible fault in my 
configuration? My configuration is as followed (some values masked for security 
reasons)

Tomcat version tested: 9.0.62, 9.0.72
Host OS: Windows 10
Java version: 11.0.4

— ${CATALINA_HOME}/conf/server.xml —














— ${CATALINA_HOME}/webapps/ROOT/WEB-INF/web.xml —

http://java.sun.com/xml/ns/javaee” 
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” 
xsi:schemaLocation=“http://java.sun.com/xml/ns/javaee 
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd” version=“3.0”>


/logout.htm



All servlet mapping is done with Spring web MVC

Regards,

Mitch

Re: how to block bad request?

[Jason Wee]

Hi Mark,

Thank you. I enabled debugging and able to reproduce (close to
matching, but not exact same output)

send null byte




$ echo -e '\x00' | nc myhost.com 80
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1939
Date: Mon, 09 Jan 2023 08:58:52 GMT
Connection: close

HTTP Status 400 – Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 – Bad RequestType
Exception ReportMessage Invalid character found in
method name [0x00...]. HTTP method names must be
tokensDescription 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).Exceptionjava.lang.IllegalArgumentException:
Invalid character found in method name [0x00...]. HTTP method names
must be tokens
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:418)
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:845)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1563)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
java.basejava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
java.basejava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.basejava.lang.Thread.run(Thread.java:834)
Note The full stack trace of the root cause is
available in the server logs.CustomServer


the log file


09-Jan-2023 08:58:50.239 FINE [https-jsse-nio-8474-exec-3]
org.apache.coyote.AbstractProcessorLight.process Socket:
[org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@573dbc7:org.apache.tomcat.util.net.SecureNioChannel@304f418e:java.nio.channels.SocketChannel[connected
local=/142.222.222.222:8080 remote=/194.111.111.111:9385]], Status in:
[OPEN_READ], State out: [OPEN]
09-Jan-2023 08:58:52.867 FINE [http-nio-8084-exec-6]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request header
java.lang.IllegalArgumentException: Invalid character found in method
name [0x00...]. HTTP method names must be tokens
at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:418)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:845)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1563)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
09-Jan-2023 08:58:52.867 FINE [http-nio-8084-exec-6]
org.apache.coyote.http11.Http11Processor.badRequest The HTTP/1.1
request did not provide a host header
09-Jan-2023 08:58:52.868 FINE [http-nio-8084-exec-6]
org.apache.coyote.AbstractProcessorLight.process Socket:
[org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@19369f2d:org.apache.tomcat.util.net.NioChannel@34663eed:java.nio.channels.SocketChannel[connected
local=/142.222.222.222:8080 remote=/210.111.111.111:53328]], Status
in: [OPEN_READ], State out: [CLOSED]



==> .access_log.2023-01-09.txt <==
210.111.111.111 - 210.111.111.111 - - [09/Jan/2023:08:58:52 +] '-'
400 1939 '-' '-' 686 -



in production

206.189.134.129 - 206.189.134.129 - - [09/Jan/2023:06:11:06 +] '-'
400 - '-' '-' 0 -



The different is

%b - Bytes sent, excluding HTTP headers, or '-' if zero
%D - Time taken to process the request in microseconds


so I guess the attacker check if the port is opened without sending
any bytes and tomcat took 0 second to process.


Christopher,

no, X-Forwarded-For and %h values are not the same.

On Fri, Jan 6, 2023 at 6:30 AM Christopher Schultz
 wrote:
>
> Mark, Jason,
>
> On 1/4/23 09:07, Mark Thomas wrote:
> > On 04/01/2023 04:09, Jason Wee wrote:
> >> Hi,
> >>
> >> Happy new year everyone.
> >>
> >

Re: how to block bad request?

[Christopher Schultz]

Mark, Jason,

On 1/4/23 09:07, Mark Thomas wrote:

On 04/01/2023 04:09, Jason Wee wrote:

Hi,

Happy new year everyone.

Background of my production setup. Using tomcat 10 and in linux
environment, using the following accesslog valve

%a %{X-Forwarded-For}i %h %l %u %t '%r' %s %b '%{Referer}i'
'%{User-Agent}i' %D %S

api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -

I often see the above registered in accesslog and have the following 
questions


1. how/where to find more information about such requests? example how
to reproduce of such request, how to enable debug to give more details
about such request, etc?


Enable debug logging for
org.apache.coyote.http11.Http11Processor

2. how to block such requests (at tomcat or at firewall or any other 
way)?


Tomcat has already blocked them. The requests were invalid. Processing 
stopped as soon as the request was found to be invalid. A 400 response 
was returned and the connection closed. There is little else Tomcat can do.


Options for blocking earlier depend on why the requests are invalid. 
That said, Tomcat appears to be behind a reverse proxy. In most (all?) 
cases, I'd expect the proxy to reject the request before it gets to Tomcat.


Those requests look like they actually came from the reverse proxy 
(X-Forwarded-For and %h values are the same). They look a *lot* like 
"are you alive" requests that reverse proxies will often send to 
back-end servers to see whether or not real traffic should be sent to 
those back-end servers.


-chris

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

Re: how to block bad request?

[Mark Thomas]

On 04/01/2023 04:09, Jason Wee wrote:

Hi,

Happy new year everyone.

Background of my production setup. Using tomcat 10 and in linux
environment, using the following accesslog valve

%a %{X-Forwarded-For}i %h %l %u %t '%r' %s %b '%{Referer}i'
'%{User-Agent}i' %D %S

api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -

I often see the above registered in accesslog and have the following questions

1. how/where to find more information about such requests? example how
to reproduce of such request, how to enable debug to give more details
about such request, etc?


Enable debug logging for
org.apache.coyote.http11.Http11Processor


2. how to block such requests (at tomcat or at firewall or any other way)?


Tomcat has already blocked them. The requests were invalid. Processing 
stopped as soon as the request was found to be invalid. A 400 response 
was returned and the connection closed. There is little else Tomcat can do.


Options for blocking earlier depend on why the requests are invalid. 
That said, Tomcat appears to be behind a reverse proxy. In most (all?) 
cases, I'd expect the proxy to reject the request before it gets to Tomcat.



3. what impact it has to tomcat (or service) if these requests come in
huge amounts and in a short time.


Minimal. Less impact than if valid requests were made since processing 
stops as soon as the request is found to be invalid. You might want to 
look at rate limiting abusive clients but in terms of a DoS, a valid 
request will cause more harm than one of these.


Mark



Thank you and happy to hear any other comments/opinions too.

Kind regards,
Jason

-
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

how to block bad request?

[Jason Wee]

Hi,

Happy new year everyone.

Background of my production setup. Using tomcat 10 and in linux
environment, using the following accesslog valve

%a %{X-Forwarded-For}i %h %l %u %t '%r' %s %b '%{Referer}i'
'%{User-Agent}i' %D %S

api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:27:36 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -
api.access_log.2022-12-20.txt:94.102.61.23 - 94.102.61.23 - -
[20/Dec/2022:01:30:42 +0100] '-' 400 - '-' '-' 0 -

I often see the above registered in accesslog and have the following questions

1. how/where to find more information about such requests? example how
to reproduce of such request, how to enable debug to give more details
about such request, etc?
2. how to block such requests (at tomcat or at firewall or any other way)?
3. what impact it has to tomcat (or service) if these requests come in
huge amounts and in a short time.

Thank you and happy to hear any other comments/opinions too.

Kind regards,
Jason

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

Re: [SECURITY][UPDATE] CVE-2022-42252 Apache Tomcat - Request Smuggling

[Christopher Schultz]

All,

There is a typo in this announcement.

The affected versions of Tomcat8.5 are 8.5.0 to 8.0.82, not 8.5.52.

Thanks,
-chris

On 10/31/22 12:46, Mark Thomas wrote:

CVE-2022-42252 Apache Tomcat - Request Smuggling

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.1.0-M1 to 10.1.0
Apache Tomcat 10.0.0-M1 to 10.0.26
Apache Tomcat 9.0.0-M1 to 9.0.67
Apache Tomcat 8.5.0 to 8.5.52

Description:
If Tomcat was configured to ignore invalid HTTP headers via setting
rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did 
not reject a request containing an invalid Content-Length header making 
a request smuggling attack  possible if Tomcat was located behind a 
reverse proxy that also failed to reject the request with the invalid 
header.



Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Ensure rejectIllegalHeader is set to true
- Upgrade to Apache Tomcat 10.1.1 or later
- Upgrade to Apache Tomcat 10.0.27 or later
- Upgrade to Apache Tomcat 9.0.68 or later
- Upgrade to Apache Tomcat 8.5.83 or later

Credit:
Thanks to Sam Shahsavar who discovered this issue and reported it to the 
Apache Tomcat security team.


History:
2022-10-31 Original advisory

References:
[1] https://tomcat.apache.org/security-10.html
[2] https://tomcat.apache.org/security-9.html
[3] https://tomcat.apache.org/security-8.html


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



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

[SECURITY] CVE-2022-42252 Apache Tomcat - Request Smuggling

[Mark Thomas]

CVE-2022-42252 Apache Tomcat - Request Smuggling

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.1.0-M1 to 10.1.0
Apache Tomcat 10.0.0-M1 to 10.0.26
Apache Tomcat 9.0.0-M1 to 9.0.67
Apache Tomcat 8.5.0 to 8.5.52

Description:
If Tomcat was configured to ignore invalid HTTP headers via setting
rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did 
not reject a request containing an invalid Content-Length header making 
a request smuggling attack  possible if Tomcat was located behind a 
reverse proxy that also failed to reject the request with the invalid 
header.



Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Ensure rejectIllegalHeader is set to true
- Upgrade to Apache Tomcat 10.1.1 or later
- Upgrade to Apache Tomcat 10.0.27 or later
- Upgrade to Apache Tomcat 9.0.68 or later
- Upgrade to Apache Tomcat 8.5.83 or later

Credit:
Thanks to Sam Shahsavar who discovered this issue and reported it to the 
Apache Tomcat security team.


History:
2022-10-31 Original advisory

References:
[1] https://tomcat.apache.org/security-10.html
[2] https://tomcat.apache.org/security-9.html
[3] https://tomcat.apache.org/security-8.html


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

Re: How to check no of user request coming in tomcat application in a minute

[Christopher Schultz]

Priyanka,

On 9/8/22 13:20, Kumawat, Priyanka wrote:
Do you want to be able to pick an arbitrary minute, or are you 
more interested in e.g. "the most recent minute or activity"?


We wanted to count the number of users hitting the application on 
tomcat/Apache , as an example for today how many users hits/send

request to the application


Requests != users.


How shall we check this request , please suggest.


I think you need to have a more well-defined question.

For example:

For a given day, we'd like to know how many requests we get per-minute, 
so we want data that looks like this:


date,hour,minute,request_count
2022-09-08,00,01,123
2022-09-08,00,02,456
2022-09-08,00,03,789
2022-09-08,00,04,876
2022-09-08,00,05,256
...

If you want to know the number of users, you'll have to define "user". 
And you probably won't be able to get that information from the 
access-log without some additional work. If you mean "established user 
session", then you'll have to probe Tomcat to find out how many sessions 
exist on whatever schedule you want. If you mean "established session 
with authentication" then you'll have to do a different kind of probe.


If you want to know how many unique authenticated-users made requests 
during a specific minute, that's yet another question and one that CAN 
be answered by looking at the access-log, as long as you add some 
convenient information to it (the user principal) and then use some 
text-processing tools to collate the information.


-chris


-Original Message-
From: Christopher Schultz 
Sent: 08 September 2022 20:04
To: users@tomcat.apache.org
Subject: Re: How to check no of user request coming in tomcat application in a 
minute

Koustav,

On 9/8/22 10:06, Naha, Koustav wrote:

Just want to know how can we calculate the number of user request processed by 
tomcat in a particular minute.


Do you want to be able to pick an arbitrary minute, or are you more interested in e.g. 
"the most recent minute or activity"?


Can we do it from Apache access logs?


Sure.

$ grep '08/Sep/2022:14:32:' access.log | wc


Version

*   Tomcat 8.5.5


Ouch. That version is 6 years old with published security vulnerabilities. I 
strongly suggest that you upgrade ASAP.


*   Apache 2.4


I'm gonna guess that this is out-of-date, too. Latest is 2.4.54 from back in 
June 2022.

-chris

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



DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

-
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: How to check no of user request coming in tomcat application in a minute

[Kumawat, Priyanka]

Hi Christopher,

> Do you want to be able to pick an arbitrary minute, or are you more 
> interested in e.g. "the most recent minute or activity"?

We wanted to count the number of users hitting the application on tomcat/Apache 
, as an example for today how many users hits/send request to the application ,
How shall we check this request , please suggest.

Thanks & Regards,

Priyanka Kumawat | Middleware Admin
T +91.7879364483
EMail - priyanka.kuma...@dxc.com
DL - ams-leveraged-webadmin-offsh...@dxc.com

DXC Technology


-Original Message-
From: Christopher Schultz 
Sent: 08 September 2022 20:04
To: users@tomcat.apache.org
Subject: Re: How to check no of user request coming in tomcat application in a 
minute

Koustav,

On 9/8/22 10:06, Naha, Koustav wrote:
> Just want to know how can we calculate the number of user request processed 
> by tomcat in a particular minute.

Do you want to be able to pick an arbitrary minute, or are you more interested 
in e.g. "the most recent minute or activity"?

> Can we do it from Apache access logs?

Sure.

$ grep '08/Sep/2022:14:32:' access.log | wc

> Version
>
>*   Tomcat 8.5.5

Ouch. That version is 6 years old with published security vulnerabilities. I 
strongly suggest that you upgrade ASAP.

>*   Apache 2.4

I'm gonna guess that this is out-of-date, too. Latest is 2.4.54 from back in 
June 2022.

-chris

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



DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

Re: How to check no of user request coming in tomcat application in a minute

[Christopher Schultz]

Koustav,

On 9/8/22 10:06, Naha, Koustav wrote:

Just want to know how can we calculate the number of user request processed by 
tomcat in a particular minute.


Do you want to be able to pick an arbitrary minute, or are you more 
interested in e.g. "the most recent minute or activity"?



Can we do it from Apache access logs?


Sure.

$ grep '08/Sep/2022:14:32:' access.log | wc


Version

   *   Tomcat 8.5.5


Ouch. That version is 6 years old with published security 
vulnerabilities. I strongly suggest that you upgrade ASAP.



   *   Apache 2.4


I'm gonna guess that this is out-of-date, too. Latest is 2.4.54 from 
back in June 2022.


-chris

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

How to check no of user request coming in tomcat application in a minute

[Naha, Koustav]

Hi,

Just want to know how can we calculate the number of user request processed by 
tomcat in a particular minute.

Can we do it from Apache access logs?

Version

  *   Tomcat 8.5.5
  *   Apache 2.4

Thanks,
Koustav


DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

AW: Request For suggestion

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mohan,

> -Ursprüngliche Nachricht-
> Von: Mohan T 
> Gesendet: Sonntag, 7. August 2022 18:18
> An: Tomcat Users List 
> Betreff: Request For suggestion
> 
> Dear All,
> 
> We are getting this error on launch of a url in browser.
> 
> We are using tomcat 8.5 on suse linux. 7. We are using JDK 1.8.
> 
> Your browser sent a request that this server could not understand.
> Reason: You're speaking plain HTTP to an SSL-enabled server port.
> Instead use the HTTPS scheme to access this URL, please.
> 
> Any inputs on this will be of great help
> 
> Thanks
> 
> Mohan


it looks like you are connecting via http to an https port.
You can take a look at server.xml which connector (port) uses which protocol.

For ssl enabled ports you must use https.

Greetings,
Thomas

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

Request For suggestion

[Mohan T]

Dear All,

We are getting this error on launch of a url in browser.

We are using tomcat 8.5 on suse linux. 7. We are using JDK 1.8.

Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.

Any inputs on this will be of great help

Thanks

Mohan
DISCLAIMER: This communication contains information which is confidential and 
the copyright of Ramco Systems Ltd, its subsidiaries or a third party 
("Ramco"). This email may also contain legally privileged information. 
Confidentiality and legal privilege attached to this communication are not 
waived or lost by reason of mistaken delivery to you.This email is intended to 
be read or used by the addressee only. If you are not the intended recipient, 
any use, distribution, disclosure or copying of this email is strictly 
prohibited without the express written approval of Ramco. Please delete and 
destroy all copies and email Ramco at le...@ramco.com immediately. Any views 
expressed in this communication are those of the individual sender, except 
where the sender specifically states them to be the views of Ramco. Except as 
required by law, Ramco does not represent, warrant and/or guarantee that the 
integrity of this communication has been maintained nor that the communication 
is free of errors, virus, interception or interference. If you do not wish to 
receive such communications, please forward this communication to 
market...@ramco.com and express your wish not to receive such communications 
henceforth.

AW: AW: Request for SSL Setup

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Manibharathi R 
> Gesendet: Dienstag, 28. Juni 2022 08:56
> An: Tomcat Users List 
> Betreff: Re: AW: Request for SSL Setup
> 
> Thanks for your prompt response.
> 
> Could you please send me the procedure that how can we generate
> certficates files?
> 
> -Original Message-
> From: Thomas Hoffmann (Speed4Trade GmbH)
> Sent: Tuesday, June 28, 2022 12:13 PM
> To: Tomcat Users List
> Subject: AW: Request for SSL Setup
> 
> This email came from an external source. Please do not click links or open
> attachments unless you recognize the sender.
> 
> 
> Hello,
> 
> > -Ursprüngliche Nachricht-
> > Von: Manibharathi R 
> > Gesendet: Dienstag, 28. Juni 2022 07:16
> > An: users@tomcat.apache.org
> > Betreff: Request for SSL Setup
> >
> > Dear Team,
> >
> > Greetings,
> >
> > I have done keystore generation, import key features and changes done
> > in server.xm. But still I am unable to access throught https.
> >
> > Kindly send me the causes of this issue
> >
> > Regards,
> > R.Manibharathi,
> > AM,Android Mobile App Developer
> >
> > 
> >
> 
> Could you please check all logfiles if there are some errors shown?
> Any stacktraces, warnings or errors visible?
> Is there a line like "org.apache.coyote.AbstractProtocol.start Starting
> ProtocolHandler ["https-openssl-nio-443"]" ?
> 
> Greetings, Thomas
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> Regards,
> R.Manibharathi,
> AM,Android Mobile App Developer
> 

You can do it e.g. with keytool:
https://stackoverflow.com/questions/42541356/how-to-create-a-self-signed-ssl-certificate-for-use-with-tomcat
This generates a self-signed certificate which is suitable for development and 
testing purposes.

Another method is using OpenSSL but this involves multiple steps:
https://www.baeldung.com/openssl-self-signed-cert

If you need a public signed certificate, you can generate a CSR with OpenSSL 
and send it to a certificate authority to get it signed.

Background information:
For using SSL you always need a matching keypair, this is a public and a 
private key. The private key is signed.
The clients needs to trust the signature (with the corresponding signatures 
public key).
A jks-file can store both keys. Alternatively you can use two separate files 
(e.g. in PEM-format) and configure the tomcat-connector to use both files.

Greetings, Thomas



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

Re: AW: Request for SSL Setup

[Manibharathi R]

Thanks for your prompt response.

Could you please send me the procedure that how can we generate certficates
files?

-Original Message-
From: Thomas Hoffmann (Speed4Trade GmbH)
Sent: Tuesday, June 28, 2022 12:13 PM
To: Tomcat Users List
Subject: AW: Request for SSL Setup

This email came from an external source. Please do not click links or open
attachments unless you recognize the sender.


Hello,


-Ursprüngliche Nachricht-
Von: Manibharathi R 
Gesendet: Dienstag, 28. Juni 2022 07:16
An: users@tomcat.apache.org
Betreff: Request for SSL Setup

Dear Team,

Greetings,

I have done keystore generation, import key features and changes done in
server.xm. But still I am unable to access throught https.

Kindly send me the causes of this issue

Regards,
R.Manibharathi,
AM,Android Mobile App Developer





Could you please check all logfiles if there are some errors shown?
Any stacktraces, warnings or errors visible?
Is there a line like "org.apache.coyote.AbstractProtocol.start Starting
ProtocolHandler ["https-openssl-nio-443"]" ?

Greetings, Thomas

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

Regards,
R.Manibharathi,
AM,Android Mobile App Developer




This email and its attachments may contain confidential, proprietary or legally 
privileged information and is intended solely for the use of the individual or 
entity to whom it is addressed. If you have erroneously received this message, 
please delete it immediately and notify the sender. Any unauthorized review, 
use, disclosure, dissemination, forwarding, printing or copying of this email 
or any action taken in reliance on this e-mail is strictly prohibited and may 
be unlawful. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
incomplete or contain viruses and any views expressed in this message are those 
of the individual sender and no binding nature of the message shall be implied 
or assumed unless the sender does so expressly with due authority of Suguna 
Foods Private Limited, its associates/subsidiaries.

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

AW: Request for SSL Setup

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Manibharathi R 
> Gesendet: Dienstag, 28. Juni 2022 07:16
> An: users@tomcat.apache.org
> Betreff: Request for SSL Setup
> 
> Dear Team,
> 
> Greetings,
> 
> I have done keystore generation, import key features and changes done in
> server.xm. But still I am unable to access throught https.
> 
> Kindly send me the causes of this issue
> 
> Regards,
> R.Manibharathi,
> AM,Android Mobile App Developer
> 
> 
> 

Could you please check all logfiles if there are some errors shown?
Any stacktraces, warnings or errors visible?
Is there a line like "org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["https-openssl-nio-443"]" ?

Greetings, Thomas

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

Request for SSL Setup

[Manibharathi R]

Dear Team,

Greetings,

I have done keystore generation, import key features and changes done in 
server.xm. But still I am unable to access throught https.

Kindly send me the causes of this issue

Regards,
R.Manibharathi,
AM,Android Mobile App Developer



This email and its attachments may contain confidential, proprietary or legally 
privileged information and is intended solely for the use of the individual or 
entity to whom it is addressed. If you have erroneously received this message, 
please delete it immediately and notify the sender. Any unauthorized review, 
use, disclosure, dissemination, forwarding, printing or copying of this email 
or any action taken in reliance on this e-mail is strictly prohibited and may 
be unlawful. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
incomplete or contain viruses and any views expressed in this message are those 
of the individual sender and no binding nature of the message shall be implied 
or assumed unless the sender does so expressly with due authority of Suguna 
Foods Private Limited, its associates/subsidiaries.

[SECURITY] CVE-2022-25762 Apache Tomcat - Request Mix-up

[Mark Thomas]

CVE-2022-25762 Apache Tomcat - Request Mix-up

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.20
Apache Tomcat 8.5.0 to 8.5.75

Description:
If a web application sends a WebSocket message concurrently with the 
WebSocket connection closing, it is possible that the application will 
continue to use the socket after it has been closed. The error handling 
triggered in this case could cause the a pooled object to be placed in 
the pool twice. This could result in subsequent connections using the 
same object concurrently which could result in data being returned to 
the wrong use and/or other errors.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.21 or later
- Upgrade to Apache Tomcat 8.5.76 or later

History:
2022-05-12 Original advisory

Credit:
This issue was identified by the Apache Tomcat security team.

References:
[1] https://tomcat.apache.org/security-9.html
[2] https://tomcat.apache.org/security-8.html

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

Re: mod_jk interference with ErrorDocument/Alias on HEAD request

[Stefan Mayr]

Hi,

i created a bugzilla entry 
(https://bz.apache.org/bugzilla/show_bug.cgi?id=65901) and included a 
first attempt to patch this issue.


Am 12.02.2022 um 14:24 schrieb Stefan Mayr:

Hello Tomcat users,

this week we were debugging a strange connection issue which I tracked 
down to an interference between Apache httpd and mod_jk.


For the full picture, the infrastructure setup contains

1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk
3. a Tomcat mit AJP-Connector

We have an application doing many different HEAD requests against an 
application running in the Tomcat server. The requests contain an 
Authorization header for Basic authentication. Expected response is a 
HTTP 200 OK or HTTP 401 if this particular user is not allowed to access 
that ressource. Because this is a HEAD request there must not be a 
response body according to RFC 2616.


If there is a response body in the response to the HEAD request our 
loadbalancer does strange things: aborts the connection if the clients 
uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its 
own which we might have to solve with the vendor.


Now comes the point where I need your help. We have a httpd 
configuration with mod_jk which generates these invalid response bodies 
on HEAD requests. I have a gut feeling this could be a bug with mod_jk.


For demonstration purpose i created a minimal demo app which only is a 
WEB-INF/web.xml


https://jakarta.ee/xml/ns/jakartaee;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
   https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
   version="5.0">
     
     
     Login
     /*
     
     
     manager
     
     
     
     manager
     
     
     BASIC
     


Then I place a JkMount in my Apache httpd configuration (+ minimal 
worker.properties):


JkMount /demo/* ajp13_worker

Testing this with curl works like expected:

root@1ae8973f1b6b:~# curl -I -v localhost/demo/
*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
 > HEAD /demo/ HTTP/1.1
 > Host: localhost
 > User-Agent: curl/7.68.0
 > Accept: */*
 >
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 401
HTTP/1.1 401 401
< Date: Sat, 12 Feb 2022 12:57:33 GMT
Date: Sat, 12 Feb 2022 12:57:33 GMT
< Server: Apache/2.4.41 (Ubuntu)
Server: Apache/2.4.41 (Ubuntu)
< Cache-Control: private
Cache-Control: private
< WWW-Authenticate: Basic realm="Authentication required"
WWW-Authenticate: Basic realm="Authentication required"
< Content-Language: en
Content-Language: en
< Content-Type: text/html;charset=utf-8
Content-Type: text/html;charset=utf-8

<
* Connection #0 to host localhost left intact

But our default setup always includes custom error pages:

Alias /error/ "/usr/share/apache2/error/"
ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var

If both of those lines are added this results in a response body for the 
HEAD request.


root@1ae8973f1b6b:~# curl -I -v localhost/demo/
*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
 > HEAD /demo/ HTTP/1.1
 > Host: localhost
 > User-Agent: curl/7.68.0
 > Accept: */*
 >
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 401
HTTP/1.1 401 401
< Date: Sat, 12 Feb 2022 12:56:27 GMT
Date: Sat, 12 Feb 2022 12:56:27 GMT
< Server: Apache/2.4.41 (Ubuntu)
Server: Apache/2.4.41 (Ubuntu)
< Cache-Control: private
Cache-Control: private
< WWW-Authenticate: Basic realm="Authentication required"
WWW-Authenticate: Basic realm="Authentication required"
< Content-Language: en
Content-Language: en
< Content-Type: text/html;charset=utf-8
Content-Type: text/html;charset=utf-8

<
* Excess found: excess = 589 url = /demo/ (zero-length body)
* Connection #0 to host localhost left intact

Checking with tcpdump on port 8009 we see the expected response without 
a body from the Tomcat AJP connector. The tcpdump von port 80 reveals 
httpd is adding the configured ErrorDocument as response body.


If we comment out either the Alias or ErrorDocument directive the 
response is correct again.


Doing similar tests with CGI/PHP applications always show the correct 
response without a response body. This only affects requests which use 
mod_jk.


So far I could reproduce this on SLES12 SP5 and SLES15 SP3 running 
Apache httpd 2.4.51 and a self compile mod_jk 1.2.46 (same with the 
included mod_jk 1.2.43) at work. At home the same happens on a stock 
openSUSE Leap 15.3 with Apache httpd 2.4.51 and mod_jk 1.2.43 as well as 
on Ubuntu 20.04 with httpd 2.4.41 and mod_jk 1.2.

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Stefan,

the debug output of mod_jk shows at least which route the request is going:
[info] jk_handler::mod_jk.c (2968): No body with status=401 for 
worker=ajp13_worker

So it looks like that the code 
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973
Returns 401 to the caller.

Apache sets the flag header_only when receiving a HEAD-Request. This flag can 
also be seen in the mod_jk sources.

The  "Excess" error is produces by curl: 
https://fossies.org/linux/curl/lib/transfer.c

Dunno if this info helps much.

Greetings, Thomas

-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Dienstag, 15. Februar 2022 14:26
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello Thomas,

Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
> Hello Stefan,
> 
> by spec / RFC, a HEAD request is not allowed to return any body.
> 
> Greetings,
> Thomas

This is true and that is why i'm writing to this list. In the described case 
mod_jk returns a response body although it should not (at least i think mod_jk 
is somehow responsible for that)

> -Ursprüngliche Nachricht-
> Von: Stefan Mayr 
> Gesendet: Montag, 14. Februar 2022 23:07
> An: users@tomcat.apache.org
> Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD 
> request
> 
> Hello again,
> 
> a self-compiled mod_jk 1.2.48 shows the same issue.
> 
> Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
>> Hi,
>>
>> looking at the source code
>> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
>> 0/mod_jk.c#L2954#L2973
>> I did some more testing:
>>
>> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
>> Variant 2: JkMount /demo/* ajp13_worker
>>
>> ignoring what variant 2 changes for regular request: reading the 
>> source comment my understanding is, that for both variants a HEAD 
>> request (by definition must have an empty response body) should let 
>> Apache httpd handle the error code.
>>
>> But the return code for jk_handler looks different:
>>
>> Variant 1: s.http_response_status
>> Variant 2: r->status
> 
> Although this looks different on the first glance it seems to be the same.
> 
>> The response only seems correct for variant 1 - which is configured 
>> to let Apache httpd handle all responses for status codes >= 401. For 
>> variant 2 mod_jk seems to handle the response itself - contrary to 
>> what the comment explains.
> 
> This leads to the next assumption, that whenever there is a special handling 
> for use_server_errors there should be something similar for the case with an 
> empty/non-existing response body.
> 
> There is
> https://github.com/apache/tomcat-connectors/blob/main/native/common/jk
> _ajp_common.c#L1991#L1993 with no corresponding (pseudo) code like
> 
>   if (!r->something_like_bodyct && r->http_response_status >= 
> JK_HTTP_BAD_REQUEST){
>   r->response_blocked = JK_TRUE;
>   }
> 
> Adding code like this (sorry, i could not find out how to determine if there 
> is a response body) fixes the issue with the wrong response body for a HEAD 
> request. But we miss the WWW-Authenticate header now.
> 
> Digging further we find
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L331#L353 which has a special treatment for 401 HTTP 
> Unauthorized. But again, only for use_server_errors.
> 
> This should be fixable by extending the condition like this
> 
>   if ((s->extension.use_server_error_pages &&
>   status >= s->extension.use_server_error_pages) ||
>   (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
> 
> 
> But the WWW-Authenticate header is still missing. So i'm wrong, again.
> Although it feels like i'm close.
> 
>> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>>> Hello Tomcat users,
>>>
>>> this week we were debugging a strange connection issue which I 
>>> tracked down to an interference between Apache httpd and mod_jk.
>>>
>>> For the full picture, the infrastructure setup contains
>>>
>>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat 
>>> mit AJP-Connector
>>>
>>> We have an application doing many different HEAD requests against an 
>>> application running in the Tomcat server. The requests contain an 
>>> Authorization header for Basic authentication. Expected resp

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Stefan,
Now I got it. Thanks for the clarification :)

-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Dienstag, 15. Februar 2022 14:26
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello Thomas,

Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
> Hello Stefan,
> 
> by spec / RFC, a HEAD request is not allowed to return any body.
> 
> Greetings,
> Thomas

This is true and that is why i'm writing to this list. In the described case 
mod_jk returns a response body although it should not (at least i think mod_jk 
is somehow responsible for that)

> -Ursprüngliche Nachricht-
> Von: Stefan Mayr 
> Gesendet: Montag, 14. Februar 2022 23:07
> An: users@tomcat.apache.org
> Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD 
> request
> 
> Hello again,
> 
> a self-compiled mod_jk 1.2.48 shows the same issue.
> 
> Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
>> Hi,
>>
>> looking at the source code
>> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
>> 0/mod_jk.c#L2954#L2973
>> I did some more testing:
>>
>> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
>> Variant 2: JkMount /demo/* ajp13_worker
>>
>> ignoring what variant 2 changes for regular request: reading the 
>> source comment my understanding is, that for both variants a HEAD 
>> request (by definition must have an empty response body) should let 
>> Apache httpd handle the error code.
>>
>> But the return code for jk_handler looks different:
>>
>> Variant 1: s.http_response_status
>> Variant 2: r->status
> 
> Although this looks different on the first glance it seems to be the same.
> 
>> The response only seems correct for variant 1 - which is configured 
>> to let Apache httpd handle all responses for status codes >= 401. For 
>> variant 2 mod_jk seems to handle the response itself - contrary to 
>> what the comment explains.
> 
> This leads to the next assumption, that whenever there is a special handling 
> for use_server_errors there should be something similar for the case with an 
> empty/non-existing response body.
> 
> There is
> https://github.com/apache/tomcat-connectors/blob/main/native/common/jk
> _ajp_common.c#L1991#L1993 with no corresponding (pseudo) code like
> 
>   if (!r->something_like_bodyct && r->http_response_status >= 
> JK_HTTP_BAD_REQUEST){
>   r->response_blocked = JK_TRUE;
>   }
> 
> Adding code like this (sorry, i could not find out how to determine if there 
> is a response body) fixes the issue with the wrong response body for a HEAD 
> request. But we miss the WWW-Authenticate header now.
> 
> Digging further we find
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L331#L353 which has a special treatment for 401 HTTP 
> Unauthorized. But again, only for use_server_errors.
> 
> This should be fixable by extending the condition like this
> 
>   if ((s->extension.use_server_error_pages &&
>   status >= s->extension.use_server_error_pages) ||
>   (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
> 
> 
> But the WWW-Authenticate header is still missing. So i'm wrong, again.
> Although it feels like i'm close.
> 
>> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>>> Hello Tomcat users,
>>>
>>> this week we were debugging a strange connection issue which I 
>>> tracked down to an interference between Apache httpd and mod_jk.
>>>
>>> For the full picture, the infrastructure setup contains
>>>
>>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat 
>>> mit AJP-Connector
>>>
>>> We have an application doing many different HEAD requests against an 
>>> application running in the Tomcat server. The requests contain an 
>>> Authorization header for Basic authentication. Expected response is 
>>> a HTTP 200 OK or HTTP 401 if this particular user is not allowed to 
>>> access that ressource. Because this is a HEAD request there must not 
>>> be a response body according to RFC 2616.
>>>
>>> If there is a response body in the response to the HEAD request our 
>>> loadbalancer does strange things: aborts the connection if the 
>>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an 
>>> issue on its own which we might have t

Re: mod_jk interference with ErrorDocument/Alias on HEAD request

[Stefan Mayr]

Hello Thomas,

Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello Stefan,

by spec / RFC, a HEAD request is not allowed to return any body.

Greetings,
Thomas


This is true and that is why i'm writing to this list. In the described 
case mod_jk returns a response body although it should not (at least i 
think mod_jk is somehow responsible for that)



-Ursprüngliche Nachricht-
Von: Stefan Mayr 
Gesendet: Montag, 14. Februar 2022 23:07
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello again,

a self-compiled mod_jk 1.2.48 shows the same issue.

Am 13.02.2022 um 18:37 schrieb Stefan Mayr:

Hi,

looking at the source code
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
0/mod_jk.c#L2954#L2973
I did some more testing:

Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
Variant 2: JkMount /demo/* ajp13_worker

ignoring what variant 2 changes for regular request: reading the
source comment my understanding is, that for both variants a HEAD
request (by definition must have an empty response body) should let
Apache httpd handle the error code.

But the return code for jk_handler looks different:

Variant 1: s.http_response_status
Variant 2: r->status


Although this looks different on the first glance it seems to be the same.


The response only seems correct for variant 1 - which is configured to
let Apache httpd handle all responses for status codes >= 401. For
variant 2 mod_jk seems to handle the response itself - contrary to
what the comment explains.


This leads to the next assumption, that whenever there is a special handling 
for use_server_errors there should be something similar for the case with an 
empty/non-existing response body.

There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like

  if (!r->something_like_bodyct && r->http_response_status >= 
JK_HTTP_BAD_REQUEST){
  r->response_blocked = JK_TRUE;
  }

Adding code like this (sorry, i could not find out how to determine if there is 
a response body) fixes the issue with the wrong response body for a HEAD 
request. But we miss the WWW-Authenticate header now.

Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only for 
use_server_errors.

This should be fixable by extending the condition like this

  if ((s->extension.use_server_error_pages &&
  status >= s->extension.use_server_error_pages) ||
  (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {


But the WWW-Authenticate header is still missing. So i'm wrong, again.
Although it feels like i'm close.


Am 12.02.2022 um 14:24 schrieb Stefan Mayr:

Hello Tomcat users,

this week we were debugging a strange connection issue which I
tracked down to an interference between Apache httpd and mod_jk.

For the full picture, the infrastructure setup contains

1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
mit AJP-Connector

We have an application doing many different HEAD requests against an
application running in the Tomcat server. The requests contain an
Authorization header for Basic authentication. Expected response is a
HTTP 200 OK or HTTP 401 if this particular user is not allowed to
access that ressource. Because this is a HEAD request there must not
be a response body according to RFC 2616.

If there is a response body in the response to the HEAD request our
loadbalancer does strange things: aborts the connection if the
clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an
issue on its own which we might have to solve with the vendor.

Now comes the point where I need your help. We have a httpd
configuration with mod_jk which generates these invalid response
bodies on HEAD requests. I have a gut feeling this could be a bug
with mod_jk.

For demonstration purpose i created a minimal demo app which only is
a WEB-INF/web.xml  https://jakarta.ee/xml/ns/jakartaee;
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee

https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;

    version="5.0">
  
  
  Login
  /*
  
  
  manager
  
  
  
  manager
  
  
  BASIC
  


Then I place a JkMount in my Apache httpd configuration (+ minimal
worker.properties):

JkMount /demo/* ajp13_worker

Testing this with curl works like

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Stefan,

by spec / RFC, a HEAD request is not allowed to return any body.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Montag, 14. Februar 2022 23:07
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello again,

a self-compiled mod_jk 1.2.48 shows the same issue.

Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
> Hi,
> 
> looking at the source code
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L2954#L2973
> I did some more testing:
> 
> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
> Variant 2: JkMount /demo/* ajp13_worker
> 
> ignoring what variant 2 changes for regular request: reading the 
> source comment my understanding is, that for both variants a HEAD 
> request (by definition must have an empty response body) should let 
> Apache httpd handle the error code.
> 
> But the return code for jk_handler looks different:
> 
> Variant 1: s.http_response_status
> Variant 2: r->status

Although this looks different on the first glance it seems to be the same.

> The response only seems correct for variant 1 - which is configured to 
> let Apache httpd handle all responses for status codes >= 401. For 
> variant 2 mod_jk seems to handle the response itself - contrary to 
> what the comment explains.

This leads to the next assumption, that whenever there is a special handling 
for use_server_errors there should be something similar for the case with an 
empty/non-existing response body.

There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like

 if (!r->something_like_bodyct && r->http_response_status >= 
JK_HTTP_BAD_REQUEST){
 r->response_blocked = JK_TRUE;
 }

Adding code like this (sorry, i could not find out how to determine if there is 
a response body) fixes the issue with the wrong response body for a HEAD 
request. But we miss the WWW-Authenticate header now.

Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only for 
use_server_errors.

This should be fixable by extending the condition like this

 if ((s->extension.use_server_error_pages &&
 status >= s->extension.use_server_error_pages) ||
 (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {


But the WWW-Authenticate header is still missing. So i'm wrong, again. 
Although it feels like i'm close.

> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>> Hello Tomcat users,
>>
>> this week we were debugging a strange connection issue which I 
>> tracked down to an interference between Apache httpd and mod_jk.
>>
>> For the full picture, the infrastructure setup contains
>>
>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat 
>> mit AJP-Connector
>>
>> We have an application doing many different HEAD requests against an 
>> application running in the Tomcat server. The requests contain an 
>> Authorization header for Basic authentication. Expected response is a 
>> HTTP 200 OK or HTTP 401 if this particular user is not allowed to 
>> access that ressource. Because this is a HEAD request there must not 
>> be a response body according to RFC 2616.
>>
>> If there is a response body in the response to the HEAD request our 
>> loadbalancer does strange things: aborts the connection if the 
>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an 
>> issue on its own which we might have to solve with the vendor.
>>
>> Now comes the point where I need your help. We have a httpd 
>> configuration with mod_jk which generates these invalid response 
>> bodies on HEAD requests. I have a gut feeling this could be a bug 
>> with mod_jk.
>>
>> For demonstration purpose i created a minimal demo app which only is 
>> a WEB-INF/web.xml  > xmlns="https://jakarta.ee/xml/ns/jakartaee;
>>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
>>
>> https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
>>    version="5.0">
>>  
>>  
>>  Login
>>  /*
>>  
>>  
>>  manager
>>  
>>  
>>

Re: mod_jk interference with ErrorDocument/Alias on HEAD request

[Stefan Mayr]

Hello again,

a self-compiled mod_jk 1.2.48 shows the same issue.

Am 13.02.2022 um 18:37 schrieb Stefan Mayr:

Hi,

looking at the source code 
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973 
I did some more testing:


Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
Variant 2: JkMount /demo/* ajp13_worker

ignoring what variant 2 changes for regular request: reading the source 
comment my understanding is, that for both variants a HEAD request (by 
definition must have an empty response body) should let Apache httpd 
handle the error code.


But the return code for jk_handler looks different:

Variant 1: s.http_response_status
Variant 2: r->status


Although this looks different on the first glance it seems to be the same.

The response only seems correct for variant 1 - which is configured to 
let Apache httpd handle all responses for status codes >= 401. For 
variant 2 mod_jk seems to handle the response itself - contrary to what 
the comment explains.


This leads to the next assumption, that whenever there is a special 
handling for use_server_errors there should be something similar for the 
case with an empty/non-existing response body.


There is 
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993 
with no corresponding (pseudo) code like


if (!r->something_like_bodyct && r->http_response_status >= 
JK_HTTP_BAD_REQUEST){

r->response_blocked = JK_TRUE;
}

Adding code like this (sorry, i could not find out how to determine if 
there is a response body) fixes the issue with the wrong response body 
for a HEAD request. But we miss the WWW-Authenticate header now.


Digging further we find 
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353 
which has a special treatment for 401 HTTP Unauthorized. But again, only 
for use_server_errors.


This should be fixable by extending the condition like this

if ((s->extension.use_server_error_pages &&
status >= s->extension.use_server_error_pages) ||
(!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {


But the WWW-Authenticate header is still missing. So i'm wrong, again. 
Although it feels like i'm close.



Am 12.02.2022 um 14:24 schrieb Stefan Mayr:

Hello Tomcat users,

this week we were debugging a strange connection issue which I tracked 
down to an interference between Apache httpd and mod_jk.


For the full picture, the infrastructure setup contains

1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk
3. a Tomcat mit AJP-Connector

We have an application doing many different HEAD requests against an 
application running in the Tomcat server. The requests contain an 
Authorization header for Basic authentication. Expected response is a 
HTTP 200 OK or HTTP 401 if this particular user is not allowed to 
access that ressource. Because this is a HEAD request there must not 
be a response body according to RFC 2616.


If there is a response body in the response to the HEAD request our 
loadbalancer does strange things: aborts the connection if the clients 
uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its 
own which we might have to solve with the vendor.


Now comes the point where I need your help. We have a httpd 
configuration with mod_jk which generates these invalid response 
bodies on HEAD requests. I have a gut feeling this could be a bug with 
mod_jk.


For demonstration purpose i created a minimal demo app which only is a 
WEB-INF/web.xml


https://jakarta.ee/xml/ns/jakartaee;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
   
https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;

   version="5.0">
 
 
 Login
 /*
 
 
 manager
 
 
 
 manager
 
 
 BASIC
 


Then I place a JkMount in my Apache httpd configuration (+ minimal 
worker.properties):


JkMount /demo/* ajp13_worker

Testing this with curl works like expected:

root@1ae8973f1b6b:~# curl -I -v localhost/demo/
*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
 > HEAD /demo/ HTTP/1.1
 > Host: localhost
 > User-Agent: curl/7.68.0
 > Accept: */*
 >
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 401
HTTP/1.1 401 401
< Date: Sat, 12 Feb 2022 12:57:33 GMT
Date: Sat, 12 Feb 2022 12:57:33 GMT
< Server: Apache/2.4.41 (Ubuntu)
Server: Apache/2.4.41 (Ubuntu)
< Cache-Control: private
Cache-Control: private
< WWW-Authenticate: Basic realm