[EMAIL PROTECTED] wrote: > Greetings all, > <snip> > 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. >
your trying to limit traffic based on what kind of request/request path it has ? > 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. yes, but from what I can see if you are trying to slow down the request with your filter, this should not be a major drama. > > 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? if you are basing the rate limiting on something on the request I would suggest you write a request hook, (somewhere after the request headers have been read.. forget the name for the moment) and make it set a note in the connection record. (or maybe use the apr_pool_userdata_set(pool) call it's faster) this hook could also insert your output filter, I would think it would make most sense for your filter to be between CORE_OUT & CONTENT_LENGTH or just before CONTENT_LENGTH depending on how you want to handle keep-alives. your filter can access the connection's notes table so your set (as far as data passing is concerned) I would set it just before CORE_OUT, giving you full control, and making sure that your hook doesn't insert it twice, the only downside is that you would need to check the note value everytime your filter got called. The only potential downside I can with implementing it this way is if you have 2 small requests which get sent out together, you will get the rate limit of the 2nd one. > > 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). >
