Bug 69031 - Not Implemented 501 by truncated method name
Summary: Not Implemented 501 by truncated method name
Status: RESOLVED INVALID
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Servlet (show other bugs)
Version: 9.0.86
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-21 18:48 UTC by Pepe
Modified: 2024-05-24 18:43 UTC (History)
0 users



Attachments
truncate request-dumper filter. (317.49 KB, application/octet-stream)
2024-05-22 09:32 UTC, Pepe
Details
tcpdump ASCII (712.12 KB, text/plain)
2024-05-22 09:34 UTC, Pepe
Details
pcap file (337.84 KB, application/octet-stream)
2024-05-22 14:16 UTC, Pepe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pepe 2024-05-21 18:48:45 UTC
There is a problem in tomcat, but unfortunately I don't know exactly where the problem occurs. Whether the connector or the web servlet is responsible.
I am calling many different POST, GET and DELETE requests in parallel using httpclient 5.3.1. In some cases a 501 (Not Implemented) code is returned.

10.81.234.21 - - [21/May/2024:14:59:42 +0000] "ST /rest/api/v1/content HTTP/1.1" 501 727

The first two letters of the rest metode are always missing, or the method is completely empty.
I have recorded the network traffic with tcpdump and seen in wireshark that a "POST","GET","PUT" or "DELETE" arrives at tomcat from the client.
In the tomcat request dump filter, however, the method is shown as  
 method=ST instead of method=POST
I therefore assume that the method name is garbled before the filter.
This occurs once with approx. 5000 calls and only if the calls are sent to the tomcat in parallel at short intervals.
Comment 1 Mark Thomas 2024-05-22 07:07:41 UTC
Please provide the tcpdump for a connection that exhibits this behaviour. We need to see all the traffic for that connection (but only that connection).
Comment 2 Pepe 2024-05-22 09:32:02 UTC
Created attachment 39727 [details]
truncate request-dumper filter.

This is the output of the request-dump filter
Comment 3 Pepe 2024-05-22 09:34:31 UTC
Created attachment 39728 [details]
tcpdump ASCII

This is the tcpdump snippet, with the truncated method "ST" instead of "POST"
Comment 4 Pepe 2024-05-22 09:35:59 UTC
I have attached the tcpdump and request dumper output to the ticket
Comment 5 Mark Thomas 2024-05-22 12:48:19 UTC
We'll need to see the raw pcap file for the tcpdump. The text version hides all sorts of key information - such as line endings.
Comment 6 Pepe 2024-05-22 14:16:03 UTC
Created attachment 39737 [details]
pcap file

This is the pcap file with the post request that leads to the 501 error. The user data has already been truncated by tcpdump, as otherwise the file would have become extremely large. I have masked the auth field. I hope that this file is sufficient for troubleshooting.
Comment 7 Pepe 2024-05-22 14:16:21 UTC
Add pcap File
Comment 8 Mark Thomas 2024-05-22 17:49:47 UTC
The provided pcap file is insufficient.

1. It needs to include at least the complete request and response before the request that fails.

2. The missing bytes in the response body are going to make analysis significantly more difficult.

Masking sensitive information is fine as long at the number of bytes are not changed.
Comment 9 Pepe 2024-05-22 18:38:49 UTC
The zipped pcap file has a size of 15MB. So I am not able to upload it as attachment. What alternative I have ?
Comment 10 Mark Thomas 2024-05-22 19:05:14 UTC
Can you upload it to Google Drive / One Drive / etc? If you want to send me the link privately, feel free.
Comment 11 Mark Thomas 2024-05-23 09:35:28 UTC
You have a broken client.

Looking at the full pcap file provided off-line, the request before the request that fails declares a content length of 68350 bytes but only sends 68348 bytes.

Since HTTP pipe-lining is being used (multiple requests over a single connection) the first two bytes of what the client considers to be the next request are used to complete the request body of the previous request.

That leaves a request line that starts "LETE..." rather than "DELETE..." which Tomcat correctly rejects.

You need to speak to the provider of your client to figure out why the content length declared is not the content-length sent.
Comment 12 Pepe 2024-05-23 10:54:44 UTC
Thank you very much for the analysis. I will now take a closer look at httpclient5. So the error remains in the apache family :-)
Comment 13 Pepe 2024-05-24 18:43:51 UTC
I have found the error. Several threads have edited and overwritten an image at the same time. This resulted in this effect when the exact image was uploaded via put. So also no problem of httpclient5.
Usually the problem is in front of the computer :-)