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
Related
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".
How to increase the header size limit in haproxy, currently the default settings allowed only 8KB.
Due to this we are facing 400 error at client side.
localhost haproxy[21502]: xx.xx.xx.xx:xxxx [xx/xxx/xxxx:xx:xx:xx.xx] www-http www-http/ -1/-1/-1/-1/0 400 187 - - PR-- 411/23/0/0/0 0/0 ""
You can set the tune.maxrewrite to a higher value.
It is strongly recommended that the header should be lower then the 8KB.
Here a link which shows the header limits on different servers Maximum HTTP request header size defaults compared across web servers
We are running production workloads with Istio 1.1.4 and noticed that for a specific timeframe, the request latency reported to the telemetry component for client invoked traffic increased from 50-60ms to 6-7 seconds and at the same time we started observing 500 (internal server error) response codes from Envoy.
We are trying to understand under what cases Envoy returns 500 and the only thing I could find in the documentation/source code was that a 500 is returned if the response body must be buffered and it exceeds the buffer limit. This is certainly not the case for us, as those 500 occurred for a health check endpoint beyond other endpoints, whose response body is very small.
What are the cases where Envoy will return 500? What should we investigate as the root cause of the issue?
Can you please provide the status code for below ?
a) Log Entry
b) Telemetry
c) Prometheus and Grafana
and just see if all three above shows response code as 500 or any deviation ?
Some rogue people have set up server monitoring that connects to server every 2 minutes to check if it's down (they connect from several different accounts so they ping the server every 20 seconds or so). It's a simple GET request.
I have two options:
Leave it as it is (ie. allow them via a normal 200 server response).
Block them by either IP or user-agent (giving 403 response).
My question is - what is the better solution as far as server performance is concerned (ie. what is less 'stressful' on the server) - 1 (200 response) or 2 (403 response)?
I'm inclined to #1 since there would be no IP / user-agent checking which should mean less stress on the server, correct?
It doesn't matter.
The status code and an if-check on the user-string is completely dominated by network IO, gc and server subsystems.
If they just query every 2 minutes, I'd very much leave it alone. If they query a few hundred times per second; time to act.
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