Greetings all, A little while back I started working on a module to control bandwidth utilization with rate limiting, employing fairly flexible configuration and some other nifty features.. At the time it became clear fairly early on that it would be much easier to do this properly within the 2.0 API than the then-current 1.3 server, but the 2.0 API was still somewhat in flux, so after looking into things a bit I decided to hold off for a little while and come back to things later.
Now that things are somewhat more solidified I'm coming back and looking at this project again, but I'm still running into a few questions with the current 2.0 API that I was hoping some folks here could provide some insight/suggestions on.. >From what I've read about the 2.0 API, this application (rate limiting of server output) seems perfect for an output filter. However, one of my first questions centers around where in the filter chain behavior such as this should go. Obviously, in order to function properly, this filter should come after any content-modifying filters in the output chain. Given the fairly low-level nature of what it's doing (controlling network traffic) it seems to me that it really makes most sense to put this somewhere in the AP_FTYPE_CONNECTION, or possibly even AP_FTYPE_NETWORK part of things, however it's my understanding that connection and network filters do not have access to any information about the request, and since the bulk of deciding what rate limits are to be imposed for a given hunk of data is going to be determined by per-resource configuration, this presents a problem. I could implement this as an AP_FTYPE_CONTENT_SET filter, which would make the most sense from a configuration and decision-making standpoint (since I have access to request information), but one of the questions I have about this is whether other buffering and such later in the filter chain (such as with transcode/connection/etc filters) would render any attempts at rate control at this level moot, or at least seriously degraded. Ultimately, what seems like the most correct solution I can see would be to implement this in multiple stages, with one content_set filter used to determine the appropriate limits for a given set of data, and then a later filter actually controlling the output rate of that data when it's closer to going out over the network. The problem with this is that I can't see any obvious way for the earlier filter to communicate what it's decided about the given data to the later stage for acting upon. Is there any way to "mark" data going out from one filter with information that can be used by a later filter when it gets that data to work on? Anyway, does anybody out there have suggestions on the best approach to use for this application? Where should code to control data flow rate go in the filter chain, and if that place isn't in a request-related filter, is there an easy way to make request-level decisions related to that filtering? Thanks, -alex PS: As this subject seems to be a hotbutton for some people (at least it was the last time I brought it up on this list), please don't just respond to this by saying "why would you want to do that?" or "bandwidth limiting doesn't belong in the httpd server!" or "people have already made things that do that" or similar things. I've had all these discussions before, and I have good reasons for making this module that I'll be happy to explain to people in private if you really want to understand where I'm coming from with this, but ultimately it boils down to: Yes, this is required to do things which you really can't do other ways and is potentially very useful. No, nobody else has already done it with the capabilities I'm looking for (I've checked).
