- Software and digital services
- HTTP service
400
HTTP 400 Bad Request: the server rejected the request
Risk level
Low
Usually safe to check without specialist tools.
Urgency
Medium
Quick answer
HTTP 400 means the server cannot or will not process the request because it perceives a client error such as malformed syntax invalid message framing or deceptive routing. Capture the exact request before changing it.
Safety first
Stop and check this first
- Never paste authorization headers session cookies API keys or unredacted request bodies into public diagnostics. Capture structure and correlation data without exposing secrets.
Safe checks you can perform
- Capture the exact failing exchange safely
- Compare the request with the endpoint contract
- Identify which HTTP layer returned 400
Leave these tasks to a qualified professional
- Do not attempt this professional task: Trace parsing and routing at the rejecting layer
What a technician must be able to justify
Technician visit
These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.
These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.
Trace parsing and routing at the rejecting layer
What they doA developer or platform operator should correlate the request identifier across edge proxy and origin logs and inspect the first layer that records a parsing framing or routing rejection.
Before accepting a part or repair
Nothing has been shown yet. Do not accept a part swap based on the code alone.
Follow these steps
Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.
Capture the exact failing exchange safely
Record the method URL response status timestamp and any request identifier. Preserve headers and body structure only after removing authorization cookies tokens and personal data.
A raw request export can contain live credentials and user data. Redact it before storage or sharing.
Evidence: RFC 9110 section 15.5.1 - 400 Bad Request
Compare the request with the endpoint contract
Check the URL encoding required headers content type and body shape against the API or site documentation. Correct one mismatch at a time and retry in a safe environment.
Do not replay a state-changing request against production unless it is known to be safe and idempotent.
Evidence: RFC 9110 section 15.5.1 - 400 Bad Request
Identify which HTTP layer returned 400
Use response headers request IDs and controlled logs to distinguish an edge gateway proxy and the origin application before changing application code.
The 400 status itself does not prove that the origin application received the request.
Evidence: RFC 9110 section 15.5.1 - 400 Bad Request
Still not solved
If the error persists, stop here. See what the technician must do and show you.
Where this code applies
A code is meaningful only inside the right product and version context.
Primary scope
- System
- Software and digital services
- Brand
- HTTP
- Product type
- HTTP service
Known code variants
- 400 Bad Request
- 400 Richiesta non valida
- 400 Solicitud incorrecta
- 400 Ungültige Anfrage
- code erreur 400
- HTTP 400
- HTTP status 400
- status code 400
What it means
The status identifies the request class but not the exact bad field or layer that rejected it. An edge proxy and the origin can each generate 400.
Warnings and stop conditions
- Higheditorial warning
Never paste authorization headers session cookies API keys or unredacted request bodies into public diagnostics. Capture structure and correlation data without exposing secrets.
Evidence: RFC 9110 section 15.5.1 - 400 Bad Request
Symptoms and causes
Probable causes · in order
- Malformed request syntaxPossible
RFC 9110 lists malformed request syntax as an example of the client error perceived by a server returning 400.
Evidence: RFC 9110 section 15.5.1 - 400 Bad Request
- Invalid request message framingPossible
The server can reject a request whose HTTP message framing is invalid before the application can process it.
Evidence: RFC 9110 section 15.5.1 - 400 Bad Request
- Deceptive request routingPossible
RFC 9110 also names deceptive request routing as an example condition for 400 Bad Request.
Evidence: RFC 9110 section 15.5.1 - 400 Bad Request
Virtual technician
Does 400 still appear after these checks?
Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.
Sources and technical references
- 1
RFC 9110 section 15.5.1 - 400 Bad Request
Internet Engineering Task Force · 2022 · official_doc
Was this entry useful?