Use IBM’s Apache Directive Finder Instead of Google
When it comes to finding information on HTTP Server for IBM i (based on Apache), Google is NOT the way to go!
Recently Calvin did a web search for Apache’s ServerUserID directive. It returned old forum posts that could have taken anyone down a rabbit hole—a waste of time at best.
That’s why we strongly recommend IBM’s HTTP Server for IBM i Directive Finder instead. It reliably retrieves the most up-to-date information on configuration directives specific to IBM i. Try it yourself with the ServerUserID directive.
Fast and easy, and you get the latest, most accurate information available. See?
Apache on IBM i Directive Finder results for ServerUserID
If you’re not sure of the exact directive you need, try searching by keyword. For example, the search “SSL” returns 34 SSL directives, each linked to its configuration details.
Apache on IBM i Directive Finder results for SSL
Alternatively, use the “Show all” button on the main page to see all HTTP Server for i directives.
Any way you use it, IBM’s Apache Directive Finder will get you the information you need quickly, and you can count on it being current. For additional reference links, see our earler blog post: Apache for IBM i: Where to Find Documentation.
Stefan, I see the problem, that because the payload is encrypted, you cannot inspect the body until Apache receives it. I believe you’d also need mod_parp in order to inspect the payload (request body). If you could get your client to add a header to distinguish the type of each payload it would be a lot easier! We have had success building Apache extensions on IBM i. Let us know if you would like us to look at building these. An alternative would be if you could find a reverse proxy (even if on Linux or cloud-based), to sit in front of the IBM i, that has these modules built in.
Hi, Anyone knows if mod_qos is supported on IBM i? We are trying to limit the number of concurrent requests from our clients and it seems like a task for mod_qos. For some of our heavier api’s we need to throttle the clients – currently some of them send > 500 requests/second. Any hints highly appreciated.
Stefan, mod_qos is not provided by IBM. We could possibly build mod_qos on IBM i, but I’m not sure whether it is the best solution for your situation. What alternatives have you considered?
Hi Alan, I can imagine two alternatives, the first being a firewall rule pointing at the apache endpoint. The second is to try to manage the issue in the cgi-programs. I’m afraid of the overhead added to all requests as well. If we need to deal with this in every apache worker-job we need ( as an example ) create a database with a counter per remote ipaddress, timestamp and a counter. We currently use 200-300 worker job in this endpoint. To me this seems to be many IOPS to catch a situation that happens a few times a day.
Stefan, I would not suggest managing it in your programs. The firewall seems like the best way because that will limit traffic before it enters your network. What type of response do you wish to provide to the “excess” requests, since they are from your “friends?”
Likely a rc 429 indicating too many requests. Main issue with the firewall solution is that we can only throttle per ipaddress and time. All requests are POST with a body giving the details. It might have been beneficial to be able to throttle based on the payload.