Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, 23 Oct 2003, [ISO-8859-15] André Malo wrote:
* [EMAIL PROTECTED] wrote:
Log:
fix segfault which occured if the filename was not
set, for example, when processing some error conditions.
-if ((t = strrchr(r-filename, '/'))) {
+if (r-filename (t = strrchr(r-filename, '/'))) {
apr_table_setn(e, DOCUMENT_NAME, ++t);
}
In fact, r-filename is used way more often within the includes filter
(in error messages). Should we catch these cases as well, i.e. replace
occurences of r-filename with r-filename ? r-filename : NULL?
Uck. I still think somebody ought to go on a mission to eliminate these
null r-filename cases. I don't have time tho. :( Maybe a good thing
for some of us to look at at the Con.
In the meanwhile I guess we should be checking for it to be null, though,
yes.
--Cliff
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
* [EMAIL PROTECTED] wrote:
Log:
fix segfault which occured if the filename was not
set, for example, when processing some error conditions.
-if ((t = strrchr(r-filename, '/'))) {
+if (r-filename (t = strrchr(r-filename, '/'))) {
apr_table_setn(e, DOCUMENT_NAME, ++t);
}
In fact, r-filename is used way more often within the includes filter (in
error messages). Should we catch these cases as well, i.e. replace occurences
of r-filename with r-filename ? r-filename : NULL?
nd
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
* [EMAIL PROTECTED] wrote: Modified:modules/filters mod_include.c Log: void * can't be used as a function pointer without casting doh, really? Good to know ;-) Thanks, nd
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
André Malo wrote: * [EMAIL PROTECTED] wrote: Modified:modules/filters mod_include.c Log: void * can't be used as a function pointer without casting doh, really? Good to know ;-) unfortunately this is one of a few common issues we hit from time to time that gcc doesn't catch, at least with the flags we use with --enable-maintainer-mode... maybe some experimentation in that area would be useful some of the vendor compilers puke with assigning void * to function *...
Re: cvs commit httpd-2.0/modules/filters/mod_include.c
Sorry for the lack of timeliness on responding to this. Our mailserver has been about to be back up any minute now for a couple of days. The test case that I ran was even more brutal than what your test module does. Basically I have a small piece of code that puts each byte in its own bucket and each bucket in its own brigade. Brian's patch will not handle this case because there is no next bucket to point tag_start_index at. I was a little vague in my description of the problem. Basically, if the !--# tag occurs at the end of one brigade and the directive starts at the beginning of the next brigade we have trouble. In my tests this was causing a core dump which my patch fixed. I'm also surprised that the include virtual was failing since it passed my tests. :( I'll double check those results to see if I missed something. Also, Brian, I do not see where the comment you removed was invalid. Slen is only ever set to ctx-start_seq_len (which by default is 5 I believe). Slen is never changed to be any number other than ctx-start_seq_len. I do not claim to have studied bndm enough to be certain, but it seems to me that if the brigade has a single bucket with a single byte which hapens to match within the pattern then you will end up incrementing ctx-bytes_parsed by pos+slen (where slen == 5) when only one byte was processed. That is to say, len == 1, so it will enter the if (len) conditional block around line 472. Bndm can match the pattern and return pos = 0, so it enters the (pos != len) conditional block. At the end of this block it increments ctx-bytes_parsed by pos+slen even though it only processed one byte. The previous bytes will have already been accounted for during runs through find_start_sequence for previous brigades. Where am I confused? Sorry again for the delay in responding. Paul J. Reder
Re: cvs commit httpd-2.0/modules/filters/mod_include.c
Paul Reder wrote: Sorry for the lack of timeliness on responding to this. Our mailserver has been about to be back up any minute now for a couple of days. The test case that I ran was even more brutal than what your test module does. Basically I have a small piece of code that puts each byte in its own bucket and each bucket in its own brigade. Brian's patch will not handle this case because there is no next bucket to point tag_start_index at The next bucket in this case is the brigade sentinel, which is the same thing that send_parsed_content() would choose as the next bucket to scan if we escaped from find_start_sequence() with tag_start_index==NULL. I was a little vague in my description of the problem. Basically, if the !--# tag occurs at the end of one brigade and the directive starts at the beginning of the next brigade we have trouble. In my tests this was causing a core dump which my patch fixed. I'm also surprised that the include virtual was failing since it passed my tests. :( I'll double check those results to see if I missed something. Also, Brian, I do not see where the comment you removed was invalid. Slen is only ever set to ctx-start_seq_len (which by default is 5 I believe). Slen is never changed to be any number other than ctx-start_seq_len. I do not claim to have studied bndm enough to be certain, but it seems to me that if the brigade has a single bucket with a single byte which hapens to match within the pattern then you will end up incrementing ctx-bytes_parsed by pos+slen (where slen == 5) when only one byte was processed. bndm will only match on an instance of the complete pattern within the current bucket. If slen==5 and len==1, bndm won't find a match. All the one-byte-at-a-time scanning code in find_start_sequence() exists solely to catch the boundary cases where the pattern spans two or more buckets--the cases that bndm won't detect. So when bndm finds a match, it's guaranteed that len = slen. If len==1 and bndm indicates that it's found a pattern, it can only mean that the pattern has been changed from !--# to some single-byte token. This case *is* possible, now that we support the SSIStartTag directive. But the logic for incrementing ctx-bytes_parsed by pos+slen is still correct; pos+slen==1. --Brian
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
William A. Rowe, Jr. wrote: At 03:19 PM 4/4/2002, you wrote: rederpj 02/04/04 13:19:32 Modified:modules/filters mod_include.c Log: This patch fixes a core dump that occurs in mod_include during tag parsing if the starting sequence (!--#) finishes at the end of a bucket and the directive starts at the beginning of the next bucket. Revision ChangesPath 1.215 +47 -24httpd-2.0/modules/filters/mod_include.c Could any of the three or so of you who have looked at this problem already vouch for Paul's solution here? One enthusiastic +1 from those who know this bug best would help sway me to get this fix straight into .34. -1 for now, I'm afraid. With this new code, mod_include is failing one of my test cases in which each character of an otherwise-valid !--#include ... -- directive is contained in a separate bucket. This test case worked with the original .34 mod_include code. I'm debugging now. --Brian P.S.: My test case is: * Create a file consisting of !--#include virtual=/whatever -- * Add Ctrl-B's between all the characters * Run through the BUCKETEER filter before mod_include; this will create bucket breaks where all the Ctrl-B's are.
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
At 03:19 PM 4/4/2002, you wrote: rederpj 02/04/04 13:19:32 Modified:modules/filters mod_include.c Log: This patch fixes a core dump that occurs in mod_include during tag parsing if the starting sequence (!--#) finishes at the end of a bucket and the directive starts at the beginning of the next bucket. Revision ChangesPath 1.215 +47 -24httpd-2.0/modules/filters/mod_include.c Could any of the three or so of you who have looked at this problem already vouch for Paul's solution here? One enthusiastic +1 from those who know this bug best would help sway me to get this fix straight into .34. Bill
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, 4 Apr 2002, William A. Rowe, Jr. wrote: This patch fixes a core dump that occurs in mod_include during tag parsing if the starting sequence (!--#) finishes at the end of a bucket and the directive starts at the beginning of the next bucket. Revision ChangesPath 1.215 +47 -24httpd-2.0/modules/filters/mod_include.c Could any of the three or so of you who have looked at this problem already vouch for Paul's solution here? One enthusiastic +1 from those who know this bug best would help sway me to get this fix straight into .34. I'm sorry, but -0 for now. I just added a bunch of tests to the httpd-test repository that use mod_bucketeer to test mod_include. They all work before this patch, but the last two (the most brutal ones :) fail after the patch. The ones that now fail basically put every single byte of an include virtual tag into separate buckets. On HEAD, the tag just silently disappears for some reason I haven't determined yet. The upshot is that we now have a good framework in the httpd-test repository for constructing worst cases for mod_include. Paul, can you do me the favor of making a test that demonstrates the conditions that are segfaulting for you that were fixed by this patch? It's really easy to set these things up now. mod_bucketeer is my new best friend. :) With more tests, I think we'll be able to pin down whatever the remaining issue is pretty quickly. Thanks, --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 5 Apr 2002 [EMAIL PROTECTED] wrote: brianp 02/04/04 23:44:15 Modified:modules/filters mod_include.c Log: Fix for the boundary case in which each character of an SSI directive is in a separate bucket...the code in send_parsed_content() doesn't Holy crap, that was fast! One second you send an email, the next second a fix is committed. Nice. :) Of course I would still really appreciate it if someone could craft a test for the condition that was segfaulting before these patches. But, since the other issue is resolved, I of course change my vote to +1 for HEAD. Looks good to me! --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
This is *not* equivalent code. In the deleted line the increment happens *after* the check. In the replacement line of code the increment happens during the check. This patch is wrong and should be backed out. Paul J. Reder [EMAIL PROTECTED] wrote: bnicholes02/03/28 16:39:56 Modified:modules/filters mod_include.c Log: Stop the while loop from incrementing twice per iteration before checking for the NULL terminator. This was causing the while loop to walk off the end of any string with an odd number of characters. Revision ChangesPath 1.209 +1 -1 httpd-2.0/modules/filters/mod_include.c Index: mod_include.c === RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v retrieving revision 1.208 retrieving revision 1.209 diff -u -r1.208 -r1.209 --- mod_include.c 28 Mar 2002 01:57:03 - 1.208 +++ mod_include.c 29 Mar 2002 00:39:56 - 1.209 @@ -1179,7 +1179,7 @@ return 0; #endif path += dots; -while (*path *(path++) != '/') +while (*path *(path+1) != '/') ++path; } return 1; -- Paul J. Reder --- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Nevermind. Should have read the rest of my mail before commenting. I see that it has already been fixed. Sorry for the noise. Paul J. Reder wrote: This is *not* equivalent code. In the deleted line the increment happens *after* the check. In the replacement line of code the increment happens during the check. This patch is wrong and should be backed out. Paul J. Reder [EMAIL PROTECTED] wrote: bnicholes02/03/28 16:39:56 Modified:modules/filters mod_include.c Log: Stop the while loop from incrementing twice per iteration before checking for the NULL terminator. This was causing the while loop to walk off the end of any string with an odd number of characters. Revision ChangesPath 1.209 +1 -1 httpd-2.0/modules/filters/mod_include.c Index: mod_include.c === RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v retrieving revision 1.208 retrieving revision 1.209 diff -u -r1.208 -r1.209 --- mod_include.c28 Mar 2002 01:57:03 -1.208 +++ mod_include.c29 Mar 2002 00:39:56 -1.209 @@ -1179,7 +1179,7 @@ return 0; #endif path += dots; -while (*path *(path++) != '/') +while (*path *(path+1) != '/') ++path; } return 1; -- Paul J. Reder --- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
[EMAIL PROTECTED] wrote: bnicholes02/03/28 16:39:56 Modified:modules/filters mod_include.c Log: Stop the while loop from incrementing twice per iteration before checking for the NULL terminator. This was causing the while loop to walk off the end of any string with an odd number of characters. With this change, the is_only_below() function is getting stuck in an infinite loop when I run httpd-test. I'm gdb'ing it now... --Brian
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 29 Mar 2002 [EMAIL PROTECTED] wrote:
-while (*path *(path+1) != '/')
+while (*path (*path != '/')) {
+++path;
+}
+if (*path == '/') {
++path;
+}
Alternatively:
while (*path *(path++) != '/')
continue;
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Wed, 27 Feb 2002, Brian Pane wrote:
+if (!APR_BRIGADE_EMPTY(ctx-ssi_tag_brigade)) {
+for (;;) {
+apr_bucket *e = APR_BRIGADE_LAST(ctx-ssi_tag_brigade);
+if (e == APR_BRIGADE_SENTINEL(ctx-ssi_tag_brigade)) {
+break;
+}
+APR_BUCKET_REMOVE(e);
+APR_BRIGADE_INSERT_HEAD(bb, e);
+}
}
I was thinking about APR_BRIGADE_CONCAT, but what I really needed
was APR_BRIGADE_PREPEND because _CONCAT would have left bb empty.
Is there a prepend variant anywhere?
The following is equivalent to the above (except it runs in constant
time):
/* prepend ctx-ssi_tag_brigade onto bb */
APR_BRIGADE_CONCAT(ctx-ssi_tag_brigade, bb);
APR_BRIGADE_CONCAT(bb, ctx-ssi_tag_brigade);
But I'd be fine with adding a prepend macro in the API if others agree
it's useful.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Cliff Woolley wrote:
On Wed, 27 Feb 2002, Brian Pane wrote:
+if (!APR_BRIGADE_EMPTY(ctx-ssi_tag_brigade)) {
+for (;;) {
+apr_bucket *e = APR_BRIGADE_LAST(ctx-ssi_tag_brigade);
+if (e == APR_BRIGADE_SENTINEL(ctx-ssi_tag_brigade)) {
+break;
+}
+APR_BUCKET_REMOVE(e);
+APR_BRIGADE_INSERT_HEAD(bb, e);
+}
}
I was thinking about APR_BRIGADE_CONCAT, but what I really needed
was APR_BRIGADE_PREPEND because _CONCAT would have left bb empty
Is there a prepend variant anywhere?
The following is equivalent to the above (except it runs in constant
time):
/* prepend ctx-ssi_tag_brigade onto bb */
APR_BRIGADE_CONCAT(ctx-ssi_tag_brigade, bb);
APR_BRIGADE_CONCAT(bb, ctx-ssi_tag_brigade);
Thanks, I'll update this in mod_include later today
But I'd be fine with adding a prepend macro in the API if others agree
it's useful
+1
--Brian
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, Feb 28, 2002 at 12:57:50PM -0500, Cliff Woolley wrote: The following is equivalent to the above (except it runs in constant time): /* prepend ctx-ssi_tag_brigade onto bb */ APR_BRIGADE_CONCAT(ctx-ssi_tag_brigade, bb); APR_BRIGADE_CONCAT(bb, ctx-ssi_tag_brigade); But I'd be fine with adding a prepend macro in the API if others agree it's useful That is *very* obtuse I can't imagine anybody figuring out that idiom means prepend Yes, please add an appropriate macro thx! -g -- Greg Stein, http://wwwlyraorg/
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, 28 Feb 2002, Cliff Woolley wrote: On Thu, 28 Feb 2002, Greg Stein wrote: /* prepend ctx-ssi_tag_brigade onto bb */ APR_BRIGADE_CONCAT(ctx-ssi_tag_brigade, bb); APR_BRIGADE_CONCAT(bb, ctx-ssi_tag_brigade); That is *very* obtuse. I can't imagine anybody figuring out that idiom means prepend. Yes, please add an appropriate macro. Okay, will add. Committed. Brian, can you please run your tests on it for me? I've yet to find the exact test case to get into that block of code. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Cliff Woolley wrote: On Thu, 28 Feb 2002, Cliff Woolley wrote: On Thu, 28 Feb 2002, Greg Stein wrote: /* prepend ctx-ssi_tag_brigade onto bb */ APR_BRIGADE_CONCAT(ctx-ssi_tag_brigade, bb); APR_BRIGADE_CONCAT(bb, ctx-ssi_tag_brigade); That is *very* obtuse I can't imagine anybody figuring out that idiom means prepend Yes, please add an appropriate macro Okay, will add Committed Brian, can you please run your tests on it for me? I've yet to find the exact test case to get into that block of code I just finished testing against my test cases that exercise this part of the code, and the new version using APR_BRIGADE_PREPEND works fine All my test cases for this are variants of a technique that Ian created: use mod_bucketeer in front of mod_include, and insert ctrl-B's (force new bucket), ctrl-P's (pass brigade now), and ctrl-F's (flush brigade) after '' symbols that aren't the start of a !--# This exercises the code in mod_include that keeps track of !--# directives that span brigades --Brian
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 24 Feb 2002 [EMAIL PROTECTED] wrote:
+if (!APR_BRIGADE_EMPTY(ctx-ssi_tag_brigade)) {
+for (;;) {
+apr_bucket *e = APR_BRIGADE_LAST(ctx-ssi_tag_brigade);
+if (e == APR_BRIGADE_SENTINEL(ctx-ssi_tag_brigade)) {
+break;
+}
+APR_BUCKET_REMOVE(e);
+APR_BRIGADE_INSERT_HEAD(bb, e);
+}
}
sigh
PLEASE use APR_BRIGADE_CONCAT() for these kinds of things. I can't say
that frequently enough I guess.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Cliff Woolley wrote:
On 24 Feb 2002 [EMAIL PROTECTED] wrote:
+if (!APR_BRIGADE_EMPTY(ctx-ssi_tag_brigade)) {
+for (;;) {
+apr_bucket *e = APR_BRIGADE_LAST(ctx-ssi_tag_brigade);
+if (e == APR_BRIGADE_SENTINEL(ctx-ssi_tag_brigade)) {
+break;
+}
+APR_BUCKET_REMOVE(e);
+APR_BRIGADE_INSERT_HEAD(bb, e);
+}
}
sigh
PLEASE use APR_BRIGADE_CONCAT() for these kinds of things. I can't say
that frequently enough I guess.
I was thinking about APR_BRIGADE_CONCAT, but what I really needed
was APR_BRIGADE_PREPEND because _CONCAT would have left bb empty.
Is there a prepend variant anywhere?
--Brian
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 24 Feb 2002 [EMAIL PROTECTED] wrote: HTTPD-test is failing. but it was failing on 2.0.32 version of mod-include as well Really?? What's the verbose output? It worked fine for me when I tested 2.0.32... I'll try it again with HEAD tomorrow. --Cliff
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Cliff Woolley wrote:
On 24 Feb 2002 [EMAIL PROTECTED] wrote:
HTTPD-test is failing.
but it was failing on 2.0.32 version of mod-include as well
Really?? What's the verbose output? It worked fine for me when I tested
2.0.32... I'll try it again with HEAD tomorrow.
--Cliff
2.0.32 is clean
2.0.32 + CVS-HEAD of mod-include
# testing : GET /modules/include/exec/off/cmd.shtml
# expected: '[an error occurred while processing this directive]'
# received: ''
not ok 8
# testing : GET /modules/include/exec/off/cgi.shtml
# expected: '[an error occurred while processing this directive]'
# received: ''
not ok 30
and we get a core-dump
in handle_exec/mod_cgi
it looks like the ctx has some bad data
(gdb) print *ctx
$6 = {state = PARSED, flags = 11, if_nesting_level = 0, parse_pos = 3,
bytes_parsed = 39, status = 0, output_now = 0, head_start_bucket = 0x0,
head_start_index = 135541272, tag_start_bucket = 0x0, tag_start_index
= 135541272, tail_start_bucket = 0x5, tail_start_index = 135541272,
combined_tag = 0x24 Address 0x24 out of bounds, curr_tag_pos =
0xbfffe2a0 exec, directive_length = 3221217957, tag_length = 4,
error_str = 0x1f Address 0x1f out of bounds, error_str_override =
0x80944a0 [an error occurred while processing this directive],
time_str = 0x0, time_str_override = 0x8093a95 %A, %d-%b-%Y %H:%M:%S
%Z, pool = 0x0, ssi_tag_brigade = 0x8143730, start_seq_pat = 0x8143ba8,
start_seq = 0x8141b0c , start_seq_len = 134822578, end_seq = 0x5
Address 0x5 out of bounds, re_string = 0x8093aae --, re_result = 0x0}
(gdb)
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
I think I have it working now (with the mod_include
changes that I just committed). Mod_include test #31
in httpd-test is failing, but I think it's a config
problem.
We probably need some more test cases in httpd-test
to validate all the boundary conditions that can occur
in mod_include when SSI directives span multiple buckets
or even multiple brigades.
--Brian
Ian Holsman wrote:
Cliff Woolley wrote:
On 24 Feb 2002 [EMAIL PROTECTED] wrote:
HTTPD-test is failing.
but it was failing on 2.0.32 version of mod-include as well
Really?? What's the verbose output? It worked fine for me when I
tested
2.0.32... I'll try it again with HEAD tomorrow.
--Cliff
2.0.32 is clean
2.0.32 + CVS-HEAD of mod-include
# testing : GET /modules/include/exec/off/cmd.shtml
# expected: '[an error occurred while processing this directive]'
# received: ''
not ok 8
# testing : GET /modules/include/exec/off/cgi.shtml
# expected: '[an error occurred while processing this directive]'
# received: ''
not ok 30
and we get a core-dump
in handle_exec/mod_cgi
it looks like the ctx has some bad data
(gdb) print *ctx
$6 = {state = PARSED, flags = 11, if_nesting_level = 0, parse_pos = 3,
bytes_parsed = 39, status = 0, output_now = 0, head_start_bucket = 0x0,
head_start_index = 135541272, tag_start_bucket = 0x0,
tag_start_index = 135541272, tail_start_bucket = 0x5, tail_start_index
= 135541272,
combined_tag = 0x24 Address 0x24 out of bounds, curr_tag_pos =
0xbfffe2a0 exec, directive_length = 3221217957, tag_length = 4,
error_str = 0x1f Address 0x1f out of bounds, error_str_override =
0x80944a0 [an error occurred while processing this directive],
time_str = 0x0, time_str_override = 0x8093a95 %A, %d-%b-%Y %H:%M:%S
%Z, pool = 0x0, ssi_tag_brigade = 0x8143730, start_seq_pat = 0x8143ba8,
start_seq = 0x8141b0c , start_seq_len = 134822578, end_seq = 0x5
Address 0x5 out of bounds, re_string = 0x8093aae --, re_result =
0x0}
(gdb)
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
This patch is wrong. Only text/html output is valid for consideration.
Just because no handler has been associated to the handler doesn't mean
we should blindly accept the file. Contrawise, even another handler
(e.g. PHP) could be xbithacked using the new filtering features.
So perhaps this is a better test;
if (!r-content_type || strcmp(r-content_type, text/html)) {
return DECLINED;
}
However, I'm of a mind that we should perhaps allow any text/* types that
the administrator is interested in to be considered for xbit testing.
That would include things like xml content, etc. What about changing the
xbithack enable to something like
XBitHackByType text/html text/xml text/application-xml
or some such? This array could be skimmed in place of this test, and the
absense of a match would decline include's xbit-toggled participation
in serving the request.
Just a thought.
Bill
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 29, 2001 3:34 PM
Subject: cvs commit: httpd-2.0/modules/filters mod_include.c
brianp 01/12/29 13:34:04
Modified:modules/filters mod_include.c
Log:
Fix to make xbithack work again
Revision ChangesPath
1.175 +1 -1 httpd-2.0/modules/filters/mod_include.c
Index: mod_include.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.174
retrieving revision 1.175
diff -u -r1.174 -r1.175
--- mod_include.c 28 Dec 2001 17:44:28 - 1.174
+++ mod_include.c 29 Dec 2001 21:34:04 - 1.175
@@ -3220,7 +3220,7 @@
return DECLINED;
}
-if (!r-handler || strcmp(r-handler, text/html)) {
+if (r-handler strcmp(r-handler, text/html)) {
return DECLINED;
}
}
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
[EMAIL PROTECTED] wrote:
-static int xbithack_handler(request_rec *r)
+static int include_fixup(request_rec *r)
{
#if defined(OS2) || defined(WIN32) || defined(NETWARE)
/* OS/2 dosen't currently support the xbithack. This is being worked on. */
@@ -3201,17 +3201,28 @@
conf = (include_dir_config *) ap_get_module_config(r-per_dir_config,
include_module);
-if (*conf-xbithack == xbithack_off) {
-return DECLINED;
+if (r-handler (strcmp(r-handler, server-parsed) == 0))
+{
+if (!r-content_type || !*r-content_type) {
+r-content_type = text/html;
+}
+r-handler = default-handler;
}
+else
+{
+if (strcmp(r-handler, text/html)) {
+return DECLINED;
+}
+
+if (*conf-xbithack == xbithack_off) {
+return DECLINED;
+}
I see three problems here:
* On OS/2, Win32, and Netware, you're skipping the
check for handler==server-parsed. Is that intentional?
* In the 'strcmp(r-handler, text/html)' expression,
there's no guarantee that r-handler!=NULL
* That same comparison should happen after, not before,
the cheaper *conf-xbithack check
--Brian
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
wrowe 01/12/28 09:44:28 Modified:modules/filters mod_include.c Log: Improvements suggested by Brian Pane, first assure all OS's get to deal with handler 'server-parsed', do the xbithack bit tests before testing it's string values (protected against a null point). And make it [perhaps] more legible. Thanks Brian... this code has been gathering much dust, it's more useful if the world can evaluate it, rather than my pouring over it any further. The negotation code needs a final vetting [this afternoon? I hope!] before it's committed, and then reviewed for completeness [Allows 'prefered' handling independently for both MULTIPLE_CHOICES and NONE_ACCEPTABLE.) Then, off into the MPM again. Oh, there was no trivially legible way, that I saw, to run the xbithack checks before the handler test, and I suspect that we needed to fix the handler always, irrespective of everything else. Since I suspect fewer users actually use xbit, this makes sense to me. Bill
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
If you really want to get anal:
if ((*tag == 'v' strcmp(tag, virtual) == 0)
|| ...
You can avoid a whole strcmp.
woo! (not)
Then again, you'd just be obfuscating the damned code for little overall
gain.
Cheers,
-g
On Fri, Dec 07, 2001 at 03:09:54AM -, [EMAIL PROTECTED] wrote:
brianp 01/12/06 19:09:54
Modified:modules/filters mod_include.c
Log:
When checking for file or virtual as an argument to
!--#, check for virtual first. That's the more likely
case (assuming that people follow the recommendation in
the mod_include documentation that virtual be used in
preference to file), so by checking for virtual first
we can short-circuit out of the conditional after one
strcmp instead of two.
Revision ChangesPath
1.164 +1 -1 httpd-2.0/modules/filters/mod_include.c
Index: mod_include.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.163
retrieving revision 1.164
diff -u -r1.163 -r1.164
--- mod_include.c 2001/12/02 19:16:01 1.163
+++ mod_include.c 2001/12/07 03:09:54 1.164
@@ -1034,7 +1034,7 @@
return (1);
}
}
-if (!strcmp(tag, file) || !strcmp(tag, virtual)) {
+if (!strcmp(tag, virtual) || !strcmp(tag, file)) {
request_rec *rr = NULL;
char *error_fmt = NULL;
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 1 Dec 2001 [EMAIL PROTECTED] wrote: brianp 01/11/30 21:38:23 Modified:.CHANGES modules/filters mod_include.c Log: Fix the handling of SSI directives in which the of the terminating -- is the last byte in a file (previously, the output of the directive was lost in this case). Hey, good catch. :) I just added a test to the test suite so we can avoid having this bug creep back in in the future. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Fri, Sep 07, 2001 at 06:39:17AM -0700, Ryan Bloom wrote: On Thursday 06 September 2001 22:52, [EMAIL PROTECTED] wrote: jerenkrantz01/09/06 22:52:29 Modified:modules/filters mod_include.c Log: Fix error in Netware-specific code. (This really should be an APR function - if it isn't already...) strchr Why should that be in APR? Not specifically that line of code (sorry my context was incredibly bad), but that whole function where that line of code lives (is_only_below): * XXX: Needs to become apr_is_path_relative() test */ static int is_only_below(const char *path) -- justin
Re: cvs commit: httpd-2.0/modules/filters mod_include.c mod_include.h
On 2 Sep 2001 [EMAIL PROTECTED] wrote: jerenkrantz01/09/01 18:09:02 Modified:.CHANGES modules/filters mod_include.c mod_include.h Log: Make mod_include check for BYTE_COUNT_THRESHOLD on a per-bucket basis rather than on a per-character basis. A significant amount of time was spent checking the limit. A better place to check for the threshold is when we read the bucket in not as we read each character in the bucket. If a bucket manages to be 200MB, it is not this code's problem as it is a mere filter. I ran this with the mod_include stuff in httpd-test and it looks good from here. The httpd-test mod_include tests are probably insufficient to test this code. They have lots of recursion and check just about all of the imaginable flavors of tag types, but none of them have really BIG content... not even close to big enough to warrant a brigade split. Maybe we should add a test that includes biggish data from the middle of a biggish file? Somewhere around 32k should be sufficient, I'd guess... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Marc Slemko wrote: On 22 Aug 2001 [EMAIL PROTECTED] wrote: gregames01/08/22 16:12:24 Modified:modules/filters mod_include.c Log: get rid of nuisance log messages due to subrequests failing with EPIPE Erm... forgive me if I haven't followed any discussion on this... but why are subrequests failing with EPIPE, and why is that considered normal? I see EPIPE on FreeBSD when the user hits stop on the browser and goes off to a different site. Greg
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, 2001-08-30 at 18:12, Greg Ames wrote: Marc Slemko wrote: On 22 Aug 2001 [EMAIL PROTECTED] wrote: gregames01/08/22 16:12:24 Modified:modules/filters mod_include.c Log: get rid of nuisance log messages due to subrequests failing with EPIPE Erm... forgive me if I haven't followed any discussion on this... but why are subrequests failing with EPIPE, and why is that considered normal? I see EPIPE on FreeBSD when the user hits stop on the browser and goes off to a different site. Is there any way to log when people 'stop' the downlaod ? Greg -- Ian Holsman Performance Measurement Analysis CNET Networks-415 364-8608
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Ian Holsman wrote: On Thu, 2001-08-30 at 18:12, Greg Ames wrote: Marc Slemko wrote: On 22 Aug 2001 [EMAIL PROTECTED] wrote: gregames01/08/22 16:12:24 Modified:modules/filters mod_include.c Log: get rid of nuisance log messages due to subrequests failing with EPIPE Erm... forgive me if I haven't followed any discussion on this... but why are subrequests failing with EPIPE, and why is that considered normal? I see EPIPE on FreeBSD when the user hits stop on the browser and goes off to a different site. Is there any way to log when people 'stop' the downlaod ? Sure. Set LogLevel info in the config file. That will cause CoreOutputFilter to log write errors, in addition to this code in mod_include. To be consistent, I suppose we should do the same on the read side (ap_getline and ap_get_client_block), but we didn't the last time I looked. Greg
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 25 Aug 2001 [EMAIL PROTECTED] wrote: rbb 01/08/24 22:26:05 Modified:.CHANGES modules/filters mod_include.c Log: Add the ability for mod_include to add the INCLUDES filter if the file is configured for the server-parsed handler. This makes the configuration for .shtml files much easier to understand, and allows mod_include to honor Apache 1.3 config files. Based on Doug MacEachern's patch to PHP to do the same thing. Before I go back and put back all the stuff I took out of the docs on mod_include handlers (;-) could you clarify this a little for me. 1. True/False: Using the handler is perfectly equivalent to using the filter except in the case where more than one filter or handler is in use or a content-type other than text/html is being filtered. The server-parsed handler cannot be used when another handler is in use for the same file (eg. cgi-script). As well, the server-parsed handler will always run first, so if you wish the INCLUDES filter to run after another filter, you should explictly specify the filter chain using SetFilter. Finally, the server-parsed filter will always output HTML, whereas the INCLUDES filter can process any file type and will not change the content-type. 2. What is the recommended way of using mod_include? SetFilter is more flexible, but the FilesMatch thing makes it hard to use and slows down the directory-walk. 3. If you are going to add back the magic-mime-type, please let me know so I don't have to re-re-revise the docs. Joshua.
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 25 Aug 2001 [EMAIL PROTECTED] wrote: rbb 01/08/24 22:26:05 Modified:.CHANGES modules/filters mod_include.c Log: Add the ability for mod_include to add the INCLUDES filter if the file is configured for the server-parsed handler. This makes the configuration for .shtml files much easier to understand, and allows mod_include to honor Apache 1.3 config files. Based on Doug MacEachern's patch to PHP to do the same thing. It still does not honor 1.3's magic text/x-server-parsed-html mime-type, though, right? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Friday 24 August 2001 22:41, Cliff Woolley wrote: On 25 Aug 2001 [EMAIL PROTECTED] wrote: rbb 01/08/24 22:26:05 Modified:.CHANGES modules/filters mod_include.c Log: Add the ability for mod_include to add the INCLUDES filter if the file is configured for the server-parsed handler. This makes the configuration for .shtml files much easier to understand, and allows mod_include to honor Apache 1.3 config files. Based on Doug MacEachern's patch to PHP to do the same thing. It still does not honor 1.3's magic text/x-server-parsed-html mime-type, though, right? No, but that would actually be trivial to add. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
