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 2006/12/07 11:34:22 UTC
DO NOT REPLY [Bug 41120] New: - Filters corrupt the data sent to the browser if they dont exist
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41120>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41120
Summary: Filters corrupt the data sent to the browser if they
dont exist
Product: Apache httpd-2
Version: 2.2.3
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: normal
Priority: P2
Component: mod_ext_filter
AssignedTo: bugs@httpd.apache.org
ReportedBy: stimmins@wiley.co.uk
If you define an external filter and the actual filter does not exist, or for
instance is not executable, then the data sent back to the browser becomes
corrupted.
Using a build of httpd 2.2.3 on solaris 9, all content was removed (headers
still present) resulting in a blank page. When processing content served by a
backend tomcat server (using mod_proxy_ajp) the content was (apprently
arbitrarily) missing a certain number of bytes from the begining.
The only error in the error_log file was as follows:
[Wed Dec 06 16:30:27 2006] [error] [client 10.0.3.19] (32)Broken pipe:
ef_unified_filter() failed
Droppping a valid filter onto the file system results in an immediate fix.
Sample configuration/filter:
ExtFilterDefine testfilter cmd="/var/tmp/filter.pl"
<Location />
SetOutputFilter testfilter
</Location>
And simply make sure the file /var/tmp/filter.pl does not exist. URLs should
stop working. Then put the following in /var/tmp/filter.pl:
#!/usr/local/bin/perl
use strict;
while (<STDIN>)
{
print;
}
Make it executable. Now URLs should be served correctly.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 41120] - Filters corrupt the data sent to the browser if they dont exist
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41120>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41120
------- Additional Comments From trawick@apache.org 2006-12-07 04:07 -------
You could experiment with a code change like this (several lines after call to
init_filter_instance()):
static apr_status_t ef_output_filter(ap_filter_t *f, apr_bucket_brigade *bb)
{
request_rec *r = f->r;
ef_ctx_t *ctx = f->ctx;
apr_status_t rv;
if (!ctx) {
if ((rv = init_filter_instance(f)) != APR_SUCCESS) {
/* return rv; */
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, f->r,
"mod_ext_filter: ignoring error, sending unfiltered
data");
f->etx->noop = 1;
}
ctx = f->ctx;
}
if (ctx->noop) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
This doesn't seem so useful in the grand scheme of things. It seems to me
rather rare that somebody would
*) implement/configure a filter
*) not test it immediately after configuration to ensure that it actually worked
*) desire for data to be sent unfiltered if the filter can't be started
I wonder if this scenario was confusing because of how the error was handled?
Maybe the output filter was called again even after it returned an error the
first time, and that led to the garbled output instead of no output?
That seems unlikely, but I don't see how else you'd be missing just the first
part of the response. If it can happen then this patch might help:
Index: mod_ext_filter.c
===================================================================
--- mod_ext_filter.c (revision 482178)
+++ mod_ext_filter.c (working copy)
@@ -67,6 +67,7 @@
ef_dir_t *dc;
ef_filter_t *filter;
int noop;
+ apr_status_t perm_error;
#if APR_FILES_AS_SOCKETS
apr_pollset_t *pollset;
#endif
@@ -855,10 +856,15 @@
if (!ctx) {
if ((rv = init_filter_instance(f)) != APR_SUCCESS) {
+ f->ctx->perm_error = rv;
return rv;
}
ctx = f->ctx;
}
+ else if (ctx->perm_error != 0) {
+ return ctx->perm_error;
+ }
+
if (ctx->noop) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org