How do you diagnose a request rejected before a Spring controller runs?

Classifies mapping, conversion, binding, validation, multipart, CORS, filter, and negotiation failures before changing controller code.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I capture the method, path, query, relevant headers, content type, accept value, body shape, response status, and resolved exception. Then I locate the stage: no handler or wrong method, media-type mismatch, message-conversion failure, type conversion, validation, multipart parsing, CORS preflight, or an earlier filter rejection. Spring logs and the exception resolver often name the exact category. I reproduce with the smallest request that preserves the failure.

Full answer below

Practice focus

Pipeline-based diagnosis using status, exception resolver, request evidence, and safe logging.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
A controller breakpoint is only useful after the request has matched and every required argument has been resolved.
I capture the method, path, query, relevant headers, content type, accept value, body shape, response status, and resolved exception. Then I locate the stage: no handler or wrong method, media-type mismatch, message-conversion failure, type conversion, validation, multipart parsing, CORS preflight, or an earlier filter rejection. Spring logs and the exception resolver often name the exact category. I reproduce with the smallest request that preserves the failure.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A malformed JSON body may raise a message-not-readable exception, while a valid JSON object with failed constraints follows the validation path. A 415 points toward request media support, and 406 points toward response negotiation. A browser-only failure suggests CORS or credentials, especially when direct curl succeeds. Reverse-proxy rewriting and maximum body limits are checked because the application may receive a different request or no request at all.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Changing controller logic before confirming it was invoked.
Mapping every pre-controller failure to one generic message.
Logging complete sensitive request bodies.

How do you diagnose a request rejected before a Spring controller runs?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?