Spring Boot
request target
invalid character error
troubleshooting
web application development

Invalid character found in the request target in spring boot

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

The Spring Boot error Invalid character found in the request target typically originates from the embedded servlet container (often Tomcat) rejecting an HTTP request line that violates RFC rules. The root cause is usually an unencoded URL containing characters like spaces, {}, [], |, or raw JSON fragments in query parameters. Although developers often try to relax server parsing rules immediately, the safer first fix is to encode client URLs correctly.

Understanding where the invalid character enters the request path is key. If you only patch server settings, you may hide bad client behavior and create security or interoperability issues.

Core Sections

1. Recognize common invalid request patterns

Bad examples:

text
GET /search?q={"name":"john"} HTTP/1.1
GET /files/my report.pdf HTTP/1.1
GET /api?ids=[1,2,3] HTTP/1.1

These contain characters that must be percent-encoded in URLs.

2. Encode query/path components on the client

Java client example with Spring utilities:

java
1import org.springframework.web.util.UriComponentsBuilder;
2
3String uri = UriComponentsBuilder.fromPath("/search")
4    .queryParam("q", "{\"name\":\"john\"}")
5    .build()
6    .encode()
7    .toUriString();

Use builders instead of string concatenation for URLs.

3. Validate incoming parameters in controllers

Even with correct encoding, validate expected formats.

java
1@GetMapping("/search")
2public ResponseEntity<?> search(@RequestParam String q) {
3    if (q.length() > 2000) {
4        return ResponseEntity.badRequest().body("query too long");
5    }
6    return ResponseEntity.ok(service.search(q));
7}

Validation prevents malformed or abusive inputs from propagating.

4. Relax container settings only when justified

Tomcat allows optional relaxed chars configuration, but use cautiously.

properties
server.tomcat.relaxed-query-chars=|,{,},[,]
server.tomcat.relaxed-path-chars=|,{,},[,]

Only permit characters your application genuinely needs, and document why.

5. Diagnose with access logs and proxies

Reverse proxies or load balancers may alter or reject URLs before Spring sees them. Compare logs across layers.

bash
# Example check in proxy logs
grep "400" /var/log/nginx/access.log

Pinpointing the failing hop avoids incorrect fixes in the wrong component.

6. Prefer POST for complex payloads

If query strings carry structured data, move payload to request body.

java
1@PostMapping("/search")
2public ResponseEntity<?> search(@RequestBody SearchRequest request) {
3    return ResponseEntity.ok(service.search(request));
4}

This avoids URL encoding complexity and request-line limits.

7. Add tests for encoded/invalid inputs

java
1@Test
2void rejectsRawJsonInQueryWhenUnencoded() {
3    // integration test with malformed URI should expect 400
4}

Regression tests prevent accidental acceptance/rejection changes during upgrades.

Common Pitfalls

  • Sending unencoded JSON or spaces in query strings and expecting server-side magic handling.
  • Relaxing Tomcat character rules broadly without security review.
  • Building URLs by manual string concatenation rather than URI builders.
  • Assuming Spring controller logic is at fault when proxy or container rejects request first.
  • Using GET with large structured payloads better suited for POST bodies.

Summary

Invalid character found in the request target usually means malformed URL encoding at the client boundary. Encode query/path components properly, validate inputs, and prefer POST for complex payloads. Relax Tomcat character settings only for explicit, justified cases. With correct URI construction and layered diagnostics, this error becomes easy to prevent and troubleshoot.

A practical way to harden this topic in real projects is to add a small operational checklist and treat it as part of your engineering standard, not a one-off fix. Start by creating one minimal failing case and one passing case that represent real input from production logs. Then automate those checks in CI so regressions are caught before release. Add lightweight instrumentation around the critical branch where this logic runs, and include structured fields that let you filter by version, environment, and error type. This gives you fast feedback when behavior changes after dependency upgrades or refactors.

For long-term maintainability on invalid character found in the request target in spring boot, keep one source of truth for helper logic instead of duplicating variants across services or UI layers. Document assumptions near the code, including data format, edge-case behavior, and expected fallback policy. During code review, verify that example inputs and tests cover empty values, malformed values, and high-volume scenarios. Teams that combine explicit assumptions, repeatable tests, and basic observability typically avoid the same category of bug recurring every quarter.


Course illustration
Course illustration

All Rights Reserved.