Skip to content

Unexpected behavior: GET converted to POST without body when @RequestParam is missing in OpenFeign #2872

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dkswnkk opened this issue Apr 29, 2025 · 0 comments

Comments

@dkswnkk
Copy link

dkswnkk commented Apr 29, 2025

Description

When using OpenFeign, I originally intended to send a query parameter with a GET request.

For example:

@FeignClient(name = "test-client")
public interface TestClient {

    @GetMapping("/test")
    DataRs getData(String query); // `query` has a non-null value
}

My goal was to send the request like:

GET /test?query=value

What actually happened

  • Because the query parameter was not annotated with @RequestParam, OpenFeign treated it as a request body.
  • However, since GET requests should not have a body, the internal HTTP client (HttpURLConnection) automatically changed the method to POST at runtime:
// https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1326
if (method.equals("GET")) {
    method = "POST"; // Backward compatibility
}

Image

  • Even though the HTTP method was changed to POST, the body was empty (Content-Length: 0).

  • So:

    • The request became POST,
    • But no request body was actually sent,
    • And there was no error or warning during Feign request generation.

Important note

  • When I explicitly add @RequestParam, everything works correctly:
@FeignClient(name = "test-client")
public interface TestClient {

    @GetMapping("/test")
    DataRs getData(@RequestParam String query); // ✅ Works as intended: GET with query string
}
  • So I fully understand that @RequestParam is needed when sending query parameters.

Suggestion

Given this behavior, I would like to ask:

Wouldn't it be more appropriate for OpenFeign to throw a warning or an error early — for example, during startup or client creation — if it detects a GET method that has parameters but is missing annotations like @RequestParam or @SpringQueryMap?

In many cases, when a developer defines a GET method with parameters, the expected behavior is to send those as query parameters, not as a body.
If the annotation is missing, and OpenFeign ends up silently treating the request as a POST with an empty body, it can easily cause confusion, unexpected behavior, or even runtime issues under strict API gateways or HTTP method validation rules.

Additionally, when I checked the client-side logs, it still showed the request being sent as a GET,
but when I confirmed with the receiving server, the request was actually received as a POST.
This discrepancy made it very difficult to quickly identify and debug the issue.

In my local logging, using the following RequestInterceptor:

@Slf4j
@Configuration
public class FeignLoggingInterceptorConfig {

    @Bean
    public RequestInterceptor requestLoggingInterceptor() {
        return template -> log.info("[Feign Request] method={}, url={}, body={}",
                                    template.method(), template.url(), template.body() != null ? new String(template.body()) : "null");
    }
}

the request was logged as being sent with the GET method.
However, on the server side that received the API request, it was actually received as a POST request.

I fully understand that @RequestParam is necessary when intending to send query parameters.
However, it seems like providing an early warning in cases where a GET method's parameters would be treated incorrectly could greatly help developers catch such issues before runtime.

If there is a particular reason why OpenFeign currently does not enforce this behavior — for example, to preserve flexibility or for backward compatibility — I would be happy to understand that as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant