How can we find out the cause for 400 Errors from the Router ?

Google Cloud Apigee
1

We are getting 400 Errors from the Router for one of our APIs.

HTTP/1.1 400 Bad Request
...
Server: Apigee Router

We are unable to get the trace for this API. Can you please help to determine the cause for these 400 Errors from the Router ?

2

  1. Analysed the router logs and found that there were many 400 Errors and occasional 200 successful responses.

  2. Checked the router entries for the 400 and 200 response codes.

    • Router Entry for 400 Response Code

      February 16th 2017; 18:15:57.000,status:400request:<request> HTTP/1.1virtual_host:<host-alias>:February 16th 2017; 18:15:57.000hostname:<router-host-name>remote_address:<address>upstream_address:-request_time:0.000upstream_status:-request_length:381response_size:246response_message_id:-user_agent:Apache-HttpClient/4.5.2 (Java/1.8.0_45)request_message_id:<message_id>x_forwarded_for:-x_apigee_fault-flag:-x_apigee_fault_source:-x_apigee_fault_code:-x_apigee_fault_policy:-x_apigee_fault_flow:-x_apigee_fault_revision:-x_apigee_dp_color:-x_apigee_target_latency:-1category:<category>path:edge-router.nginx@timestamp:February 16th 2017; 18:15:57.000_id:AVpG9T-PJUGqq5zKFY_i_type:elb-nginx-access_index:<index>

    • Router Entry for 200 Response Code

      February 16th 2017; 17:27:57.000,status:200request:<request> HTTP/1.1virtual_host:<host-alias>time_iso8601:February 16th 2017; 17:27:57.000hostname:<router-hostname>remote_address:<address>upstream_address:<MP-IP-address>request_time:0.523upstream_status:200request_length:378response_size:640response_message_id:-user_agent:Apache-HttpClient/4.5.2 (Java/1.8.0_45)request_message_id:<message_id>x_forwarded_for:-x_apigee_fault-flag:-x_apigee_fault_source:-x_apigee_fault_code:-x_apigee_fault_policy:-x_apigee_fault_flow:-x_apigee_fault_revision:-x_apigee_dp_color:-x_apigee_target_latency:400category:<category>path:edge-router.nginx@timestamp:February 16th 2017; 17:27:57.000_id:AVpGyUZvJUGqq5zK5v8m_type:elb-nginx-access_index:<index>

  3. Careful review of both the entries revealed that the request_length in the case of 400 Errors was 3 bytes more than in the case of 200 response consistently:

    • request_length: 381 in the failure case (400 Error)
    • request_length: 378 in the successful case (200)

  4. Informed this to the customer.

  5. Customer found that there was an issue in their code due to which additional 3 bytes were being passed in some scenarios. Fixing this code resolved the issue.