On Thu, 2003-12-11 at 20:43, Stas Bekman wrote: > Raul Dias wrote: > > On Thu, 2003-12-11 at 16:30, Stas Bekman wrote: > > > >>Raul Dias wrote: > >> > >>>On Wed, 2003-12-10 at 20:42, Stas Bekman wrote: [...] > > It would really help to have some section about all the methods > > available to $filter, $request and $connection handlers. > > some section? You are being funny: > > perl-5.8.3-ithread -MApache2 -MModPerl::MethodLookup -e print_object > Apache::RequestRec | wc -l > 149 > Great. This is a good start point for me.
> This is only the methods you can invoke on the request object. There are some > 600 or 700 methods and functions in mp2. > > Things are slowly getting documented at: > http://perl.apache.org/docs/2.0/api/ > > For example the filter page is pretty complete: > http://perl.apache.org/docs/2.0/api/Apache/Filter.html > > > Most of the time I found some methods by browsing the list history. > > I just got to know about $c->aborted() in this thread. > > > > Sorry if this is documented somewhere, but there is no mention of it by > > greping the docs dir. > > Because it's incomplete. Help to add more things is very welcome. A big chunk > is the same as mp1 so it should be an easy copy-n-paste. > I did mean to sound as a rant (if I did). I know that's not easy to keep with the documentation. [...] > >>I'm not sure what's the right response code to use here, since first it > >>doesn't matter to the user (the connection is aborted), second a particual > >>caller of the filter may ignore the response code. I'd think AP_FILTER_ERROR > >>might be a good choice. Let me ask httpd-dev what response code should be used > >>in such a case and I'll be back to you. Then we can document it nicely. > > > > > > I think that Apache::DECLINED is the correct behaviour as you explain > > above. > > > > In a bandwidth limiter, there is no point on holding the traffic after > > the connection has being aborted. > > You aren't holding the traffic. If the connection is aborted the process is > still busy churning data, but it doesn't send any of it out. I don't think > your bandwidth limiter should be affected at all. It should monitor sockets, > not processes I believe. what if the process is busy in the cleanup phase, do > you also consider it consuming bandwidth? It doesn't since Cleanup handler is > run after the connection has been closed. > I am using a naive approach to do a traffic shapper. Dividing the available bandwidth by the sum of all "shapped" connections will give the individual connection bandwidth. Without detecting that the connection was aborted, it would be counted in the sum of the "shapped" connection. In this sense it would still slowing down the other connections. At least until I figure out a way to measure the real speed that the data is being sent to the client. > > OTOH, a filter might need to finish > > parsing a file even if the connection was drop to do some clean up that > > might be dependent on the file content (e.g. a database transaction). > > And that's precisely why I suggested that Apache::DECLINED is not the correct > value to return, because of its special meaning. It'll try to forward the > brigade that was already partially read and processed, which most likely mess > things up (it doesn't since normally nobody cares what it does if the > connection was aborted). I think I understand it now. You can only use Apache::DECLINED before starting to read the data. []'s Raul Dias -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
