Reading the Wikipedia page, it seems that there is some overlap between the two. Which is the best practice when uploaded max file size is exceded?
413 is the answer.
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.
413 Request Entity Too Large / Payload Too Large
The server is refusing to process a request because the request entity is larger than the server is willing or able to process. [...]
Sources:
400 status spec
413 status spec
Related
I made GET request with very long URL (size 12k) to Haproxy server and got 400 Bad request. Then i set
tune.bufsize 65536
as suggested here: haproxy and large GET requests.
Now server return 414 Request-URI Too Long.
Looks like you have also to increase the servers request uri length.
For example for nginx https://stackoverflow.com/a/69430750/6778826
I have a GET endpoint that sometimes returns a JSON payload larger than 10MB, thus giving me error code 500 as follows:
Execution failed due to configuration error:
Integration response of reported length 10507522 is larger than allowed maximum of 10485760 bytes.
I was aware of the 10MB payload quota, so I enabled Content Encoding in the Settings and added the HTTP header Accept-Encoding:gzip to the request.
Now, payloads that were 7-8MB uncompressed are being sent with a size of about 350KB, so the compression works. Still, payloads over 10MB continue to give that same error.
Why does it keep giving me this error? Is it checking payload size before compression? How can I fix this?
I'm implementing a pin code authorization in my web application and one of the requirements is to limit the attempt count of a user to n times in a day.
So, what is the best HTTP status code returned to the user when they reached the max attempt count?
Now, I'm thinking of
403
429 (but it's not about sending too many requests)
400 (but the request payload didn't invalid)
429 is exactly what you want.
from: https://datatracker.ietf.org/doc/html/rfc6585
429 Too Many Requests
The 429 status code indicates that the user has sent too many
requests in a given amount of time ("rate limiting").
The response representations SHOULD include details explaining the
condition, and MAY include a Retry-After header indicating how long
to wait before making a new request.
For example:
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
<html>
<head>
<title>Too Many Requests</title>
</head>
<body>
<h1>Too Many Requests</h1>
<p>I only allow 50 requests per hour to this Web site per
logged in user. Try again soon.</p>
</body>
</html>
Note that this specification does not define how the origin server
identifies the user, nor how it counts requests. For example, an
origin server that is limiting request rates can do so based upon
counts of requests on a per-resource basis, across the entire server,
or even among a set of servers. Likewise, it might identify the user
by its authentication credentials, or a stateful cookie.
Responses with the 429 status code MUST NOT be stored by a cache.
Note how the spec invites the service / implementation to provide details. It does not say what type of requests is too much or anything specific, really. Therefore, you will want to say something like "stop spamming my service because x, y, z".
In REST API if I have a resource which creation could take considerable amount of time I could return a temporary resource with status code 202. Client then could poll this temporary resource until the actual resource is created and get redirected to it when it'd done (with 303 status code). Something like described in http://restcookbook.com/Resources/asynchroneous-operations/.
Is there any standardized way to created such resources in OData?
Asynchronous requests are (briefly) mentioned in the OData V4 specification. It's probably worth reading for the fine details, but in short:
A client makes a request which includes a Prefer: respond-async header. The server can then respond with a HTTP 202 response as you described. This response includes a Location header which points to the 'status monitor resource'.
When the client sends a request to the status monitor resource there are 3 main responses:
HTTP 202: The operation is not yet completed.
HTTP 200: The operation is completed. This response must also include the AsyncResult header which holds the status code of the operation (e.g. a 200 for success, 5xx for error etc.). The body of this response contains the result of the operation.
HTTP 404:
The operation does not exist.
The operation was canceled.
The operation may have existed, but the client waited too long before requesting the status (May also be HTTP 410 (Gone)).
I don't know of any framework which implements this behavior, so you'll probably have to program it yourself.
I need to do asynchronous updates to a resource. Is there definitive statement on whether or not a 202 Accepted is an appropriate response to a PATCH?
The official documentation here, never mentions a 202, and appears to be assuming that resource changes due to a PATCH are made synchronously, but it never makes a definite statement.
What is the appropriate schematics for the PATCH action?
I don't see why returning a 202 is bad. While there is not explicit mention of using 202, the spec does hint to it in the example.
Successful PATCH response to existing text file:
HTTP/1.1 204 No Content Content-Location: /file.txt ETag:
"e0023aa4f"
The 204 response code is used because the response does not carry a
message body (which a response with the 200 code would have). Note
that other success codes could be used as well.
202 is a success code and it's definition does not prohibit it's use in a PATCH.
10.2.3 202 Accepted
The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be acted
upon, as it might be disallowed when processing actually takes place.
There is no facility for re-sending a status code from an asynchronous
operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.
As long as you patch atomically and the async request does not leave the resource in a half-patched state, this should be good.