Exception in HttpRequestHandlingEndpointSupport for incoming DELETE request without body

[gekoukoul]

In what version(s) of Spring Integration are you seeing this issue?

In 5.5.15

Describe the bug

When a DELETE HTTP request without body is incoming, the following exception occurs:

org.springframework.messaging.MessagingException: Could not convert request: no suitable HttpMessageConverter found for expected type [omitted.for.brevity] and content type [application/octet-stream]
	at org.springframework.integration.http.inbound.HttpRequestHandlingEndpointSupport.extractRequestBody(HttpRequestHandlingEndpointSupport.java:538)
	at org.springframework.integration.http.inbound.HttpRequestHandlingEndpointSupport.prepareRequestEntity(HttpRequestHandlingEndpointSupport.java:497)
	at org.springframework.integration.http.inbound.HttpRequestHandlingMessagingGateway.handleRequest(HttpRequestHandlingMessagingGateway.java:109)
	at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:52)

Expected behaviour
DELETE request should not require a message converter if there is no request body present.

A bit more analysis
From the RFC perspective, which is a bit vague and does not dictate that a DELETE request must have a request body, there are no defined body semantics.
However, the following code in HttpRequestHandlingEndpointSupport require DELETE requests to have body, so it fails when it sees there's no content-type along with the corresponding request body for a supported message converter to handle:

protected RequestEntity<Object> prepareRequestEntity(ServletServerHttpRequest request) throws IOException {
		Object requestBody = null;
		if (isReadable(request.getMethod())) {
			requestBody = extractRequestBody(request);
		}

		return new RequestEntity<>(requestBody, request.getHeaders(), request.getMethod(), request.getURI());
	}

[artembilan]

I'm not sure what is your omitted.for.brevity, but since you don't expect body for that DELETE request, why do you configure requestPayloadType then on your HTTP endpoint?

According to that RFC and this SO discussion, it looks like body in this DELETE request is optional.
So, we really cannot disallow it as we do for other non-content requests:

	/**
	 * Checks if the request has a readable body (not a GET, HEAD, or OPTIONS request).
	 * @param httpMethod the HTTP method to check
	 * @return true or false if HTTP request can contain the body
	 */
	protected static boolean isReadable(@Nullable HttpMethod httpMethod) {
		return httpMethod != null && !(CollectionUtils.containsInstance(NON_READABLE_BODY_HTTP_METHODS, httpMethod));
	}

I suggest you to remove requestPayloadType and leave that application/octet-stream content-type as is.
Then HttpRequestHandlingEndpointSupport falls back to byte[] for payload type and ByteArrayHttpMessageConverter would kick in.
If there is no body in the request, the payload will be just byte[0].
The point is there there is no way to know that body is not present:

	/**
	 * Return the body of the message as an input stream.
	 * @return the input stream body (never {@code null})
	 * @throws IOException in case of I/O errors
	 */
	InputStream getBody() throws IOException;

Never null is a clue.

[gekoukoul]

Hi @artembilan,
Thank you for your answer.
There is an IntegrationFlowBuilder that takes care the creation of the HTTP inbound flows, for each job of type WEB, where a job is something like a controller method.
So, for the HTTP flows, the setup is centralized and each Web job implements a job execution interface of type and requires the payload type to be defined (the one that in the example which is omitted for brevity).
I will try and find a way to work around this for this matter.

However, what bugs me is in a 2022 updated RFC, being mentioned in this SO thread, which in plain terms says that if a request method has no defined semantics for body, is not obliged to accept it and should ignore it. More specifically for DELETE (but also for GET and HEAD):

A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

Therefore, to my understanding at least, since the updated RFC suggests the same guidelines for request body interoperability for GET, HEAD and DELETE methods, maybe also DELETE shall belong to non-readable body HTTP methods' list.

[artembilan]

OK. You have convinced me.
I'll make this DELETE as non-readable method as well.

[muneebahmed]

is there a way to enable sending a body with delete method without having to downgrade to 6.2.0? @artembilan

[artembilan]

No, there is no way to disable that option.
According to RFC we all agreed upon, your server side has to be fixed to not accept body in DELETE request.
You both with client should revise the logic into some other HTTP method if body is required.