0

It's pretty wired but true. We are a back-end web-service team and recently our client started complaining they are getting sporadic 400 error for a GET request (this is the 2nd time in 2 week) but from server side we don't have access log either with the request-id or error code.

It violates the basic rule of client-server architecture, I have no clue what's going wrong. Any help is highly appreciable.

From client log:

2017-01-30 16:44:43,507 [nio-8009-exec-22] WARN java_class - call https://getcall.com/api [request_id] with params {app_id, start_time_in_mills , sender_id, type, pagesize, end_time_in_mills} returned error code 400-Bad Request with error

lambodar
  • 3,495
  • 5
  • 34
  • 58
  • Are you going through a proxy? – Steve Smith Jan 31 '17 at 10:04
  • no, we are not using proxy. An additional info all our nodes are under LB(f5) – lambodar Jan 31 '17 at 10:06
  • See [this post about 400](http://stackoverflow.com/questions/19671317/400-bad-request-http-error-code-meaning) there is a problem with some parameter. Ask about the browser used, maybe there is an update with a small bug, depend on how this parameter are formatted. – AxelH Jan 31 '17 at 10:13
  • @AxelH 400 is OK in genuine cases but the problem is server did't receive any request, I'm not sure how clients are getting 400, that too it's sporadic. And client team is using jursey. – lambodar Jan 31 '17 at 10:19
  • Did you open the link ? 400-Bad request does tell it find the service but the request is malformed. From [w3](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) : **400 Bad Request : The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.** So like I said, check the request the client send, there is a malformed parameter probably. PS : **OK is 200** – AxelH Jan 31 '17 at 10:24
  • @AxelH yes I did! does it mean server will not record the error code and access log? the reason you/link gave is for genuine 400 error code and i see previously our access log recording 400. But this case is different and the problem is not able to back track because it's not printing any details in access log. https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html – lambodar Jan 31 '17 at 10:35
  • Well, paste the request with data (or data-like if you can't paste the real data) and headers. Of course, it could simply be a too long URL (length depends on client and server). But one reason I could think of why the server is not logging the request at all is simply because it never receive it. Depending on the server, you could reach the limit of request to manage (it is high) – AxelH Jan 31 '17 at 10:49
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/134467/discussion-between-lambodar-and-axelh). – lambodar Jan 31 '17 at 10:58

1 Answers1

1

It was a problem with HTTP header, we were sending large amount of data(encrypted acls) in header which was exceeding the default limit from LB side(type-7), hence the request was not routing to the node and rejected from LB. Two solution here:

  • Increase the default header size for your LB/Server
  • Consider breaking headers and move it to body wherever possible.
lambodar
  • 3,495
  • 5
  • 34
  • 58