You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/05/06 04:13:41 UTC

DO NOT REPLY [Bug 19688] New: - ap_fputs, ap_fputc, ap_fwrite pass wrong filter pointer to ap_filter_flush?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19688>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19688

ap_fputs, ap_fputc, ap_fwrite pass wrong filter pointer to ap_filter_flush?

           Summary: ap_fputs, ap_fputc, ap_fwrite pass wrong filter pointer
                    to ap_filter_flush?
           Product: Apache httpd-2.0
           Version: 2.0.45
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: MMADKI@Doorways.org


Documentation for ap_fputc, etc. states that the filter argument is "the filter 
doing the writing".  However, this filter argument is sent as the context for 
ap_filter_flush via lower-level apr_ routines.  If an overflow occurs and 
ap_filter_flush is called then the filter pointer is used as the target for 
ap_pass_brigade by ap_filter_flush.  The result is that the brigade is passed 
back to the originating filter, resulting in an infinite loop or other 
nastiness.

EITHER the documentation in the source files needs to be changed to state that 
the filter argument is "the NEXT filter to which data should be passed in the 
event of an overflow" OR each of the macros ap_fputc, ap_fputs, and ap_fwrite 
needs to pass f->next instead of f as the context for any callbacks to 
ap_filter_flush.

This can be re-created by building an output filter that generates over 8K of 
data via the named macros.  Pass in the output filter's pointer (passed to the 
filter handler) and see the bad thing.  Pass in the next filter and see it work 
OK.

If this is a documentation glitch (including my misunderstanding it as written) 
then it is minor.  If the doc (and my understanding thereof) is correct and the 
macros need changing then it is major, as it prevents output filters which send 
out more than 8K at a whack from functioning properly.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org