提交合法Gson JSON请求至Jersey端点遇Bad Request问题咨询

Let’s break down your problem step by step, starting with your Wireshark question and moving into other likely root causes:

Could Wireshark miss redundant content in the request body? #

In almost all cases, no. Wireshark captures raw network packets as they traverse the network interface you’re monitoring. As long as your capture setup is correct (you’re watching the right interface, no traffic filters are excluding your request, and there’s no packet loss), the payload you see in Wireshark is exactly what’s being sent to the server. Redundant content at the end of the request body would show up in the TCP stream reassembly. If you’ve verified the full payload matches what you intended to send, this is extremely unlikely to be a Wireshark oversight.

Other Likely Causes for the 400 Bad Request #

Since your payload is syntactically valid and length-correct, let’s look at common issues that still trigger bad requests in Jersey:

• Incorrect Content-Type Header
  Jersey is strict about request content types. If your request doesn’t explicitly set Content-Type: application/json (or application/json;charset=UTF-8), the server might not recognize the payload as JSON and reject it. Double-check that this header is present and correctly formatted in your request.

• Gson Serialization vs. Jersey Deserialization Mismatch
  Even if your JSON is valid, the way Gson serializes certain types (like LocalDateTime, enums, or custom objects) might not align with how Jersey’s default deserializer (often Jackson, in Payara) expects them. For example:

  • Gson might serialize a LocalDateTime as a string in yyyy-MM-ddTHH:mm:ss format, but Jackson expects an ISO-8601 string with timezone info, or a numeric timestamp.
  • If you’re using custom Gson type adapters, ensure they produce output that Jersey’s deserializer can handle without errors.

• Misconfigured Jersey Endpoint
  Verify your endpoint method is set up correctly:

  • Does it have the @Consumes(MediaType.APPLICATION_JSON) annotation? Without this, Jersey won’t attempt to parse the JSON payload.
  • Are you using the right parameter bindings? For example, if you’re expecting a POJO, make sure it’s a direct parameter of the method (not wrapped in @FormParam or other form-based annotations).
  • Check for typos in field names between your JSON payload and the target POJO—case sensitivity (e.g., userName vs. username) can cause deserialization failures even with valid JSON.

• Character Encoding Mismatch
  If your JSON payload uses a non-UTF-8 encoding (like ISO-8859-1) but the server expects UTF-8, this can silently break deserialization even if the syntax looks correct. Ensure your request explicitly sets charset=UTF-8 in the Content-Type header, and that Gson is configured to serialize with UTF-8.

• Payara-Specific Configuration Conflicts
  Payara ships with Jackson as the default JSON provider. If your application uses Gson, you might have a conflict between the two libraries. Ensure you’ve properly registered Gson as Jersey’s JSON provider by adding a custom MessageBodyReader and MessageBodyWriter for Gson, or by excluding Jackson from your Payara deployment if you don’t need it.

Recommended Debugging Steps #

1. Enable Jersey Debug Logs
   Add logging configuration to your Payara server to see exactly what Jersey is processing:

   logging.level.org.glassfish.jersey=DEBUG
   logging.level.org.glassfish.jersey.message=TRACE
   

   This will log the raw request body received by the server and any deserialization errors, which can pinpoint the issue.

2. Inspect the Request Directly in the Endpoint
   Modify your endpoint to read and print the raw request body, to confirm it matches what you see in Wireshark:

   @POST
   @Path("/your-endpoint")
   @Consumes(MediaType.APPLICATION_JSON)
   public Response yourMethod(@Context HttpServletRequest request) throws IOException {
       String requestBody = new BufferedReader(new InputStreamReader(request.getInputStream())).lines()
           .collect(Collectors.joining("\n"));
       System.out.println("Received request body: " + requestBody);
       // Rest of your logic
   }
   

3. Test with a Minimal Payload
   Simplify your JSON to the smallest valid structure (e.g., {"id": 1, "name": "test"}) and a matching POJO. If this works, gradually add back fields to identify which one is causing the failure.

4. Validate JSON Against Your POJO
   Use Gson to deserialize the JSON payload directly in a standalone test (outside Jersey/Payara) to confirm that Gson can parse it into your target POJO without errors. If this fails, the issue is in your Gson configuration or POJO mapping.

内容的提问来源于stack exchange，提问作者juju