You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Graham Leggett <mi...@sharp.fm.INVALID> on 2023/11/27 20:09:26 UTC
400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 29 Nov 2023, at 07:18, Thomas Hoffmann (Speed4Trade GmbH) <Th...@speed4trade.com.INVALID> 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?
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello Graham,
> -----Ursprüngliche Nachricht-----
> Von: Graham Leggett <mi...@sharp.fm.INVALID>
> Gesendet: Dienstag, 28. November 2023 20:12
> An: Tomcat Users List <us...@tomcat.apache.org>
> 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 <ch...@christopherschultz.net>
> 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?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Graham,
On 11/29/23 05:01, Graham Leggett wrote:
> On 28 Nov 2023, at 21:10, Graham Leggett <mi...@sharp.fm.INVALID> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 28 Nov 2023, at 21:10, Graham Leggett <mi...@sharp.fm.INVALID> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 28 Nov 2023, at 19:11, Graham Leggett <mi...@sharp.fm.INVALID> 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?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Graham,
On 11/28/23 14:11, Graham Leggett wrote:
> On 28 Nov 2023, at 18:42, Christopher Schultz <ch...@christopherschultz.net> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 28 Nov 2023, at 18:42, Christopher Schultz <ch...@christopherschultz.net> 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?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Graham,
On 11/28/23 12:12, Graham Leggett wrote:
> On 28 Nov 2023, at 09:41, Mark Thomas <ma...@apache.org> 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:
>
> <Valve className="org.apache.catalina.valves.ErrorReportValve"
> showReport="true"
> showServerInfo="true" />
>
> Instead of rendering the exception in the output, we get the following:
>
> <!doctype html><html lang="en"><head><title>HTTP Status 500 – Internal Server Error</title><style type="text/css">body {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;}</style></head><body><h1>HTTP Status 500 – Internal Server Error</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> Internal Server Error</p><p><b>Description</b> The server encountered an unexpected condition that prevented it from fulfilling the request.</p><hr class="line" /><h3>Apache Tomcat/9.0.65</h3></body></html>
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 28 Nov 2023, at 09:41, Mark Thomas <ma...@apache.org> 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:
<Valve className="org.apache.catalina.valves.ErrorReportValve"
showReport="true"
showServerInfo="true" />
Instead of rendering the exception in the output, we get the following:
<!doctype html><html lang="en"><head><title>HTTP Status 500 – Internal Server Error</title><style type="text/css">body {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;}</style></head><body><h1>HTTP Status 500 – Internal Server Error</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> Internal Server Error</p><p><b>Description</b> The server encountered an unexpected condition that prevented it from fulfilling the request.</p><hr class="line" /><h3>Apache Tomcat/9.0.65</h3></body></html>
Is this a known problem?
Regards,
Graham
—
Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org