httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject summary: issues for my filtering patch
Date Wed, 28 Jun 2000 01:17:01 GMT
I have posted my patch to STATUS for review. At the moment, Ryan has vetoed
it and provided his technical issues for it. I'm going to summarize those
and my responses. I believe those issues do not exist, and that the veto
should be rescinded.

The patch still requires two/three +1 votes (and no more vetos, of course).
I'm not sure of two/three -- does my vote count? :-)

I'm also not sure what happens if not enough people take the time to review
it and those extra +1 votes do not appear. Is that a pocket veto?

Note: below is just a summary. For detail, see my other note. The intent
here is to summarize what has been offered to date, and summarize why those
issues do not hold. Additionally, my hope is to clarify the purported issues
so that they may be addressed clearly and concisely. Those long emails tend
to hide things.

On to Ryan's issues:

 1) Ryan suggests that some items have been left out.

    => I suggested that he details which items he is referring to. Presuming
       these are the same things that we've talked about before (e.g.
       delaying sending http headers), then I've explained how these items
       can be deferred for future rounds of patches.

 2) the design requires the framework/filters to have unbounded heap usage

    => untrue. demonstrated otherwise.

 3) Roy's buckets are needed -- this solution doesn't go far enough.

    => the framework allows for extended/additional bucket types, but does
       not preclude them. therefore, these are deferred to a future patch
       set. and the term "need" was overstated.

 4) the char* handler is bad for various reasons

    => I showed that each of these "reasons" are issues for filters in
       general and not characteristic of the char* handler. regardless, the
       "reasons" do not preclude the patch, the design, or filters in

       [ This was a rather extensive section in Ryan's response. I did
	 respond to all of his issues, but they might not be reflected in
	 this summary email. Please look there if you have concerns in this
	 area. ]

 5) my framework precludes mod_auth_digest from computing a digest

    => false. it has extra work (or punt) if the response is non-chunked,
       but these are issues for mod_auth_digest rather than a problem
       inherent in the framework. mod_auth_digest is rather unique in this
       regard due to its need to see the whole entity-body, rather than
       always able to operate in a streaming fashion like most other

 6) content generators should change how they output data
    => possibly, but that is a separate change for the future. my patch does
       not preclude the types of changes that Ryan suggests

 7) both buckets and char* callbacks introduces bugs

    => absurdly false. the proffered example was way out of line.

 8) need to track pools and their lifetimes

    => false. demonstrated otherwise

 9) the framework demands extra memory and memcpys

    => false. demonstrated otherwise

10) the framework precludes certain optimizations

    => possibly (as with any code), but there has not been a credible
       example of an optimization that is: important/relevant, and can't be
       done later within this framework

11) Content-Length needs to be sent when filters are present

    => detailed to Roy, and in my response to Ryan, that this can be handled
       in a future patch set.

       Note: Content-Length *remains* in the non-filter case. Only when we
       start taking advantage of this new feature, will it disappear. But
       there are examples of how C-L can be put back in for certain types of
       filters and response.

12) subrequests won't work (because of output filter chain issues?)

    => false. demonstrated empirically with my mod_gargle. also demonstrated
       that other subrequest filter chain policies can be specified.

That is it.

AFAICT, there are no surviving issues from Ryan's response to my issue
recap. If some do, then please bring them up so that I can track them and
respond to them.

I would also encourage others to go ahead and review the patch. It is ready
for inclusion, and I believe that it builds a great framework for output
filtering. There have been many suggestions for future optimizations and
improvements. Many have been great, but are not required at this point in
the process -- they can all be performed after this framework is in place.
As we all know, step-wise patches are much better than mother-patches. I
would like to continue with that tradition/process for the filtering


Greg Stein,

View raw message