4

I am getting below error when response is larger in size, We can fix below by enabling Streaming in Apigee ( Currently out of scope as needs work at all up streams)

The error pasted below: {"Envelope":{"Body":{"Fault":{"faultcode":"soap:Server","detail":{"source":{"errorcode":"protocol.http.TooBigBody"}},"faultstring":"Body buffer overflow","faultactor":{}}},"encodingStyle":"http:\/\/schemas.xmlsoap.org\/soap\/encoding\/"}

I am planning raise fault when we get above error from downstream system. What should be HTTP Status Code ?

413 Request Entity Too Large

400 "Message: Response is large"

John D
  • 165
  • 2
  • 5
  • 12
  • 1
    It's not the client's fault that the response is too large for the server to handle, right? So I think it should be a 5xx code. Perhaps 503 Service Unavailable? – Jaap Joris Vens Oct 08 '20 at 07:40
  • this link could help: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml – Lety Oct 13 '20 at 15:42
  • It could be: 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request, while 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. 503 is a temporary situation while 500 is your case where due to a misconfiguration your server can't fulfill the request. 4xx are for client error and are appropriate only in this case. – Lety Oct 13 '20 at 15:59
  • What error code is the downstream system throwing when it responds with that? – Dijkgraaf Oct 15 '20 at 00:45

5 Answers5

3

My vote is for 500 - Internal Server Error, with some detail in the body. A 4xx error code indicates to the client that they should retry the request after making some modifications. That does not seem to be the case here.

redab
  • 603
  • 5
  • 9
1

If you will/can not do anything to return a response with expected body attributes to the clients in this case, then you should return 500 with a good message. I saw services return 200 and the details of the issue at some part of the response with a good (okay) message as errorMessage or something in similar cases. The idea here is to propagate the exception so that the client app can give a proper message to the end users, so let the client application know about the issue with the message.

mcvkr
  • 1,907
  • 3
  • 28
  • 50
1

Well, it looks like it should be a 500 error. And, as a good practice, you should add some details in the body or a good and clear message, as said before by some wise people here.

All the 4xx errors indicates that the system is fine but your request is not. Some examples:

  • 400: will not process the request due to a client error. In the past this code was only for syntax error, but nowadays is more generic: https://tools.ietf.org/html/rfc7231#section-6.5.1
  • 403: indicates that the server understood the request but refuses to authorize it.
  • 415: the payload format is not supported
  • 422: the request format and syntax are ok, but the server will not process it. Normally a good one to raise when validation fails or some semantics are not correct. More: https://tools.ietf.org/html/rfc4918#section-11.2

You can check all RFCs you want and will not find a 4xx error for this situation. Unless you misexplained and the user should change the request in any way in order to get the right result. In this case, 422 could be your choice, for example, if the request is in the right format and syntax, but the user is requesting too many resources.

Fabiano
  • 1,044
  • 5
  • 20
0

HTTP 413 Payload Too Large is wrong status code for this situation because it tells to the clients that you are sending large request and it leads to confusion of them.
HTTP 400 Bad Request is wrong status code for this situation because the request is correct and server knows what it wants to get but because of its own limits, server doesn't want to answer to this amount of response size.

HTTP 403 Forbidden should be your choice.

The server understood the request, but is refusing to fulfill it.

Note, mostly it is a good idea to tell the reason of refusing the request with correct response status code and custom message.

Afshin
  • 1,083
  • 6
  • 15
  • How about Status code 422 with error message "Response too Large " – John D Oct 08 '20 at 20:39
  • @JohnD 422 is useful when you have an Unprocessable entity in your request but if you have no request body (no entity) which is very common in get request, it is not appropriate. – Afshin Oct 08 '20 at 21:33
  • As rfc7235 report: The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any). So, it could not be the right choice – Lety Oct 13 '20 at 15:40
  • 2
    @JohnD Even, I think `HTTP 413` and `HTTP 400` are wrong error codes here, because it's not the client who is sending a wrong request here, it's the server who can't serve the request at this time. `HTTP 403 Forbidden` seems to be the correct response here. – Ashutosh Chamoli Oct 14 '20 at 12:30
  • That's not the definition for 403 error and you would be basically telling the user that his credentials are not enough to access it. – Fabiano Oct 14 '20 at 23:35
-1

If I understood your question correctly, Your API server is not able to full fill the request it got because the response for the request is too large.

In this case, We should be returning 503 - Service Unavailable. This way we can indicate that our API server not able to respond to the request temporarily, It's not a complete downtime of the API server and it's not happening for all the requests at a time which we got. This is gonna happen only when the response/payload is too large and that too for the selective requests. Since our API server is not able to handle and respond to the request at that moment it should be.

Kovalan R
  • 110
  • 1
  • 1
  • 6