Graham,
On 11/29/23 05:01, Graham Leggett wrote:
On 28 Nov 2023, at 21:10, Graham Leggett <minf...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
