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