[issue2551360] Processing leftover post data when using GET request

New submission from John Rouillard:

Using the following CURL command:

   curl -vv -n -p -X GET --header "Content-Type: application/xml"   \
         --header "Accept: application/json" \
         --header 'If-Match: "3cda6983cac9eb51266b6e418141c53d"' \
         --data-urlencode '@op=add' \
         --header "Origin: https://example.net" \
     "https://example.net/demo/rest/data/keyword?name=sv&@verbose=2"

I see the following logged:

443544 127.0.0.1 - - [17/Jul/2024 23:12:04] "GET /demo/rest/data/keyword?
name=sv&@verbose=2 HTTP/1.1" 200 -
443544 127.0.0.1 - - [17/Jul/2024 23:12:04] code 400, message Bad request syntax 
('@op=add')
443544 127.0.0.1 - - [17/Jul/2024 23:12:04] "@op=add" 400 -

So it looks like curl is sending the data @op=add and a GET request isn't draining the
input. So Roundup (with roundup-server behind a proxy) consumes the initial GET 
header line, routes using it. Then when BaseRequestHandler.handle gets
called again, it gets the left over content on the socket.

What should happen here? I don't think it is a security issue as the only
value recognized by handle() at that point is an HTTP header.

AFAICT it just reports an error that might be useful to find poorly behaving
rest clients.

So maybe nothing has to happen?

Thoughts?

(I generated the curl command by mucking with a PATCH command created for
a different purpose and didn't feel like getting rid of the other settings. So sort
of a manual fuzzer.)

----------
components: Web interface
messages: 8114
nosy: rouilj, schlatterbeck
severity: normal
status: new
title: Processing leftover post data when using GET request
type: behavior

_________________________________________________
Roundup tracker <[email protected]>
<https://issues.roundup-tracker.org/issue2551360>
_________________________________________________