Graphite API responds with 413 when response is too large not request about metrictank

[Dieterbe]

the standard set of http status codes doesn't always map well to our needs, and sometimes no code seems to be the exact right fit for a given use case.
You're right that 413 was never intended to be used this way, but neither was 403. 403 seems generally assumed to come from lacking authorization in a security context.

[blami]

@Dieterbe I understand but using 413 is really misleading as most of tools/libraries suggest this is problem with request size and not query evaluation issue (breaking limits) on server side.

Also understand that given 403 being used mainly in security context might be misleading/fuzzy as 413 is. Since explanation is provided in error response body what about using bare 400?

[Dieterbe]

most of tools/libraries suggest this is problem with request size

interesting. do you know of examples of this?

So I've been reading the RFC a bit more..
https://tools.ietf.org/html/rfc2616

413 and 400 are fairly explicit in the spec that they are meant for a different use then this. 413 you already pointed out, 400 is due to "The request could not be understood by the server due to malformed syntax."

Reading the 403 in more detail leads me to believe it has nothing to do with security, and anyone (including me :) ) treating it this way is wrong.
Because 401 covers both "you need to authenticate" and "you authenticated and you're login is not allowed to request this"

The mozilla "interpretation" if this status code seems to confirm
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403 says

403 Forbidden
The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it.

This status is similar to 401, but in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.

for completeness, the RFC copy:

10.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help and the request SHOULD NOT be repeated.
   If the request method was not HEAD and the server wishes to make
   public why the request has not been fulfilled, it SHOULD describe the
   reason for the refusal in the entity.  If the server does not wish to
   make this information available to the client, the status code 404
   (Not Found) can be used instead.

I now think 403 is the best choice for this use case.

[blami]

@Dieterbe Thanks for looking into this. I wanted to bring up "Authorization will not help and the request SHOULD NOT be repeated." - but had to agree with you that 403 is in real world used a lot in security context and that note can be easily interpreted like 401 "you authenticated and you're login is not allowed to request this" easily.

As for tools I was playing with API through few HTTP intercepting tools that give hints on bad results while building API client (tools like https://httptoolkit.tech/ or postman) and they mostly gave "invalid request" kind of hint.

[Dieterbe]

yep, let's do the right thing then and use 403.

thanks Ondrej !