Re: [patch] adding mpm info to httpd -V
Jeff Trawick wrote: Geoffrey Young wrote: wow, I didn't expect to see this followed up upon. thanks. Server version: Apache/2.1.0-dev Server built: Aug 12 2003 02:25:22 Server's Module Magic Number: 20030213:1 Architecture: 32-bit Server MPM: Prefork too bad ap_show_mpm doesn't list this like other modules :( (prefork.c or worker.c)... the major source file name is what you need in IfModule FOO hmm... odd. I guess I'll take your word for it that doesn't work now (I'm on conference overload and really can't think straight at the moment :) but if it doesn't I'd be happy to try and make it work if there is a consensus that it would be a good thing. the only issue I can see is something mentioned in the original thread on test-dev@ - that attributes like being threaded (or not) are generally more useful than the more simplistic approach of looking for worker.c. http://marc.theaimsgroup.com/?l=apache-test-devm=105795076610731w=2 nevertheless, I'd be happy to do the scut work here and code both up (httpd -V and IfDefine/IfModule stuff) if some agreement can be reached on exactly what it all ought to look like. also, we can axe the display of the MPM directory, right? what good is that? or does the test suite use that? currently, the test suite uses it to infer the mpm (worker, prefork, etc). but I don't see any reason (from the perspective of the perl-framework) that it can't be moved, provided there is some other way to determine the mpm (or relevant underlying mpm attributes). again, thanks for your interest - it is really appreciated. --Geoff
Re: [patch] adding mpm info to httpd -V
wow, I didn't expect to see this followed up upon. thanks.
maybe httpd developers should be stranded in airports more often...
also, several weeks ago somebody was complaining to me about various
things they didn't like about Apache 2... one of the ones I took note of
was having httpd -V display the name of the MPM... so when I saw your
old post I could visualize that to-do getting marked DONE with little
effort on my part :)
:)
Server version: Apache/2.1.0-dev
Server built: Aug 12 2003 02:25:22
Server's Module Magic Number: 20030213:1
Architecture: 32-bit
Server MPM: Prefork
too bad ap_show_mpm doesn't list this like other modules :(
(prefork.c or worker.c)... the major source file name is what you
need in IfModule FOO
hmm... odd. I guess I'll take your word for it that doesn't work now
oh, I see what you mean now - IfModule prefork.c works but httpd -V
doesn't show prefork.c.
very minor issue... forget about it :)
k :)
but if it doesn't I'd be happy to try and make it work if there is a
consensus that it would be a good thing. the only issue I can see is
something mentioned in the original thread on test-dev@ - that
attributes like being threaded (or not) are generally more useful than
the more simplistic approach of looking for worker.c.
http://marc.theaimsgroup.com/?l=apache-test-devm=105795076610731w=2
do whatever Stas said w.r.t. that :)
well, I wasn't taling about the Apache-Test stuff, per se, but rather what
Bill had to say about querying for specific mpm's versus threads in general,
which I think is a very good point - I actually care very little in my code
whether apache is using worker or leader, it's threads or not that's
important (to me anyway :) thus the below...
nevertheless, I'd be happy to do the scut work here and code both up
(httpd -V and IfDefine/IfModule stuff) if some agreement can be
reached on exactly what it all ought to look like.
scratch the Ifdefine issue for now... I don't think it is so
important... at worst, we just have to change the definition of the
MPM_NAME symbol in each MPM's header file
contrary to your advice, I took the initiative and coded IfThreaded
against 2.1. basically, this would allow you to group threaded directives
together. so, instead of this
IfModule worker.c
ThreadsPerChild 5
/IfModule
IfModule perchild.c
MaxThreadsPerChild 5
/IfModule
IfModule prefork.c
MaxClients 5
/IfModule
and so on for every threaded mpm, we could have
IfThreaded
MaxThreadsPerChild 5
/IfThreaded
IfModule prefork.c
MaxClients 5
/IfModule
I toyed with the idea of adding IfNotThreaded to parallel the concept, but
I wasn't sure about it - I figured I'd see how the initial idea went over
first :)
so, patch attached and feedback welcome. I'll work on the real httpd -V
stuff later this afternoon.
--Geoff
Index: server/core.c
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.252
diff -u -r1.252 core.c
--- server/core.c 21 Nov 2003 15:02:04 - 1.252
+++ server/core.c 2 Dec 2003 16:54:26 -
@@ -90,6 +90,7 @@
#include mod_core.h
#include mod_proxy.h
#include ap_listen.h
+#include ap_mpm.h
/* LimitXMLRequestBody handling */
#define AP_LIMIT_UNSET ((long) -1)
@@ -1928,6 +1929,45 @@
}
}
+static const char *start_ifthreaded(cmd_parms *cmd, void *mconfig, const char *arg)
+{
+const char *endp = ap_strrchr_c(arg, '');
+int mpm_query_info;
+apr_status_t retval;
+
+if (endp == NULL) {
+return unclosed_directive(cmd);
+}
+
+arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+
+if (arg[0]) {
+return IfThreaded takes no arguments;
+}
+
+retval = ap_mpm_query(AP_MPMQ_IS_THREADED, mpm_query_info);
+
+if (retval != APR_SUCCESS) {
+return apr_pstrcat(cmd-pool, IfThreaded could not query ,
+ ap_show_mpm(), MPM for threads, NULL);
+}
+
+if (mpm_query_info) {
+ap_directive_t *parent = NULL;
+ap_directive_t *current = NULL;
+const char *retval;
+
+retval = ap_build_cont_config(cmd-pool, cmd-temp_pool, cmd,
+ current, parent, IfThreaded);
+*(ap_directive_t **)mconfig = current;
+return retval;
+}
+else {
+*(ap_directive_t **)mconfig = NULL;
+return ap_soak_end_container(cmd, IfThreaded);
+}
+}
+
/* httpd.conf commands... beginning with the VirtualHost business */
static const char *virtualhost_section(cmd_parms *cmd, void *dummy,
@@ -3073,6 +3113,8 @@
Container for directives based on existance of specified modules),
AP_INIT_TAKE1(IfDefine, start_ifdefine, NULL, EXEC_ON_READ | OR_ALL,
Container for directives based on existance of command line defines),
+AP_INIT_RAW_ARGS(IfThreaded, start_ifthreaded,
Re: [patch] adding mpm info to httpd -V
I'll work on the real httpd -V
stuff later this afternoon.
here is the latest patch. basically, it's the same as what I submitted
before. the differences are those suggested by stas and jeff - make the
AP_MPMQ_STATIC/DYNAMIC wording a bit better and axe the -D APACHE_MPM_DIR=
stuff.
so, the output looks like this for worker and prefork.
Server version: Apache/2.1.0-dev
Server built: Dec 2 2003 03:28:43
Server's Module Magic Number: 20030821:2
Architecture: 32-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with
-D APR_HAS_SENDFILE
[etc]
Server version: Apache/2.1.0-dev
Server built: Dec 2 2003 02:44:12
Server's Module Magic Number: 20030821:2
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with
-D APR_HAS_SENDFILE
[etc]
patch against current 2.1
--Geoff
Index: server/main.c
===
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.140.2.3
diff -u -r1.140.2.3 main.c
--- server/main.c 27 Feb 2003 12:09:44 - 1.140.2.3
+++ server/main.c 2 Dec 2003 19:15:33 -
@@ -85,7 +85,46 @@
* Most significant main() global data can be found in http_config.c
*/
-/* XXX - We should be able to grab the per-MPM settings here too */
+static void show_mpm_settings(void)
+{
+int mpm_query_info;
+apr_status_t retval;
+
+printf(Server MPM: %s\n, ap_show_mpm());
+
+retval = ap_mpm_query(AP_MPMQ_IS_THREADED, mpm_query_info);
+
+if (retval == APR_SUCCESS) {
+printf( threaded: );
+
+if (mpm_query_info == AP_MPMQ_DYNAMIC) {
+printf(yes (variable thread count)\n);
+}
+else if (mpm_query_info == AP_MPMQ_STATIC) {
+printf(yes (fixed thread count)\n);
+}
+else {
+printf(no\n);
+}
+}
+
+retval = ap_mpm_query(AP_MPMQ_IS_FORKED, mpm_query_info);
+
+if (retval == APR_SUCCESS) {
+printf(forked: );
+
+if (mpm_query_info == AP_MPMQ_DYNAMIC) {
+printf(yes (variable process count)\n);
+}
+else if (mpm_query_info == AP_MPMQ_STATIC) {
+printf(yes (fixed process count)\n);
+}
+else {
+printf(no\n);
+}
+}
+}
+
static void show_compile_settings(void)
{
printf(Server version: %s\n, ap_get_server_version());
@@ -98,6 +137,9 @@
* consistent
*/
printf(Architecture: %ld-bit\n, 8 * (long)sizeof(void *));
+
+show_mpm_settings();
+
printf(Server compiled with\n);
#ifdef BIG_SECURITY_HOLE
printf( -D BIG_SECURITY_HOLE\n);
@@ -105,10 +147,6 @@
#ifdef SECURITY_HOLE_PASS_AUTHORIZATION
printf( -D SECURITY_HOLE_PASS_AUTHORIZATION\n);
-#endif
-
-#ifdef APACHE_MPM_DIR
-printf( -D APACHE_MPM_DIR=\%s\\n, APACHE_MPM_DIR);
#endif
#ifdef HAVE_SHMGET
new IfThreaded directive (was Re: [patch] adding mpm info to httpd -V)
IfThreaded MaxThreadsPerChild 5 /IfThreaded This rubs me the wrong way FWIW. oops, sorry :) I think it is best to have all directives for a specific MPM together in one container, and have that container specific to the MPM. well, in some cases I'd certainly agree. however, I think that some if I have a threaded MPM container would be genuinely useful. consider the perl-framework, where the default httpd.conf that is generated has the exact same directives IfModule worker.c StartServers 1 MaxClients 1 MinSpareThreads 1 MaxSpareThreads 1 ThreadsPerChild 1 MaxRequestsPerChild 0 /IfModule for both worker and perchild (and we'd need the same for leader someday I suppose). granted, this kind of duplication might make sense in some circumstances. however, specifically for non-core directives it might be nice to have such a feature. for instance, I can see some value in IfThreaded # if using a threaded mpm load some ultra-slow but threadsafe # version of some ultra-fast but non-threadsafe module /IfThreaded if this kind of thing (someday) applies to, say, php folks, then asking them to duplicate this for each and every possible threaded MPM seems to be asking a bit much. but maybe this is all just academic anyway. thanks for listening nonetheless :) If somebody really wants to do this they could use IfDefine; though it would be easier if the core pre-defined some symbol for use in IfDefine, it is doable as-is. sure. the only reason I didn't go that way was that the docs seem to say that IfDefine only applies to -D command-line parameters - I wasn't familiar enough with the directives to see if there were other, internal -D flags that were also used. --Geoff
Re: new IfThreaded directive (was Re: [patch] adding mpm info to httpd -V)
William A. Rowe, Jr. wrote: At 02:10 PM 12/3/2003, Geoffrey Young wrote: IfThreaded MaxThreadsPerChild 5 /IfThreaded This rubs me the wrong way FWIW. oops, sorry :) I don't care for that container either... but even horrible new ideas are always good when then generate more ideas :) :) If somebody really wants to do this they could use IfDefine; though it would be easier if the core pre-defined some symbol for use in IfDefine, it is doable as-is. sure. the only reason I didn't go that way was that the docs seem to say that IfDefine only applies to -D command-line parameters - I wasn't familiar enough with the directives to see if there were other, internal -D flags that were also used. Actually, such defines might need to be a little more dynamic, but either IfDefine AP_MPM_THREADED would be good, or if we absolutely needed too, we could add IfFeature FOO where features could be registered, by the core or by a loaded module. actually, the other idea I had (going for 0-2 on the horrible new idea theme :) was IfMPM AP_MPMQ_IS_THREADED (or somesuch) as a direct interface to ap_mpm_query, but I thought that outside of threaded/forked there wasn't much other useful config-time information there. but either/any form would probably be valuable to somebody somewhere along the line. Individual IfFoo blocks would pollute the command table significantly, slowing down config parsing by a corresponding amount. ah, good point. --Geoff
Re: [patch] adding mpm info to httpd -V
commited to 2.1-dev... thanks! sure. and thanks for taking the time to shepherd it through. --Geoff
Re: new IfThreaded directive
Actually, such defines might need to be a little more dynamic, but either
IfDefine AP_MPM_THREADED would be good, or if we absolutely
needed too, we could add IfFeature FOO where features could be
registered, by the core or by a loaded module.
to that end, here's a preliminary and rough patch for
IfServerIs !threaded
(substitute 'IfServerIs' for whatever you please - I'm not so good with names).
I couldn't think of anything else to implement other than threadedness right
now, but I guess we're discussing the concept at the moment so that's ok. I
did almost start on
IfServerIs = 2.1
but I thought that the new container semantics probably wouldn't go over
well (and I wasn't entirely convinced that was a worthy thing to test at
config time).
--Geoff
Index: server/core.c
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.252
diff -u -r1.252 core.c
--- server/core.c 21 Nov 2003 15:02:04 - 1.252
+++ server/core.c 4 Dec 2003 19:57:35 -
@@ -90,6 +90,7 @@
#include mod_core.h
#include mod_proxy.h
#include ap_listen.h
+#include ap_mpm.h
/* LimitXMLRequestBody handling */
#define AP_LIMIT_UNSET ((long) -1)
@@ -1928,6 +1929,60 @@
}
}
+static const char *start_ifserver(cmd_parms *cmd, void *mconfig,
+ const char *arg)
+{
+const char *endp = ap_strrchr_c(arg, '');
+int not = 0;
+int soak = 1;
+
+if (endp == NULL) {
+return unclosed_directive(cmd);
+}
+
+arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+
+if (arg[0] == '!') {
+not = 1;
+arg++;
+}
+
+/* custom server properties - expand at will
+ * currently supports:
+ * threaded (true if MPM is threaded)
+ */
+
+if (strcasecmp(arg, threaded) == 0) {
+int mpm_query_info;
+
+apr_status_t retval = ap_mpm_query(AP_MPMQ_IS_THREADED, mpm_query_info);
+
+if (retval != APR_SUCCESS) {
+return apr_pstrcat(cmd-pool, IfServerIs could not query ,
+ ap_show_mpm(), MPM for threads, NULL);
+}
+
+if ((!not mpm_query_info) || (not !mpm_query_info)) {
+soak = 0;
+}
+}
+
+if (soak) {
+*(ap_directive_t **)mconfig = NULL;
+return ap_soak_end_container(cmd, IfServerIs);
+}
+else {
+ap_directive_t *parent = NULL;
+ap_directive_t *current = NULL;
+const char *retval;
+
+retval = ap_build_cont_config(cmd-pool, cmd-temp_pool, cmd,
+ current, parent, IfServerIs);
+*(ap_directive_t **)mconfig = current;
+return retval;
+}
+}
+
/* httpd.conf commands... beginning with the VirtualHost business */
static const char *virtualhost_section(cmd_parms *cmd, void *dummy,
@@ -3073,6 +3128,8 @@
Container for directives based on existance of specified modules),
AP_INIT_TAKE1(IfDefine, start_ifdefine, NULL, EXEC_ON_READ | OR_ALL,
Container for directives based on existance of command line defines),
+AP_INIT_TAKE1(IfServerIs, start_ifserver, NULL, EXEC_ON_READ | OR_ALL,
+ Container for directives based on existance of a various server properties),
AP_INIT_RAW_ARGS(DirectoryMatch, dirsection, (void*)1, RSRC_CONF,
Container for directives affecting resources located in the
specified directories),
Re: [Patch] Hook to allow insertion of filters during error processing
Paul J. Reder wrote: This patch addresses PRs 24884 and 25123. Please see my note at http://marc.theaimsgroup.com/?l=apache-httpd-devm=106947094322141w=2 for a full explanation of the problem with code references. I've griped a bit before about having default_handler make conditional GET decisions, and this is probably another instance where having ap_meets_conditions in it's own filter could avoid inevitable problems. I think we were supposed to discuss this at the hackathon, but it never happened. I'm up for laying out my issues if the list is interested in them and reevaluating the whole meets_conditions/filter_init stuff. --Geoff
[PATCH] catching malformed container directives
hi all...
currently, all core container directives have an issue (albeit a minor one)
- they require an argument in practice but are allowed to proceed without
one during configuration.
for example
IfModule
does not currently throw an error. instead, the config is allowed to
proceed, soaking up the container.
while the subsequent behavior seems ok, to me the lack of feedback for a
malformed directive is less than ideal, especially if users are using a
template to configure apache - something like this
IfModule [% mymod %]
or whatever would silently proceed if the substitution variable was
unpopulated, which is a tricky thing to track down
anyway, attached is a patch that makes IfModule, IfDefine, Directory,
Location, Files (and their regex counterparts), Limit, LimitExcept,
and VirtualHost containers fail if no arguments are specified.
--Geoff
Index: server/core.c
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.252
diff -u -r1.252 core.c
--- server/core.c 21 Nov 2003 15:02:04 - 1.252
+++ server/core.c 8 Dec 2003 15:58:10 -
@@ -1552,6 +1552,24 @@
return NULL;
}
+/*
+ * Report a missing-'' syntax error.
+ */
+static char *unclosed_directive(cmd_parms *cmd)
+{
+return apr_pstrcat(cmd-pool, cmd-cmd-name,
+directive missing closing '', NULL);
+}
+
+/*
+ * Report a missing args in 'Foo ' syntax error.
+ */
+static char *missing_container_arg(cmd_parms *cmd)
+{
+return apr_pstrcat(cmd-pool, cmd-cmd-name,
+directive requires additional arguments, NULL);
+}
+
AP_CORE_DECLARE_NONSTD(const char *) ap_limit_section(cmd_parms *cmd,
void *dummy,
const char *arg)
@@ -1566,6 +1584,10 @@
return err;
}
+if (!limited_methods[0]) {
+return missing_container_arg(cmd);
+}
+
while (limited_methods[0]) {
char *method = ap_getword_conf(cmd-pool, limited_methods);
int methnum;
@@ -1610,15 +1632,6 @@
#define USE_ICASE 0
#endif
-/*
- * Report a missing-'' syntax error.
- */
-static char *unclosed_directive(cmd_parms *cmd)
-{
-return apr_pstrcat(cmd-pool, cmd-cmd-name,
-directive missing closing '', NULL);
-}
-
static const char *dirsection(cmd_parms *cmd, void *mconfig, const char *arg)
{
const char *errmsg;
@@ -1642,6 +1655,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
if (!arg) {
if (thiscmd-cmd_data)
return DirectoryMatch block must specify a path;
@@ -1736,6 +1753,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
cmd-path = ap_getword_conf(cmd-pool, arg);
cmd-override = OR_ALL|ACCESS_CONF;
@@ -1795,6 +1816,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
cmd-path = ap_getword_conf(cmd-pool, arg);
/* Only if not an .htaccess file */
if (!old_path) {
@@ -1860,6 +1885,10 @@
arg++;
}
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
found = ap_find_linked_module(arg);
if ((!not found) || (not !found)) {
@@ -1911,6 +1940,10 @@
arg++;
}
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
defined = ap_exists_config_define(arg);
if ((!not defined) || (not !defined)) {
ap_directive_t *parent = NULL;
@@ -1948,6 +1981,10 @@
}
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
/* FIXME: There's another feature waiting to happen here -- since you
can now put multiple addresses/names on a single VirtualHost
Re: [PATCH] catching malformed container directives
André Malo wrote: * Geoffrey Young [EMAIL PROTECTED] wrote: anyway, attached is a patch that makes IfModule, IfDefine, I'd like to keep IfDefine possible. Simply because it's a very efficient way to comment a whole part out (reliably, since one cannot specify an empty -D argument). And it's in use out there. ah, cool. thanks. I wasn't aware that people were taking advantage of this feature :) so, ok, any other exceptions? this was just an idea, so I won't push it or anything - it just felt weird :) --Geoff
Re: [Patch] Hook to allow insertion of filters during error processing
Jeff Trawick wrote: Geoffrey Young wrote: I've griped a bit before about having default_handler make conditional GET decisions, and this is probably another instance where having ap_meets_conditions in it's own filter could avoid inevitable problems. I'm up for laying out my issues if the list is interested in them and reevaluating the whole meets_conditions/filter_init stuff. please do ok. it's been outlined before in the archives in bits and pieces, but here is essentially the problem... with the advent of output filters, content handlers (such as default_handler) can't possibly have enough information to accurately determine whether a 304 is warranted. the issue is, of course, that later filters might alter content to the point where the 304 would have been wrong. the way Apache chose to work around this was to add the filter_init callback to allow filters to add processing just prior to content generation. presumably, this is where filters could call ap_update_mtime or whatnot to add their information in the conditional GET calculations. the decision to use filter_init over putting ap_meets_conditions logic in its own filter was made in order to let the (presumably) most popular case - default_handler + mod_deflate - be as fast as possible, now, I wasn't present for that discussion (some of which happened on #irc) but that's how it looks like it happened to me from the archives. I certainly don't mean to misrepresent things if I'm not entirely accurate - please speak up if I've missed something. so, for the most part how things are currently works for core. however, the first time I tried to use output filters with conditional GET logic I saw that the idea fell short. just using current 2.1 core you can see for yourself how filter_init is suboptimal. here's an Apache-Test tarball you can view or run if you like (keep in mind it's 2.1 specific) http://perl.apache.org/~geoff/bug-ap_meets_conditions.tar.gz basically, what this tarball shows is that the filter_init won't run when the content-type is set during content-generation and the filter is added via AddOutputFilterByType. while this particular example might seem a bit abnormal, it was one I could quickly see that didn't involve anything other than core modules. the basic problem, however, isn't in AddOutputFilterByType, it's in the entire idea that conditional GET logic can be fully accommodated via filter_init processing. basically, filters that rely on decisions made by content-generators are left in a catch-22: if they add logic to the request via filter_init they risk that logic being wrong due to later decisions, or if they postpone the logic until after content-generation they risk never having it called at all. hopefully, this kind of makes sense to at least some people. personally, the only thing that makes sense to me is moving conditonal GET logic to it's own filter, similar to Content-Length I suppose. yes, it would slow down the server for default+deflate responses, but I guess that would be the trade-off for allowing people to properly control the cache-correctness of their responses (among other things). I have the *feeling* that Paul's patch is a very safe fix (i.e., no regression for 2.0.x) for the missing Expires on 304, and in general I like the idea of a module getting the chance to add a filter on the error path, but I have no awareness of other problems caused by the present meets-conditions handling. I haven't looked at this particular issue to know whether the two ideas are mutually exclusive, but I can't help but wonder if the problem would go away if meets_conditons were held back until the very last moment. we might be talking about two different things, though :) anyway, as usual, thanks for listening. --Geoff
Re: [Patch] Hook to allow insertion of filters during error processing
Stas Bekman wrote: Geoffrey Young wrote: [...] hopefully, this kind of makes sense to at least some people. personally, the only thing that makes sense to me is moving conditonal GET logic to it's own filter, similar to Content-Length I suppose. yes, it would slow down the server for default+deflate responses, but I guess that would be the trade-off for allowing people to properly control the cache-correctness of their responses (among other things). What if you use a plain connection filter to manipulate the headers and remove it the moment the output headers have been sent? If understand correctly you want this filter to be triggered the moment the first bit of the response body is sent (if any). Could this be then done by a response body filter which will then immediately remove itself from the filters stack? maybe - I don't really understand why you would need to remove it. but whether it's an intermediate filter that can be removed or whatever is secondary - until people buy into whether conditional GET logic ought to be in a filter at all (and thus after _all_ content-generating-and-manipulating filter have run) there's really no point in figuring out an implementation. that is, probably - if people just want to see code, then I guess we can work up something, too :) --Geoff
Re: [PATCH] catching malformed container directives
Geoffrey Young wrote:
André Malo wrote:
* Geoffrey Young [EMAIL PROTECTED] wrote:
anyway, attached is a patch that makes IfModule, IfDefine,
I'd like to keep IfDefine possible. Simply because it's a very efficient
way to comment a whole part out (reliably, since one cannot specify an
empty -D argument). And it's in use out there.
ok, here is a new patch that excludes IfDefine .
also included is a patch (that applies on top of the other one) that fixes
broken Limit containers. currently
Limit GET
does not throw an error (note the missing final '').
if people don't like the first idea but would like to fix Limit I can do
that separately as well.
HTH
--Geoff
Index: server/core.c
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.252
diff -u -r1.252 core.c
--- server/core.c 21 Nov 2003 15:02:04 - 1.252
+++ server/core.c 9 Dec 2003 15:08:01 -
@@ -1552,6 +1552,24 @@
return NULL;
}
+/*
+ * Report a missing-'' syntax error.
+ */
+static char *unclosed_directive(cmd_parms *cmd)
+{
+return apr_pstrcat(cmd-pool, cmd-cmd-name,
+directive missing closing '', NULL);
+}
+
+/*
+ * Report a missing args in 'Foo ' syntax error.
+ */
+static char *missing_container_arg(cmd_parms *cmd)
+{
+return apr_pstrcat(cmd-pool, cmd-cmd-name,
+directive requires additional arguments, NULL);
+}
+
AP_CORE_DECLARE_NONSTD(const char *) ap_limit_section(cmd_parms *cmd,
void *dummy,
const char *arg)
@@ -1566,6 +1584,10 @@
return err;
}
+if (!limited_methods[0]) {
+return missing_container_arg(cmd);
+}
+
while (limited_methods[0]) {
char *method = ap_getword_conf(cmd-pool, limited_methods);
int methnum;
@@ -1610,15 +1632,6 @@
#define USE_ICASE 0
#endif
-/*
- * Report a missing-'' syntax error.
- */
-static char *unclosed_directive(cmd_parms *cmd)
-{
-return apr_pstrcat(cmd-pool, cmd-cmd-name,
-directive missing closing '', NULL);
-}
-
static const char *dirsection(cmd_parms *cmd, void *mconfig, const char *arg)
{
const char *errmsg;
@@ -1642,6 +1655,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
if (!arg) {
if (thiscmd-cmd_data)
return DirectoryMatch block must specify a path;
@@ -1736,6 +1753,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
cmd-path = ap_getword_conf(cmd-pool, arg);
cmd-override = OR_ALL|ACCESS_CONF;
@@ -1795,6 +1816,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
cmd-path = ap_getword_conf(cmd-pool, arg);
/* Only if not an .htaccess file */
if (!old_path) {
@@ -1860,6 +1885,10 @@
arg++;
}
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
found = ap_find_linked_module(arg);
if ((!not found) || (not !found)) {
@@ -1948,6 +1977,10 @@
}
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
/* FIXME: There's another feature waiting to happen here -- since you
can now put multiple addresses/names on a single VirtualHost
--- server/core.c 2003-12-09 10:29:09.0 -0500
+++ server/core.c 2003-12-09 10:29:59.0 -0500
@@ -1574,7 +1574,8 @@
void *dummy,
const char *arg)
{
-const char *limited_methods = ap_getword(cmd-pool, arg, '');
+const char *endp = ap_strrchr_c(arg, '');
+const char *limited_methods;
void *tog = cmd-cmd-cmd_data;
apr_int64_t limited = 0;
const char *errmsg;
@@ -1584,6 +1585,12 @@
return err;
}
+if (endp == NULL) {
+return unclosed_directive(cmd);
+}
+
+limited_methods = apr_pstrndup(cmd-pool, arg, endp - arg);
+
if (!limited_methods[0]) {
return missing_container_arg(cmd);
}
Re: [PATCH] catching malformed container directives
William A. Rowe, Jr. wrote: At 09:36 AM 12/9/2003, Geoffrey Young wrote: André Malo wrote: I'd like to keep IfDefine possible. Simply because it's a very efficient way to comment a whole part out (reliably, since one cannot specify an empty -D argument). And it's in use out there. ok, here is a new patch that excludes IfDefine . Now you have me thinking. For Apache 2.1 (perhaps 2.0) I'd like to see that particular nonsense go away. I sympathize with André's observation that it's useful, but what he wants to do can be accomplished with IfDefine NEVER DangerousDirective /IfDefine which serves the same purpose, but it much more legible. not to speak for andre, but he pointed out to me on irc that what he was after was an IfDefine that could not be overridden with -D, and I suppose -DNEVER would expose the config block. or are you suggesting a literal IfDefine NEVER as a special case? one thing I suggested was perhaps using IfDefine 0, but he pointed out that -D0 works (but -D doesn't). so maybe we can make -D0 not work as well and keep with something that feels programmatically familiar. You point out that containers that expect args (e.g. not Perl blocks) can be very difficult to debug in any sort of dynamic (mod_macro) sort of config environment. that was part of the rationale, yes. the other being that it just didn't seem to make sense that the directive arguments were required in the docs (and in practice) but that illegally formed configs were allowed to pass without so much as a warning. But also consider that many conf rewriting tools could probably crack under the strain of parsing such IfFoo containers, if they specify no argument. it must be that it's post-dinner here and I need a rejolt of coffee, but I don't understand that :) On the balance, for 2.1 forward we should disallow IfDefine . It's a coin toss to me if we continue to accept them in 2.0 - so I'd argue the principle of least surprise. Disallow in 2.1, but continue to allow in 2.0 IfDefine . either way, my patches were against 2.1, so if the community agrees to 2.1 inclusion then I suppose 2.0 backport gets voted on afterward. also included is a patch (that applies on top of the other one) that fixes broken Limit containers. currently Limit GET does not throw an error (note the missing final ''). That would be goodness! :) if you'd like that as a separate issue before the IfFoo stuff is resolved (as it's probably less controversial :) I'll whip up a new patch - just let me know. --Geoff
Re: cvs commit: httpd-2.0/server core.c
[EMAIL PROTECTED] wrote: trawick 2003/12/10 14:40:33 Modified:.CHANGES server core.c Log: Fix Limit and LimitExcept parsing to require a closing '' in the initial container. PR:25414 Submitted by: Geoffrey Young geoff apache.org] Reviewed by: Jeff Trawick excellent, thanks. and sorry about the space problems in the patch. I usually use attachments but didn't see the upload field in the bug form, which I'll use from now on. --Geoff
Re: [PATCH] catching malformed container directives
Now you have me thinking. For Apache 2.1 (perhaps 2.0) I'd like to see that
particular nonsense go away. I sympathize with André's observation that it's
useful, but what he wants to do can be accomplished with
IfDefine NEVER
DangerousDirective
/IfDefine
which serves the same purpose, but it much more legible.
not to speak for andre, but he pointed out to me on irc that what he was
after was an IfDefine that could not be overridden with -D, and I suppose
-DNEVER would expose the config block. or are you suggesting a literal
IfDefine NEVER as a special case? one thing I suggested was perhaps
using IfDefine 0, but he pointed out that -D0 works (but -D doesn't).
so maybe we can make -D0 not work as well and keep with something that feels
programmatically familiar.
yet another try :)
this patch makes 'httpd -D0' invalid, thus making IfDefine 0 a special
define case that is guaranteed to evaluate to false. the rest remains as
before - arguments are enforced across all containers.
it actually feels a bit strange to fail the command line args without some
kind of message, so I suppose it might be wiser to implement this in core.c
instead, tossing an error message to the error_log if 0 is both caught and
defined. but for the moment I guess I'm just seeing if the idea is
appealing, after which the implementation can be adjusted as required.
--Geoff
Index: server/core.c
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.253
diff -u -r1.253 core.c
--- server/core.c 10 Dec 2003 22:40:33 - 1.253
+++ server/core.c 11 Dec 2003 04:06:57 -
@@ -1561,6 +1561,15 @@
directive missing closing '', NULL);
}
+/*
+ * Report a missing args in 'Foo ' syntax error.
+ */
+static char *missing_container_arg(cmd_parms *cmd)
+{
+return apr_pstrcat(cmd-pool, cmd-cmd-name,
+directive requires additional arguments, NULL);
+}
+
AP_CORE_DECLARE_NONSTD(const char *) ap_limit_section(cmd_parms *cmd,
void *dummy,
const char *arg)
@@ -1582,6 +1591,10 @@
limited_methods = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!limited_methods[0]) {
+return missing_container_arg(cmd);
+}
+
while (limited_methods[0]) {
char *method = ap_getword_conf(cmd-pool, limited_methods);
int methnum;
@@ -1649,6 +1662,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
if (!arg) {
if (thiscmd-cmd_data)
return DirectoryMatch block must specify a path;
@@ -1743,6 +1760,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
cmd-path = ap_getword_conf(cmd-pool, arg);
cmd-override = OR_ALL|ACCESS_CONF;
@@ -1802,6 +1823,10 @@
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
cmd-path = ap_getword_conf(cmd-pool, arg);
/* Only if not an .htaccess file */
if (!old_path) {
@@ -1867,6 +1892,10 @@
arg++;
}
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
found = ap_find_linked_module(arg);
if ((!not found) || (not !found)) {
@@ -1918,6 +1947,10 @@
arg++;
}
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
+
defined = ap_exists_config_define(arg);
if ((!not defined) || (not !defined)) {
ap_directive_t *parent = NULL;
@@ -1955,6 +1988,10 @@
}
arg = apr_pstrndup(cmd-pool, arg, endp - arg);
+
+if (!arg[0]) {
+return missing_container_arg(cmd);
+}
/* FIXME: There's another feature waiting to happen here -- since you
can now put multiple addresses/names on a single VirtualHost
Index: server/main.c
===
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.148
diff -u -r1.148 main.c
--- server/main.c 4 Dec 2003 03:05:42 - 1.148
+++ server/main.c 11 Dec 2003 04:06:57 -
@@ -505,11 +505,17 @@
break;
case 'D':
-new = (char **)apr_array_push(ap_server_config_defines);
-*new = apr_pstrdup(pcommands, optarg);
-/* Setting -D DUMP_VHOSTS is equivalent to setting -S */
-if (strcmp(optarg, DUMP_VHOSTS) == 0)
-configtestonly = 1;
+/* disallow -D0 so that IfDefine 0 cannot be overridden */
+if (strcmp(optarg, 0)) {
+new = (char **)apr_array_push(ap_server_config_defines);
+*new = apr_pstrdup(pcommands, optarg);
+/* Setting -D DUMP_VHOSTS is
Re: [Patch] Hook to allow insertion of filters during error processing
the way Apache chose to work around this was to add the filter_init callback to allow filters to add processing just prior to content generation. presumably, this is where filters could call ap_update_mtime or whatnot to add their information in the conditional GET calculations. the decision to use filter_init over putting ap_meets_conditions logic in its own filter was made in order to let the (presumably) most popular case - default_handler + mod_deflate - be as fast as possible, This isn't entirely true. Yes, there is the filter-init callback, but the other accepted solution is to create a handler/filter hybrid (such as the cache code). The handler participates in making sure all the pieces and parts required to make a good decision are present, then the filter acts on the final decision. The handler can insert the desired filter. I can see how that might work in some (even most) circumstances. but requiring filters to rewrite things like default_handler just because it makes it difficult to behave properly is asking a bit much. but default_handler and mod_autoindex are the only core things I can think of at the moment :) I believe the decision was also motivated by a desire to make the 304 as streamlined as possible. Why run a 304 through *all* of the filters and associated processing if the effort was just to be thrown away and a 304 sent. precisely because you can't possibly know whether the 304 is valid until every potentially-content-altering filter has run - because we're offering a filtering API (as opposed to only supporting core filters), each third party filter can use _absolutely whatever criteria it wants_ to decide whether it will alter the content. I could give an(other) example, but I fear people on the list are tiring of this already, so I'll give it a rest :) I agree that this is a potential pitfall. Perhaps not all situations can be addressed by a handler/filter hybrid. But moving the meets_condition logic to a filter doesn't address all of what my fix does. ... My feeling right now is to commit my patch and address the meets_condition question as a seperate issue. yes, I'm terribly sorry that the two got jumbled together, thus distracting potential reviewers away from your work - it's entirely my fault. so, I'll end it here :) --Geoff
new ETag supression/weakening API
hi all
this is something I've been meaning to do for a while. as mod_include
demonstrates, output filters will sometimes be required to remove the ETag
header generated by content handlers, depending on how much they alter the
content. the current methodology is to set a no-etag note, which is
recognized by the header filter.
what I wanted to do was expand this a bit and offer an ETag weakening API -
it should be easy to see that while some (most) output filters alter content
dramatically, others might only alter content bitwise but not semantically.
in these cases a weak etag is acceptable (and probably preferred to no etag
at all, from my reading of the specs). under the current state of affairs,
there is no way for an output filter to intercept ETag generation other than
to specify its removal.
the attached patch (etag_api.patch) offers two new functions.
ap_weaken_etag() guarantees a weak ETag header will be generated if one is
generated at all. the decision to generate one is still given to
ap_set_etag(). ap_supress_etag() is just a formalization of the no-etag
idiom into a real API.
fwiw, I've also included patches against mod_case_filter and the
perl-framework, which is what I used for my testing (so you can try it
yourself).
--Geoff
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.84
diff -u -r1.84 http_protocol.h
--- include/http_protocol.h 3 Feb 2003 17:52:53 - 1.84
+++ include/http_protocol.h 12 Dec 2003 16:57:17 -
@@ -196,11 +196,25 @@
AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak);
/**
- * Set the E-tag outgoing header
+ * Set the ETag outgoing header
* @param The current request
* @deffunc void ap_set_etag(request_rec *r)
*/
AP_DECLARE(void) ap_set_etag(request_rec *r);
+
+/**
+ * Supress the ETag outgoing header
+ * @param The current request
+ * @deffunc void ap_supress_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_supress_etag(request_rec *r);
+
+/**
+ * Force generation of a weak ETag header
+ * @param The current request
+ * @deffunc void ap_weaken_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r);
/**
* Set the last modified time for the file being sent
Index: modules/filters/mod_include.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.292
diff -u -r1.292 mod_include.c
--- modules/filters/mod_include.c 10 Dec 2003 02:30:20 - 1.292
+++ modules/filters/mod_include.c 12 Dec 2003 16:57:33 -
@@ -3584,7 +3584,7 @@
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
-apr_table_setn(f-r-notes, no-etag, );
+ap_supress_etag(f-r);
return OK;
}
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.473
diff -u -r1.473 http_protocol.c
--- modules/http/http_protocol.c16 Nov 2003 02:09:13 - 1.473
+++ modules/http/http_protocol.c12 Dec 2003 16:57:37 -
@@ -2693,7 +2693,7 @@
* note it for the header-sender to ignore.
*/
if (etag_bits ETAG_NONE) {
-apr_table_setn(r-notes, no-etag, omit);
+ap_supress_etag(r);
return ;
}
@@ -2711,7 +2711,13 @@
* we send a weak tag instead of a strong one, since it could
* be modified again later in the second, and the validation
* would be incorrect.
+ *
+ * additional criteria for a weak tag is if force_weak is true
+ * or ap_weaken_etag() was called
*/
+
+force_weak = (force_weak || apr_table_get(r-notes, weak-etag));
+
if ((r-request_time - r-mtime (1 * APR_USEC_PER_SEC))
!force_weak) {
weak = NULL;
@@ -2831,6 +2837,37 @@
}
apr_table_setn(r-headers_out, ETag, etag);
+}
+
+/*
+ * Take steps to ensure that current and future-generated ETag
+ * headers are marked as weak.
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r)
+{
+const char *etag = apr_table_get(r-headers_out, ETag);
+
+/* if the ETag header exists and is not already marked
+ * as weak, mark it now
+ */
+if ((etag = apr_table_get(r-headers_out, ETag))
+strncmp(etag, ETAG_WEAK, strlen(ETAG_WEAK))) {
+
+ etag = apr_pstrcat(r-pool, ETAG_WEAK, etag, NULL);
+
+ apr_table_setn(r-headers_out, ETag, etag);
+}
+
+/* make sure future calls to ap_make_etag() produce weak tags */
+apr_table_setn(r-notes, weak-etag, yes);
+}
+
+/*
+ * Formalize ETag header supression.
+ */
+AP_DECLARE(void) ap_supress_etag(request_rec *r)
+{
+apr_table_setn(r-notes, no-etag, omit);
}
static int
Re: new ETag supression/weakening API
Paul J. Reder wrote:
I just have a quick comment based on some work I did recently.
You should check for the ETag value in both headers_out locations.
It is actually a bit more likely that the ETag will be in
r-err_headers_out
rather than r-headers_out, but it could be in either.
hmm, I had thought about that. ap_meets_conditions only checks headers_out,
so I figured it was safe.
but you bring up an interesting point. outside of this patch, if somebody
manually populates an ETag header in err_headers_out then it won't be caught
by the no-etag stuff we already depend on. I'll account for that as well.
Your patch should
look in both locations and stick the altered value back where you found it.
yes, good idea. and it brings up another good point. the weaken API only
worked for tags generated with ap_make_etag - manual ETag entries could pass
through to the client unaltered if they happen after the new ap_weaken_etag
call. so, some additional logic is required in the header filter to take
care of those cases.
The other comment I have is that in the ap_weaken_etag function you call
etag = apr_table_get(r-headers_out, ETag) twice (once in the decl/init
and once in the conditional).
drat. refactoring leakage :)
Other than that, I'm not enough of an expert on tags and weakness...
from what
I do know this looks good, but some doc for the function might be useful to
help folks know when they might be legally able to weaken a tag.
sure. I placed a brief bit and a pointer to the docs in httpd.h, in
addition to expanding the comments in the weaken function more. is there
someplace else that's appropriate?
thanks for your input - new patch attached.
--Geoff
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.84
diff -u -r1.84 http_protocol.h
--- include/http_protocol.h 3 Feb 2003 17:52:53 - 1.84
+++ include/http_protocol.h 12 Dec 2003 19:03:00 -
@@ -196,11 +196,28 @@
AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak);
/**
- * Set the E-tag outgoing header
+ * Set the ETag outgoing header
* @param The current request
* @deffunc void ap_set_etag(request_rec *r)
*/
AP_DECLARE(void) ap_set_etag(request_rec *r);
+
+/**
+ * Supress the ETag outgoing header
+ * @param The current request
+ * @deffunc void ap_supress_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_supress_etag(request_rec *r);
+
+/**
+ * Force generation of a weak ETag header.
+ * weak tags are allowed when the resource is semantically
+ * equivalent to a prior version, even though the content
+ * bits are different. see RFC-2616 13.3.3
+ * @param The current request
+ * @deffunc void ap_weaken_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r);
/**
* Set the last modified time for the file being sent
Index: modules/filters/mod_include.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.292
diff -u -r1.292 mod_include.c
--- modules/filters/mod_include.c 10 Dec 2003 02:30:20 - 1.292
+++ modules/filters/mod_include.c 12 Dec 2003 19:03:14 -
@@ -3584,7 +3584,7 @@
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
-apr_table_setn(f-r-notes, no-etag, );
+ap_supress_etag(f-r);
return OK;
}
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.473
diff -u -r1.473 http_protocol.c
--- modules/http/http_protocol.c16 Nov 2003 02:09:13 - 1.473
+++ modules/http/http_protocol.c12 Dec 2003 19:03:18 -
@@ -1631,9 +1631,22 @@
/*
* Now remove any ETag response header field if earlier processing
* says so (such as a 'FileETag None' directive).
+ *
+ * be sure to clear err_headers_out, in case some non-core module
+ * populates it manually.
*/
if (apr_table_get(r-notes, no-etag) != NULL) {
apr_table_unset(r-headers_out, ETag);
+apr_table_unset(r-err_headers_out, ETag);
+}
+
+/* speaking of err_headers_out, if an ETag is added to either
+ * table manually, the ap_make_etag/ap_weaken_etag link is
+ * broken. do one final sweep to make sure we weaken the ETag
+ * no matter where it originated
+ */
+if (apr_table_get(r-notes, weak-etag) != NULL) {
+ap_weaken_etag(r);
}
/* determine the protocol and whether we should use keepalives. */
@@ -2693,7 +2706,7 @@
* note it for the header-sender to ignore.
*/
if (etag_bits ETAG_NONE) {
-apr_table_setn(r-notes, no-etag, omit);
+
Re: new ETag supression/weakening API
thanks for your input - new patch attached. bah, that's not right either. I'll refactor it again and fix some of the messed up logic over the weekend. sorry to waste the bandwidth. --Geoff
Re: new ETag supression/weakening API
William A. Rowe, Jr. wrote: Just a quick tangent on weak ETags let's say I have a transform to convert (charset-any) into utf-8 format... and based on a browser string, conditionally insert that filter. It's a straightforward (predictable) transform so that it retains any strong ETag, but it isn't the identity. Wouldn't it make more sense to concat a suffix onto the existing ETag? keeping an already existing (strong) ETag (such as one generated by default_handler) seems suspect to me. because the response now involves content altering logic, there is the chance that a bug in the logic could render the response bits different before and after bug discovery. if the ETag ends up being the same (even weakened) it seems like it would be wrong. so, adding to or otherwise predictably altering the previously generated ETag seems to make sense (to me :), so long as it takes into account code versions or whatever else effects the response translation (config directives or whatnot). the criterion that makes me most nervous when I play with ETags is the requirement that An entity tag MUST be unique across all versions of all entities associated with a particular resource which feels very difficult to get right if you're not in control of the entire tag. fwiw, the need for the ap_weaken_etag API I was suggesting stemmed from simple HTML scrubbing, such as changing strong to b. it's probably rare that people will want or need to use it, but it will be nice to have if they need it. --Geoff
Re: new ETag supression/weakening API
hi again...
ok, I think I've worked out all the issues - attached is a new patch with
logic (and spelling :) errors hopefully worked out. also included is a
patch against the perl-framework for testing if you so choose.
one of the issues that needed working out was dealing with multiple ETag
headers. my original idea was to have ap_weaken_etag guarantee that ETag
headers would be weak. with ETag headers entering err_headers_out via a
third party, there exists the possibility that the server would send
multiple ETag headers for a single request. while I'm not sure if this is
actually legal, I can't find anything that says it isn't. so, the header
table is iterated and all ETag headers adjusted. oh, and if there is an
easier way to alter table entries with multi-valued keys other than creating
a temporary table, I'm all ears.
anyway, thanks for your patience in reviewing. all told it's more logic
than I wanted or expected but it's probably valuable nonetheless, even if it
requires more work.
--Geoff
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.85
diff -u -r1.85 http_protocol.h
--- include/http_protocol.h 12 Dec 2003 17:03:58 - 1.85
+++ include/http_protocol.h 15 Dec 2003 20:47:56 -
@@ -203,11 +203,28 @@
AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak);
/**
- * Set the E-tag outgoing header
+ * Set the ETag outgoing header
* @param The current request
* @deffunc void ap_set_etag(request_rec *r)
*/
AP_DECLARE(void) ap_set_etag(request_rec *r);
+
+/**
+ * Supress the ETag response header
+ * @param The current request
+ * @deffunc void ap_suppress_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_suppress_etag(request_rec *r);
+
+/**
+ * Force generation of weak ETag headers.
+ * weak tags are allowed when the resource is semantically
+ * equivalent to a prior version, even though the content
+ * bits are different. see RFC-2616 13.3.3
+ * @param The current request
+ * @deffunc void ap_weaken_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r);
/**
* Set the last modified time for the file being sent
Index: modules/filters/mod_include.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.292
diff -u -r1.292 mod_include.c
--- modules/filters/mod_include.c 10 Dec 2003 02:30:20 - 1.292
+++ modules/filters/mod_include.c 15 Dec 2003 20:48:09 -
@@ -3584,7 +3584,7 @@
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
-apr_table_setn(f-r-notes, no-etag, );
+ap_suppress_etag(f-r);
return OK;
}
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.474
diff -u -r1.474 http_protocol.c
--- modules/http/http_protocol.c12 Dec 2003 17:03:58 - 1.474
+++ modules/http/http_protocol.c15 Dec 2003 20:48:13 -
@@ -1560,6 +1560,55 @@
}
}
+typedef struct {
+request_rec *r;
+apr_table_t *etag_table;
+} weaken_struct;
+
+#define ETAG_WEAK W/
+
+/* apr_table_do iterator for weakening ETag header fields */
+static int make_etags_weak(weaken_struct *w, const char *key, const char *val)
+{
+if (strncmp(val, ETAG_WEAK, strlen(ETAG_WEAK))) {
+apr_table_addn(w-etag_table, key,
+ apr_pstrcat(w-r-pool, ETAG_WEAK, val, NULL));
+}
+else {
+apr_table_addn(w-etag_table, key, val);
+}
+
+return 1;
+}
+
+/*
+ * weaken all the ETag headers in r-headers_out.
+ *
+ * there might be multiple ETag headers to weaken, specifically
+ * if both r-headers_out and r-err_headers out contained
+ * entries that were merged via ap_http_header_filter. perhaps
+ * there are legitimate reasons for multiple ETag headers as
+ * well?
+ */
+static void weaken_etags(request_rec *r)
+{
+if (apr_table_get(r-headers_out, ETag)) {
+
+apr_table_t *etag_table = apr_table_make(r-pool, 2);
+weaken_struct w;
+w.r = r;
+w.etag_table = etag_table;
+
+apr_table_do((int (*) (void *, const char *, const char *))
+ make_etags_weak, (void *) w, r-headers_out,
+ ETag, NULL);
+
+apr_table_unset(r-headers_out, ETag);
+r-headers_out = apr_table_overlay(r-pool, r-headers_out,
+ etag_table);
+}
+}
+
typedef struct header_filter_ctx {
int headers_sent;
} header_filter_ctx;
@@ -1612,7 +1661,7 @@
* later attempts to set or unset a given fieldname might be bypassed.
*/
if (!apr_is_empty_table(r-err_headers_out)) {
-
Re: new ETag supression/weakening API
Roy T. Fielding wrote: one of the issues that needed working out was dealing with multiple ETag headers. my original idea was to have ap_weaken_etag guarantee that ETag headers would be weak. with ETag headers entering err_headers_out via a third party, there exists the possibility that the server would send multiple ETag headers for a single request. while I'm not sure if this is actually legal, I can't find anything that says it isn't. RFC 2616, section 3.11, BNF does not allow multiple ETag header fields. excellent, thanks. I think you need to work on making this patch more efficient -- it is doing too much work for an activity in the critical path of servicing a request. yes, it certainly felt that way. but now that you've cleared up the multiple header bit, lots of that excess can get cleaned up. BTW, an entity tag does not identify the entity -- it merely acts as a key for cache and range request handling. right. and what I was trying to do was make it possible for content-altering filters to handle that key a bit more intelligently than just removing it altogether. the situation I initially had in mind was when a filter was bitwise altering the content but not the semantics of it, an HTML scrubber perhaps. in this case, it seems that allowing the default ETag is wrong, but that removing it can be avoided (thus keeping to the spirit that ETags should be sent if feasable). granted, the circumstances are probably very rare that filters would behave that way. are you saying that weakening the ETag is the wrong behavior here? if so I'm kinda wasting my time (as well as everyone else's). If a filter consistently produces the same content, then it should not modify the entity tag (the routine that arranges the filters must do that if needed). hmm... I don't see how that would work given the current API. but it does seem like the API could be a bit better. perhaps filters could supply criteria that ap_make_etag can draw from when the time comes. is that what you had in mind? anyway, thanks for taking the time to clear things up and offer a bit of advice. I appreciate it. --Geoff
Re: [PATCH] catching malformed container directives
hi all just following up on this to see if the interested parties have given the issue any more thought. if there is still some dis-harmony around the IfDefine case then I'm happy to keep posting alternatives until a solution is reached that everyone can live with. otherwise, if there isn't sufficient interest in changing the current (somewhat broken) core container args parsing, I'll just lop it off of my todo list. --Geoff (current patch viewable from http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9526) Geoffrey Young wrote: Now you have me thinking. For Apache 2.1 (perhaps 2.0) I'd like to see that particular nonsense go away. I sympathize with André's observation that it's useful, but what he wants to do can be accomplished with IfDefine NEVER DangerousDirective /IfDefine which serves the same purpose, but it much more legible. not to speak for andre, but he pointed out to me on irc that what he was after was an IfDefine that could not be overridden with -D, and I suppose -DNEVER would expose the config block. or are you suggesting a literal IfDefine NEVER as a special case? one thing I suggested was perhaps using IfDefine 0, but he pointed out that -D0 works (but -D doesn't). so maybe we can make -D0 not work as well and keep with something that feels programmatically familiar. yet another try :) this patch makes 'httpd -D0' invalid, thus making IfDefine 0 a special define case that is guaranteed to evaluate to false. the rest remains as before - arguments are enforced across all containers. it actually feels a bit strange to fail the command line args without some kind of message, so I suppose it might be wiser to implement this in core.c instead, tossing an error message to the error_log if 0 is both caught and defined. but for the moment I guess I'm just seeing if the idea is appealing, after which the implementation can be adjusted as required. --Geoff
thread/process termination APIs?
hi again... I was wondering if much thought has been given to official thread and/or process termination APIs. I tried sloshing through the archives but didn't find much discussion. I understand why ap_child_terminate was removed (or at least I think I do). however, having something like ap_thread_terminate or ap_process_terminate would be a really nice for gracefully knocking off large, runaway processes (or threads, assuming you could accurately determine such an event) where the mpm allowed for it - lots of shops I know of depended on this functionality for performance reasons in 1.3 so being able to offer something similar in 2.0 would be nice. --Geoff
Re: why open_logs/post_config hooks are run only for the main server?
William A. Rowe, Jr. wrote:
It is almost worth a totally different hook entry point (before
post_config) such as vhost_init which *would* be called per-vhost
(starting from the main server config and working through the list.)
I have several modules with the for (s=_server; s; s = s-next) paradigm
that would be easier to read using such a hook. Although I'm generally
against adding more cpu-intensive hook phases, this is an init-only hook
so it's much easier to implement.
I had some spare time and thought I could help with the grunt work - my try
at a patch attached.
HTH
--Geoff
Index: include/http_config.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_config.h,v
retrieving revision 1.103
diff -u -r1.103 http_config.h
--- include/http_config.h 31 Oct 2003 22:00:38 - 1.103
+++ include/http_config.h 22 Dec 2003 17:04:39 -
@@ -1001,6 +1001,17 @@
/**
+ * Run the vhost_init function for each module
+ * @param pconf The config pool
+ * @param plog The logging streams pool
+ * @param ptemp The temporary pool
+ * @param s The virtual host to initialize
+ * @return OK or DECLINED on success anything else is a error
+ */
+AP_DECLARE_HOOK(int,vhost_init,(apr_pool_t *pconf,apr_pool_t *plog,
+apr_pool_t *ptemp,server_rec *s))
+
+/**
* Run the post_config function for each module
* @param pconf The config pool
* @param plog The logging streams pool
Index: server/config.c
===
RCS file: /home/cvspublic/httpd-2.0/server/config.c,v
retrieving revision 1.167
diff -u -r1.167 config.c
--- server/config.c 11 Oct 2003 06:37:45 - 1.167
+++ server/config.c 22 Dec 2003 17:04:40 -
@@ -109,6 +109,7 @@
APR_HOOK_STRUCT(
APR_HOOK_LINK(header_parser)
APR_HOOK_LINK(pre_config)
+ APR_HOOK_LINK(vhost_init)
APR_HOOK_LINK(post_config)
APR_HOOK_LINK(open_logs)
APR_HOOK_LINK(child_init)
@@ -124,6 +125,11 @@
(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp),
(pconf, plog, ptemp), OK, DECLINED)
+
+AP_IMPLEMENT_HOOK_RUN_ALL(int, vhost_init,
+ (apr_pool_t *pconf, apr_pool_t *plog,
+ apr_pool_t *ptemp, server_rec *s),
+ (pconf, plog, ptemp, s), OK, DECLINED)
AP_IMPLEMENT_HOOK_RUN_ALL(int, post_config,
(apr_pool_t *pconf, apr_pool_t *plog,
Index: server/main.c
===
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.149
diff -u -r1.149 main.c
--- server/main.c 10 Dec 2003 13:43:14 - 1.149
+++ server/main.c 22 Dec 2003 17:04:41 -
@@ -444,6 +444,7 @@
const char *temp_error_log = NULL;
process_rec *process;
server_rec *server_conf;
+server_rec *s; /* vhost-specific server_rec */
apr_pool_t *pglobal;
apr_pool_t *pconf;
apr_pool_t *plog; /* Pool of log streams, reset _after_ each read of conf */
@@ -649,6 +656,14 @@
destroy_and_exit_process(process, 1);
}
+for (s = server_conf; s; s = s-next) {
+if ( ap_run_vhost_init(pconf, plog, ptemp, s) != OK) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
+ 0, NULL, Unable to initialize virtual hosts\n);
+destroy_and_exit_process(process, 1);
+ }
+}
+
if ( ap_run_post_config(pconf, plog, ptemp, server_conf) != OK) {
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR, 0,
NULL, Configuration Failed\n);
@@ -692,6 +707,14 @@
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
0, NULL, Unable to open logs\n);
destroy_and_exit_process(process, 1);
+}
+
+for (s = server_conf; s; s = s-next) {
+if ( ap_run_vhost_init(pconf, plog, ptemp, s) != OK) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
+ 0, NULL, Unable to initialize virtual hosts\n);
+destroy_and_exit_process(process, 1);
+}
}
if (ap_run_post_config(pconf, plog, ptemp, server_conf) != OK) {
Index: modules/experimental/mod_example.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/experimental/mod_example.c,v
retrieving revision 1.44
diff -u -r1.44 mod_example.c
--- modules/experimental/mod_example.c 13 Dec 2003 15:41:33 - 1.44
+++ modules/experimental/mod_example.c 22 Dec 2003 17:12:18 -
@@ -859,6 +859,25 @@
}
/*
+ * This routine is called to do virtual host initialization.
+ * It is invoked just before the post_config phase.
+ *
+ * The return
Re: why open_logs/post_config hooks are run only for the main server?
William A. Rowe, Jr. wrote: Only question below is should this hook always run before or after the post config hook? My gut says after post config. just going from what you had said earlier: It is almost worth a totally different hook entry point (before post_config) such as vhost_init which *would* be called per-vhost (starting from the main server config and working through the list.) :) but now that I think about it, if post_config is where module init stuff lives, then it feels right to have vhosts initialized prior to that, since the new hook seems like more of a config-type thing. but it's not hard to see how someone could have the opposite viewpoint, so no strong feelings here either way. the only other (unrelated) thought that I had was that it might be more self-documenting to name it host_init rather than vhost_init, keeping it very obvious that it runs for the main server as well as any configured vhosts. --Geoff
Re: why open_logs/post_config hooks are run only for the main server?
No... the default server is still a server. But you make an interesting point, that
certain percolation occurs in the post config. I suppose I would want that to
happen before my handlers dealt with the per-vhost settings, and I would not
want the changes I make to that global server to percolate any longer in the
host_init phase. So running the post config, then the host init phases makes
sense for that paradigm.
cool. just to keep up, new patches attached.
But let's imagine a scenario of dynamic vhosts, al la htaccess. It would actually
be quite cool in one thread to create such a dynamic host (propagate from some
given vhost for example.) This host init hook would still be run against the thread
specific dynamic server record. We could get away with some really cool things
that way :) Discuss ...
you'd need a way to direct requests directly to that specific thread,
though, right? anyway, what kind of cool things? I can see some advantage
to this oven in prefork, where you might want to dedicate a pool of children
to specific clients, but I don't really see the threaded advantages. but I
generally don't get threaded environments anyway :)
--Geoff
Index: include/http_config.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_config.h,v
retrieving revision 1.103
diff -u -r1.103 http_config.h
--- include/http_config.h 31 Oct 2003 22:00:38 - 1.103
+++ include/http_config.h 23 Dec 2003 16:49:03 -
@@ -1001,6 +1001,17 @@
/**
+ * Run the host_init function for each module
+ * @param pconf The config pool
+ * @param plog The logging streams pool
+ * @param ptemp The temporary pool
+ * @param s The (virtual) host to initialize
+ * @return OK or DECLINED on success anything else is a error
+ */
+AP_DECLARE_HOOK(int,host_init,(apr_pool_t *pconf,apr_pool_t *plog,
+ apr_pool_t *ptemp,server_rec *s))
+
+/**
* Run the post_config function for each module
* @param pconf The config pool
* @param plog The logging streams pool
Index: server/main.c
===
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.149
diff -u -r1.149 main.c
--- server/main.c 10 Dec 2003 13:43:14 - 1.149
+++ server/main.c 23 Dec 2003 16:49:03 -
@@ -444,6 +444,7 @@
const char *temp_error_log = NULL;
process_rec *process;
server_rec *server_conf;
+server_rec *s; /* host-specific server_rec */
apr_pool_t *pglobal;
apr_pool_t *pconf;
apr_pool_t *plog; /* Pool of log streams, reset _after_ each read of conf */
@@ -655,6 +656,14 @@
destroy_and_exit_process(process, 1);
}
+for (s = server_conf; s; s = s-next) {
+if ( ap_run_host_init(pconf, plog, ptemp, s) != OK) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
+ 0, NULL, Unable to initialize hosts\n);
+destroy_and_exit_process(process, 1);
+ }
+}
+
apr_pool_destroy(ptemp);
for (;;) {
@@ -698,6 +707,14 @@
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
0, NULL, Configuration Failed\n);
destroy_and_exit_process(process, 1);
+}
+
+for (s = server_conf; s; s = s-next) {
+if ( ap_run_host_init(pconf, plog, ptemp, s) != OK) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
+ 0, NULL, Unable to initialize hosts\n);
+destroy_and_exit_process(process, 1);
+}
}
apr_pool_destroy(ptemp);
Index: server/config.c
===
RCS file: /home/cvspublic/httpd-2.0/server/config.c,v
retrieving revision 1.167
diff -u -r1.167 config.c
--- server/config.c 11 Oct 2003 06:37:45 - 1.167
+++ server/config.c 23 Dec 2003 16:49:03 -
@@ -109,6 +109,7 @@
APR_HOOK_STRUCT(
APR_HOOK_LINK(header_parser)
APR_HOOK_LINK(pre_config)
+ APR_HOOK_LINK(host_init)
APR_HOOK_LINK(post_config)
APR_HOOK_LINK(open_logs)
APR_HOOK_LINK(child_init)
@@ -124,6 +125,11 @@
(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp),
(pconf, plog, ptemp), OK, DECLINED)
+
+AP_IMPLEMENT_HOOK_RUN_ALL(int, host_init,
+ (apr_pool_t *pconf, apr_pool_t *plog,
+ apr_pool_t *ptemp, server_rec *s),
+ (pconf, plog, ptemp, s), OK, DECLINED)
AP_IMPLEMENT_HOOK_RUN_ALL(int, post_config,
(apr_pool_t *pconf, apr_pool_t *plog,
Index: modules/experimental/mod_example.c
===
RCS file:
Re: log_error_core escaping change broke things
Stas, we have closed a well known and remotely exploitable security leak. This
goes straight over comfort. If you don't like it, provide an alternative
solution. Just nagging or trying to talk the problem away doesn't help.
is creating a compile-time flag to disable the new-default behavior a simple
solution that might make everyone happy?
--Geoff
Index: server/main.c
===
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.152
diff -u -r1.152 main.c
--- server/main.c 5 Jan 2004 10:37:25 - 1.152
+++ server/main.c 7 Jan 2004 20:29:43 -
@@ -277,6 +277,10 @@
#ifdef SERVER_CONFIG_FILE
printf( -D SERVER_CONFIG_FILE=\ SERVER_CONFIG_FILE \\n);
#endif
+
+#ifdef UNESCAPED_ERROR_LOG
+printf( -D UNESCAPED_ERROR_LOG\n);
+#endif
}
static void destroy_and_exit_process(process_rec *process,
Index: server/log.c
===
RCS file: /home/cvspublic/httpd-2.0/server/log.c,v
retrieving revision 1.138
diff -u -r1.138 log.c
--- server/log.c1 Jan 2004 13:26:23 - 1.138
+++ server/log.c7 Jan 2004 20:29:44 -
@@ -402,7 +402,7 @@
const request_rec *r, apr_pool_t *pool,
const char *fmt, va_list args)
{
-char errstr[MAX_STRING_LEN], scratch[MAX_STRING_LEN];
+char errstr[MAX_STRING_LEN];
apr_size_t len, errstrlen;
apr_file_t *logf = NULL;
const char *referer;
@@ -539,16 +539,27 @@
}
errstrlen = len;
+#ifdef UNESCAPED_ERROR_LOG
+len += apr_vsnprintf(errstr + len, MAX_STRING_LEN - len, fmt, args);
+
+if (r (referer = apr_table_get(r-headers_in, Referer))) {
+len += apr_snprintf(errstr + len, MAX_STRING_LEN - len,
+, referer: %s, referer);
+}
+#else
if (apr_vsnprintf(scratch, MAX_STRING_LEN - len, fmt, args)) {
+char scratch[MAX_STRING_LEN];
len += ap_escape_errorlog_item(errstr + len, scratch,
MAX_STRING_LEN - len);
}
if ( r (referer = apr_table_get(r-headers_in, Referer))
ap_escape_errorlog_item(scratch, referer, MAX_STRING_LEN - len)) {
+char scratch[MAX_STRING_LEN];
len += apr_snprintf(errstr + len, MAX_STRING_LEN - len,
, referer: %s, scratch);
}
+#endif
/* NULL if we are logging to syslog */
if (logf) {
Re: log_error_core escaping change broke things
André Malo wrote: * Stas Bekman [EMAIL PROTECTED] wrote: Though since it really affects any logging it probably should be called UNESCAPED_LOGGING or similar. And probably a similar patch applied to 1.3. It only affects error logging. that was my intent. What do you mean by any logging? I can live with it in general (wouldn't make the scratch definition twice). sorry, that was me trying to make it compile under -Werror with my only passable C skills :) However, is it wise to add a configure option for it? how do you mean? I was trying to make it just a compile time option, similar to -DBIG_SECURITY_HOLE (which seems to me a bigger risk than this). do you mean to require users to change a define in the code itself? --Geoff
Re: cvs commit: httpd-2.0/server log.c
+ *) Allow unescaped error logs via compile time switch + -DAP_ERROR_LOG_UNESCAPED. + [Geoffrey Young geoff modperlcookbook.org, André Malo] ah, cool :) if it's all the same to everyone, I actually like joe's suggested -DUNSAFE_LOG_ESCAPING (or some error_log derivitave) a bit better - undoing the default should raise some eyebrows. --Geoff
Re: cvs commit: httpd-2.0 STATUS
* unescaped error logs seem to be essential for some folks
backport -DAP_UNSAFE_ERROR_LOG_UNESCAPED to 2.0 and 1.3
server/log.c: r1.139, r1.140
-+1: nd
++1: nd, stas
should this get another vote, I have patches for 2.0 and 1.3 ready.
--Geoff
Index: server/log.c
===
RCS file: /home/cvspublic/httpd-2.0/server/log.c,v
retrieving revision 1.127.2.6
diff -u -r1.127.2.6 log.c
--- server/log.c1 Jan 2004 13:30:43 - 1.127.2.6
+++ server/log.c14 Jan 2004 15:19:00 -
@@ -401,7 +401,10 @@
const request_rec *r, apr_pool_t *pool,
const char *fmt, va_list args)
{
-char errstr[MAX_STRING_LEN], scratch[MAX_STRING_LEN];
+char errstr[MAX_STRING_LEN];
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+char scratch[MAX_STRING_LEN];
+#endif
apr_size_t len, errstrlen;
apr_file_t *logf = NULL;
const char *referer;
@@ -538,15 +541,28 @@
}
errstrlen = len;
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
if (apr_vsnprintf(scratch, MAX_STRING_LEN - len, fmt, args)) {
len += ap_escape_errorlog_item(errstr + len, scratch,
MAX_STRING_LEN - len);
}
+#else
+len += apr_vsnprintf(errstr + len, MAX_STRING_LEN - len, fmt, args);
+#endif
if ( r (referer = apr_table_get(r-headers_in, Referer))
- ap_escape_errorlog_item(scratch, referer, MAX_STRING_LEN - len)) {
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+ ap_escape_errorlog_item(scratch, referer, MAX_STRING_LEN - len)
+#endif
+) {
len += apr_snprintf(errstr + len, MAX_STRING_LEN - len,
-, referer: %s, scratch);
+, referer: %s,
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+scratch
+#else
+referer
+#endif
+);
}
/* NULL if we are logging to syslog */
Index: src/main/http_log.c
===
RCS file: /home/cvspublic/apache-1.3/src/main/http_log.c,v
retrieving revision 1.98
diff -u -r1.98 http_log.c
--- src/main/http_log.c 1 Jan 2004 13:32:54 - 1.98
+++ src/main/http_log.c 16 Jan 2004 16:15:14 -
@@ -313,11 +313,15 @@
const server_rec *s, const request_rec *r,
const char *fmt, va_list args)
{
-char errstr[MAX_STRING_LEN], scratch[MAX_STRING_LEN];
+char errstr[MAX_STRING_LEN];
size_t len;
int save_errno = errno;
FILE *logf;
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+char scratch[MAX_STRING_LEN];
+#endif
+
if (s == NULL) {
/*
* If we are doing stderr logging (startup), don't log messages that are
@@ -445,10 +449,14 @@
}
#endif
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
if (ap_vsnprintf(scratch, sizeof(scratch) - len, fmt, args)) {
len += ap_escape_errorlog_item(errstr + len, scratch,
sizeof(errstr) - len);
}
+#else
+len += ap_vsnprintf(errstr + len, sizeof(errstr) - len, fmt, args);
+#endif
/* NULL if we are logging to syslog */
if (logf) {
Re: [PATCH] Location block speed up
...which is the same way we enable mod_status and mod_info. The key thing here is that the URIs to access a Location enabled handler do not map to the filesystem, so the directory walk is a waste of cycles. So what can we do about it? isn't that what map_to_storage is for? http://marc.theaimsgroup.com/?l=apache-httpd-devm=106506407907008w=2 additional issues of interest can be found here http://marc.theaimsgroup.com/?l=apache-httpd-devm=106451559226339w=2 HTH --Geoff
Re: [PATCH] Location block speed up
Bill Stoddard wrote: mod_status and mod_info both are enabled via Location containers. mod_status never DECLINEs if it is the handler. mod_info DECLINEs if the method isn't GET. Let me see what happens if I send mod_info some other method. My not so well formed thoughts are that if a module claims it should handle a request based on a SetHandler directive in a Location directive, the server should not allow that handler to DECLINE the request. Putting it another way, if the handler claims the request then DECLINEs, the server should prevent other handlers from attempting to serve the request. I've brought this up before, but if you shortcut translation, how do you handle cases where r-handler is set after translation/map_to_storage. that is, just because at the start of a request Location /foo refers to a non-static resource, doesn't mean that assumption won't change. see mod_dav and mod_include, both of which set r-handler during the fixup phase. [EMAIL PROTECTED] wrote: A map_to_storage hook needs to know when to allow the directory walk and when not to. I think I see what you mean. so, perhaps the answer to my question above is that, with your patch, if modules expect to set r-handler under certain conditions, then they ought to install their own map_to_storage handler to handle those conditions as well? --Geoff
formalizing 'no-etag' note
hi all...
well, I haven't quite figured out all the weak etag issues yet, but just the
other day someone asked how to remove ETag headers from a default-handler
response.
so, I thought I'd re-submit the ap_suppress_etag() part as a formal API
wrapper around
apr_table_setn(r-notes, no-etag, omit);
if only to make the feature a bit more self-documenting.
--Geoff
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.86
diff -u -r1.86 http_protocol.h
--- include/http_protocol.h 1 Jan 2004 13:26:16 - 1.86
+++ include/http_protocol.h 23 Jan 2004 15:56:34 -
@@ -203,11 +203,18 @@
AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak);
/**
- * Set the E-tag outgoing header
+ * Set the ETag outgoing header
* @param The current request
* @deffunc void ap_set_etag(request_rec *r)
*/
AP_DECLARE(void) ap_set_etag(request_rec *r);
+
+/**
+ * Suppress the ETag outgoing header
+ * @param The current request
+ * @deffunc void ap_suppress_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_suppress_etag(request_rec *r);
/**
* Set the last modified time for the file being sent
Index: modules/filters/mod_include.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.296
diff -u -r1.296 mod_include.c
--- modules/filters/mod_include.c 13 Jan 2004 22:12:02 - 1.296
+++ modules/filters/mod_include.c 23 Jan 2004 15:56:50 -
@@ -3539,7 +3539,7 @@
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
-apr_table_setn(f-r-notes, no-etag, );
+ap_suppress_etag(f-r);
return OK;
}
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.476
diff -u -r1.476 http_protocol.c
--- modules/http/http_protocol.c16 Jan 2004 20:11:12 - 1.476
+++ modules/http/http_protocol.c23 Jan 2004 15:56:53 -
@@ -1635,7 +1635,8 @@
/*
* Now remove any ETag response header field if earlier processing
- * says so (such as a 'FileETag None' directive).
+ * says so. this could have happened via a direct API call to
+ * ap_suppress_etag() or a directive like 'FileETag None'
*/
if (apr_table_get(r-notes, no-etag) != NULL) {
apr_table_unset(r-headers_out, ETag);
@@ -2700,7 +2701,7 @@
* note it for the header-sender to ignore.
*/
if (etag_bits ETAG_NONE) {
-apr_table_setn(r-notes, no-etag, omit);
+ap_suppress_etag(r);
return ;
}
@@ -2838,6 +2839,14 @@
}
apr_table_setn(r-headers_out, ETag, etag);
+}
+
+/*
+ * keep ETag headers from the response
+ */
+AP_DECLARE(void) ap_suppress_etag(request_rec *r)
+{
+apr_table_setn(r-notes, no-etag, omit);
}
static int parse_byterange(char *range, apr_off_t clength,
fixing ITERATE/ITERATE2 wrt DECLINE_CMD
does anyone have any objections to applying this in 2.1? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22299 --Geoff
Re: new core module mod_version
André Malo wrote: That has been long time on my todo (hello Stas! :-) There's a new module I'd like to add to the core distribution. It makes use of the new httpd version query function (ap_get_server_revision). It introduces IfVersion containers, where you can depend your config on a particular httpd version. I consider this as a very useful feature for test suites and big companies, which typically switch smoothly between versions. this is a nice idea. I had even started in on it myself not too long ago :) I've uploaded the module here: http://cvs.apache.org/~nd/mod_version.c. The are some more detailed descriptions at the beginning of the file after the license. What do you think? cool :) --Geoff
Re: new core module mod_version
Well, thank you both. If there come no objections, I'll commit it these days into modules/metadata. actually, while I still like the idea, does it make sense to broaden the scope of the module a bit? I had started a discussion on IfThreaded, which turned into more of an IfServerIs ... idea could ping ap_mpm_query and other things. the main objection, IIRC, was that people weren't too interested in adding more containers to core. so, if mod_version were to be renamed to something like mod_server_attribute (ok, too long, but I'm bad with names), then perhaps it could (eventually) be expanded to hold not only IfVersion but whatever other IfFOO server attributes people are intersted in. I still think that a container which could demark a threaded server would be valuable, even if the discussion died :) probably not what you had in mind, though - just a thought. if you like the idea, though, I'd commit it as is, just with a different name - no need to wait on other things first. --Geoff
Re: cvs commit: httpd-2.0 CHANGES
hi all... hopefully I followed protocol here correctly wrt 2.1, but someone please feel free to set me straight if I didn't. I also closed the PR. --Geoff [EMAIL PROTECTED] wrote: geoff 2004/01/30 11:43:39 Modified:.CHANGES Log: Keep focus of ITERATE and ITERATE2 on the current module when the module chooses to return DECLINE_CMD for the directive. PR: 22299
Re: cvs commit: httpd-2.0 CHANGES
That's fine. The only comment I have is that you should commit the change to CHANGES and the core change at the same time rather than splitting them into two separate commits. yeah, I always try to do that, but my cvs client doesn't ever seem to pick up on the Changes file (for any of my repositories) when I do a multi-file update. I'll see if I can remedy that before I do things again :) --Geoff
ErrorDocument mime type
hi all
it's come up a few times for me (and other users) that string-type
ErrorDocuments and custom responses default to text/html. however, lots
of people are using servers for xml-only content and want to be able to set
custom responses to simple xml strings without the overhead of a full
internal redirect. for example, anyway.
here is one way around the issue (if you agree that it's an issue :). the
attached patch:
- adds a new ErrorDocumentType directive, for setting the mime type of
string custom responses and ErrorDocuments
- removes the hard-coded charset previously set for all string-based errors
- respects AddDefaultCharset settings for both default (still text/html)
and ErrorDocumentType-set types.
so, the big change is that, by default, simple strings no longer have a
charset sent with them unless the server is specifically configured that
way. regardless of the rest of the patch, it seems this ought to be the
default behavior anyway, but I guess it hasn't been an issue in the past.
anyway, just an idea. comments or other suggestions appreciated.
--Geoff
Index: include/http_core.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_core.h,v
retrieving revision 1.77
diff -u -r1.77 http_core.h
--- include/http_core.h 1 Jan 2004 13:26:16 - 1.77
+++ include/http_core.h 3 Feb 2004 15:41:07 -
@@ -553,6 +553,12 @@
unsigned int enable_sendfile : 2; /* files in this dir can be mmap'ed */
unsigned int allow_encoded_slashes : 1; /* URLs may contain %2f w/o being
* pitched indiscriminately */
+
+/* if the ErrorDocument or custom response is a plain string (not an
+ * internal or external redirect), the MIME type to use for the string
+ */
+const char *error_type;
+
} core_dir_config;
/* Per-server core configuration */
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.476
diff -u -r1.476 http_protocol.c
--- modules/http/http_protocol.c16 Jan 2004 20:11:12 - 1.476
+++ modules/http/http_protocol.c3 Feb 2004 15:41:27 -
@@ -2334,8 +2334,14 @@
int status = r-status;
int idx = ap_index_of_response(status);
char *custom_response;
+const char *error_type;
+core_dir_config *dcfg;
const char *location = apr_table_get(r-headers_out, Location);
+dcfg = (core_dir_config *)ap_get_module_config(r-per_dir_config,
+ core_module);
+
+
/* At this point, we are starting the response over, so we have to reset
* this value.
*/
@@ -2395,7 +2401,15 @@
r-content_languages = NULL;
r-content_encoding = NULL;
r-clength = 0;
-ap_set_content_type(r, text/html; charset=iso-8859-1);
+
+if (dcfg-error_type == NULL) {
+error_type = ap_make_content_type(r, text/html);
+}
+else {
+/* ErrorDocumentType */
+error_type = ap_make_content_type(r, dcfg-error_type);
+}
+ap_set_content_type(r, error_type);
if ((status == HTTP_METHOD_NOT_ALLOWED)
|| (status == HTTP_NOT_IMPLEMENTED)) {
Index: server/core.c
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.257
diff -u -r1.257 core.c
--- server/core.c 25 Jan 2004 22:03:38 - 1.257
+++ server/core.c 3 Feb 2004 15:41:44 -
@@ -182,6 +182,8 @@
conf-enable_sendfile = ENABLE_SENDFILE_UNSET;
conf-allow_encoded_slashes = 0;
+conf-error_type = NULL;
+
return (void *)conf;
}
@@ -449,6 +451,10 @@
conf-allow_encoded_slashes = new-allow_encoded_slashes;
+if (new-error_type) {
+conf-error_type = new-error_type;
+}
+
return (void*)conf;
}
@@ -3121,6 +3127,9 @@
AP_INIT_TAKE1(DocumentRoot, set_document_root, NULL, RSRC_CONF,
Root directory of the document tree),
AP_INIT_TAKE2(ErrorDocument, set_error_document, NULL, OR_FILEINFO,
+ Change responses for HTTP errors),
+AP_INIT_TAKE1(ErrorDocumentType, ap_set_string_slot_lower,
+ (void *)APR_OFFSETOF(core_dir_config, error_type), OR_FILEINFO,
Change responses for HTTP errors),
AP_INIT_RAW_ARGS(AllowOverride, set_override, NULL, ACCESS_CONF,
Controls what groups of directives can be configured by per-directory
Re: cvs commit: httpd-2.0/modules/metadata mod_expires.c
That introduced a warning to the 2.0 build: mod_expires.c: In function `set_expiresbytype': mod_expires.c:365: warning: passing arg 1 of `ap_strrchr' discards qualifiers from pointer target type the next version up in HEAD contains the fix http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/metadata/mod_expires.c?r1=1.45r2=1.46only_with_tag=MAIN --Geoff
Re: cvs commit: httpd-2.0/modules/metadata mod_expires.c
yes, I was just about to post this :) :) (thank goodness for cron) and -Werror :) so I guess that makes at least two who build nightly. just out of curiosity, is anyone else? --Geoff
Re: FileSystem v.s. Other Resources [was configurable Location?]
Let's do this in 2.1 by splitting out the file system, and if the filesystem module isn't handling a request, it won't be serving content but also won't be invoking the directory walk or stat-ing files. this all sounds kinda interesting, and similar to the way auth has been set up in 2.1 - more directives and modules, but more flexibility and power. Oh last observation - it should become (in 2.1) nearly impossible for folks to just bork around with the contents of r-filename and r-finfo, first by stripping them from the request rec, and second by providing an API to the filesystem module that lets another module link into another file. That API would prevent module authors from bypassing the filesystem module's internal security. this has come up before, and I'd love to see an API that prevents accidental disagreement between r-filename and r-finfo (for one). IIRC, there was supposed to be some discussion at the hackathon about this, but it sounds like I didn't miss it :) --Geoff
Re: SetEnv and other modules
Brian Akins wrote:
Any reason Apache does not allow this:
SetEnv ORIGIN 1234
SetEnv doesn't really set the environment by itself. by itself, it sticks
ORIGIN in the subprocess_env table during fixups. later modules (like
mod_cgi) make calls during content-generation to propagate the
subprocess_env table to the environment. this is important because...
RewriteRule /this.html
http://that.domain.com/this.html?origin=${ENV:ORIGIN} [R,L]
RewriteRule operates during the translation phase. at this point, SetEnv
settings are still private to mod_env and not part of either the
subprocess_env table or %ENV.
HTH
--Geoff
Re: [Patch] ap_soak_end_container and argument-less Block directives
Philippe M. Chiasson wrote:
As can be seen with this simple config file:
IfDefine not-defined
Location
/Location
/IfDefine
$ httpd -f broken.conf
Syntax error on line 1 of broken.conf:
Expected /Location but saw /Location
Location with no arguments is a bug in and of itself and ought to be
fixed. there was some discussion on this fairly recently
http://marc.theaimsgroup.com/?l=apache-httpd-devm=107089922728099w=2
the rest of the thread goes on about how IfDefine is a popular hack, and
positions split on whether or not that is a good thing.
my most recent patch is here
http://marc.theaimsgroup.com/?l=apache-httpd-devm=107111613530796w=2
which still sits kinda funny with me but at least tries to please everybody :)
so, comments here welcome :)
It's only a problem with Blocks without argument, i.e. Perl blocks
in mod_perl land.
probably ought to be fixed, then :)
+if (*args == '\0' cmd_name[strlen(cmd_name) - 1] == '') {
+cmd_name[strlen(cmd_name) - 1] = '\0';
+}
+
seems reasonable enough, but one of the more hard-core parser-people ought
to take a look at it too.
--Geoff
Re: [Patch] ap_soak_end_container and argument-less Block directives
Philippe M. Chiasson wrote: As can be seen with this simple config file: IfDefine not-defined Location /Location /IfDefine $ httpd -f broken.conf Syntax error on line 1 of broken.conf: Expected /Location but saw /Location ok, I tested your patch against the perl-framework and ran a few checks against other containers as well (IfModule, etc). everything tested ok so I merged it into 2.1 and proposed for backport to 2.0. nice work philippe :) --Geoff
Re: interface of the 2.1 authentication framework / behaviour of mod_digest/mod_basic
currently, mod_auth_basic and mod_auth_digest behave inconsistently
in some cases. for example, if i enter a wrong user/pw combination,
mod_auth_basic writes the following logline (i.e. without a username)
...
another inconsistency would be that if the authentication provider
reports and internal error, mod_auth_basic produces an internal server
error whereas mod_auth_diges produces a user not found message, both
to the client an in the logs.
there are probably other edge cases where the two modules behave
inconsistenly. ideally, if i change the paramter of AuthType,
other things should stay the same in every possible way.
yeah, that would certainly be a good idea. give the attached patches a whirl
and see if they work for you. feedback from justin or others that are
familiar appreciated :)
--Geoff
Index: modules/aaa/mod_auth_basic.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/aaa/mod_auth_basic.c,v
retrieving revision 1.16
diff -u -r1.16 mod_auth_basic.c
--- modules/aaa/mod_auth_basic.c9 Feb 2004 20:29:17 - 1.16
+++ modules/aaa/mod_auth_basic.c19 Feb 2004 17:14:33 -
@@ -176,6 +176,9 @@
*user = ap_getword_nulls(r-pool, (const char**)decoded_line, ':');
*pw = decoded_line;
+/* set the user, even though the user is unauthenticated at this point */
+r-user = (char *) *user;
+
return OK;
}
Index: modules/aaa/mod_auth_digest.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/aaa/mod_auth_digest.c,v
retrieving revision 1.85
diff -u -r1.85 mod_auth_digest.c
--- modules/aaa/mod_auth_digest.c 9 Feb 2004 20:29:17 - 1.85
+++ modules/aaa/mod_auth_digest.c 19 Feb 2004 17:14:25 -
@@ -1328,8 +1328,8 @@
* Authorization header verification code
*/
-static const char *get_hash(request_rec *r, const char *user,
-digest_config_rec *conf)
+static authn_status get_hash(request_rec *r, const char *user,
+ digest_config_rec *conf)
{
authn_status auth_result;
char *password;
@@ -1374,12 +1374,11 @@
current_provider = current_provider-next;
} while (current_provider);
-if (auth_result != AUTH_USER_FOUND) {
-return NULL;
-}
-else {
-return password;
+if (auth_result == AUTH_USER_FOUND) {
+conf-ha1 = password;
}
+
+return auth_result;
}
static int check_nc(const request_rec *r, const digest_header_rec *resp,
@@ -1593,6 +1592,7 @@
request_rec *mainreq;
const char*t;
intres;
+authn_status return_code;
/* do we require Digest auth for this URI? */
@@ -1738,14 +1738,25 @@
return HTTP_UNAUTHORIZED;
}
-if (!(conf-ha1 = get_hash(r, r-user, conf))) {
+return_code = get_hash(r, r-user, conf);
+
+if (return_code == AUTH_USER_NOT_FOUND) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
Digest: user `%s' in realm `%s' not found: %s,
r-user, conf-realm, r-uri);
note_digest_auth_failure(r, conf, resp, 0);
return HTTP_UNAUTHORIZED;
}
-
+else if (return_code == AUTH_USER_FOUND) {
+/* we have a password, so continue */
+}
+else {
+/* AUTH_GENERAL_ERROR (or worse)
+ * We'll assume that the module has already said what its error
+ * was in the logs.
+ */
+return HTTP_INTERNAL_SERVER_ERROR;
+}
if (resp-message_qop == NULL) {
/* old (rfc-2069) style digest */
Re: 1.x: byte-range with ErrorDocuments returns incorrect status code
Will Lowe wrote:
It looks like byte-range requests on non-existant files returns 206
instead of 404 if ErrorDocument is set.
I was able to verify this - it looks like there's some simple logic in 2.0
that wasn't carried over to 1.3.
so, try this patch. all the byterange tests in the perl-framework pass with
it, in addition to my own ErrorDocument tests that I used to reproduce the
problem.
if anyone on 1.3 support is paying attention, what's the proper course for
insertion into the stable tree once things are verified - add to STATUS and
wait for reviews/votes?
--Geoff
Index: src/main/http_protocol.c
===
RCS file: /home/cvspublic/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.332
diff -u -r1.332 http_protocol.c
--- src/main/http_protocol.c16 Feb 2004 22:29:33 - 1.332
+++ src/main/http_protocol.c26 Feb 2004 14:14:21 -
@@ -260,7 +260,7 @@
if (!(range = ap_table_get(r-headers_in, Range)))
range = ap_table_get(r-headers_in, Request-Range);
-if (!range || strncasecmp(range, bytes=, 6)) {
+if (!range || strncasecmp(range, bytes=, 6) || r-status != HTTP_OK) {
return 0;
}
range += 6;
Re: [PATCH] RewriteCond and SSL environment variables
Mathihalli, Madhusudan wrote:
Here's a slightly modified version of Joe's patch to
- not segfault if rewrite_ssl_var_lookup is not available (mod_ssl not loaded)
- use SSL environment variables as %{ENV:HTTPS} or %{ENV:SSL_PROTOCOL}
I tested the patch with the following rules, and it appeared to work without causing
any problems.
RewriteCond %{ENV:HTTPS} =on
RewriteCond %{ENV:SSL_CIPHER_USEKEYSIZE} =128
RewriteRule ^/manual.*html$ /manual.html [L]
RewriteRule ^.*$ - [F]
looks like a perfect candidate for adding new tests to the perl-framework
;)
--Geoff
Re: [PATCH] RewriteCond and SSL environment variables
Maybe
we should put the HTTPS check into an own function (we could use %{HTTPS} in
mod_rewrite then). That way, other modules, that want to check (only) HTTPS,
also don't need to run though all the mess of ssl_var_lookup.
I'm not familiar with mod_ssl internals, but is there any reason we can't
move subprocess_env population to something early like post-read-request?
as a per-connection thingy, HTTPS ought to be know before the request cycle
begins, right? maybe not for other things, though...
anyway, this same thing came up recently with mod_env
http://marc.theaimsgroup.com/?l=apache-httpd-devm=107655981117848w=2
in that case I did trace the code and couldn't see any reason that the
population couldn't appear sooner, other than perhaps the history of
subprocess_env (but I haven't been around _that_ long :)
--Geoff
Re: making filters more efficient
If you have a concrete example of something that needs to query the state, then we can examine whether it should hook into the processing differently. I bet there is a different hook or approach that can avoid a query of the state. I think where stas is headed are cases like ryan's mod_apachecon http://rkbloom.net/rbb/mod_apachecon.c which seems to be to be a valid example - you want to manipulate part of the HTTP request, such as the request line or incoming headers, and post-read is too late. but simply scaning input for GET .* HTTP/1.0 isn't sufficient, since it's not foolproof, so it would be nice to have something that signaled the start of a request. --Geoff
Re: 1.x: byte-range with ErrorDocuments returns incorrect status code
Will Lowe wrote: Thanks for the quick response -- sorry I've been slow getting back to you. Yes, the attached patch does seem to fix 1.3.X. It'd be great if it got rolled into the next point release. ok, I'll try and guide it through the process. --Geoff
win32 on VC++ 5.0
hi all. a few win32 things :) I'm trying to get 2.0.48 to compile using VC++ 5.0 (sp1) on win2k (sp4) and am having a few issues. yeah, I know it's old, but I happen to have it around and it's all I have :) anyway, since I'm not a windows guy, some of this might be common knowledge, but I couldn't find anything on google. - http://httpd.apache.org/docs-2.0/platform/win_compiling.html suggests I need the Platform SDK, but the link is stale. in fact, I can't find it anywhere on the MS site - MS has a download page for it, but it's borked. so, is there more recent information such that the docs ought to be updated? - since the SDK is only suggested, I tried compiling anyway. I get to apr-util/rand.c and it throws this: rand.c C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'HRESULT' : undeclared identifier C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2064: term does not evaluate to a function C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : warning C4013: 'UuidCreate' undefined; assuming extern returning int C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'UUID' : undeclared identifier is this a known issue? should I report it to apr? or maybe 5.0 just isn't supported anymore? I'll accept that it's because I have no idea what I'm doing on this platform :) - lastly, is it possible/practical to have httpd 2.0 and 2.1 CVS snapshots include the win foo so I can attempt a fairly recent version of everything? anyway, thanks for any feedback. --Geoff
Re: win32 on VC++ 5.0
It's currently at: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm although MS seem to change most of their links every week ;) ugh. I found that but wasn't using msie so the js errors kept be from seeing the dropdowns. I don't think you need the Platform SDK for VC++ 6.0; I don't know about 5.0. If you do need it, then it's probably just the Core SDK component that you need. for the archives, I also needed the Internet Developer SDK to resolve some issues with winldap.h calling missing files. actually, all of ldap was a pain - I ended up disabling mod_auth_ldap to get past the issues. You also need IE 5.0 or later to be able to use most of their download sites! go figure. HRESULT is declared thus: typedef LONG HRESULT; in my COMMCTRL.h. Do you have that header file I have the file but no declaration. the core sdk conains the file as well with the declaration, so adding the sdk include path before the visual studio paths worked. it compiled (with 118 warnings). so, thanks for the help. --Geoff
Re: win32 on VC++ 5.0
I hate even including the links as they are staled often. yeah. but here's a patch anyway that at least matches my recent experience. if it looks ok to the people that use the platform regularly I'll hand it over to httpd-docs. --Geoff
Re: win32 on VC++ 5.0
blarg. patch attached Geoffrey Young wrote: I hate even including the links as they are staled often. yeah. but here's a patch anyway that at least matches my recent experience. if it looks ok to the people that use the platform regularly I'll hand it over to httpd-docs. --Geoff Index: docs/manual/platform/win_compiling.xml === RCS file: /home/cvspublic/httpd-2.0/docs/manual/platform/win_compiling.xml,v retrieving revision 1.7 diff -u -r1.7 win_compiling.xml --- docs/manual/platform/win_compiling.xml 9 Feb 2004 20:22:51 - 1.7 +++ docs/manual/platform/win_compiling.xml 5 Mar 2004 18:37:31 - @@ -65,7 +65,7 @@ li pThe Windows Platform SDK./p pVisual C++ 5.0 builds require an updated Microsoft Windows -Platform SDK to enable some Apache features. For command line +Platform SDK to compile. For command line builds, the Platform SDK environment is prepared by the codesetenv/code batch file:/p @@ -77,13 +77,9 @@ later are sufficient, so users of later version may skip this requirement./p -noteNote that the Windows Platform SDK update is required -to enable all supported modulemod_isapi/module features. -Without a recent update, Apache will issue warnings under -MSVC++ 5.0 that some modulemod_isapi/module features -will be disabled. Look for the update at a -href=http://msdn.microsoft.com/downloads/sdks/platform/platform.asp; -http://msdn.microsoft.com/downloads/sdks/platform/platform.asp/a./note +noteLook for the Platform SDK at a +href=http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm; + http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm/a./note /li li
Re: mod_deflate - disabling per response?
Jess Holle wrote: My apologies if this is better done on the user group, but I've been reading Apache source code and trying to understand the following. Is there any way to signal mod_deflate that a particular response should not be deflated when: 1. the URL of the request is identical to other cases that should be deflated, 2. the MIME type of the response is identical to other cases that should be deflated, and 3. the response is not already compressed/deflated? Essentially request parameters, data states, Java server logic, etc, behind mod_jk (or mod_jk2) will dictate whether compression can be allowed, but I need a way to signal this in my response from Tomcat. Any pointers would be much appreciated! really, it's the client that decides whether the content should be encoded or not, which they typically do by setting an Accept-Encoding request header. so remove that in the client and no compression. from the server side, it looks like you can set use the subprocess_env table to suppress it if you have access to the API apr_table_setn(r-subprocess_env, no-gzip); not sure if either of these suits you, though. HTH --Geoff
Re: Time for 1.3.30?
Jim Jagielski wrote: There are a few open patches floating about, but in general I think we're close to a point where we should seriously consider 1.3.30. I volunteer to be RM... I'd like to shoot for mid-late next week for a release. Comments? I just added a simple thing to STATUS that I've reviewed and tested. if other people could comment, that would be great. other than that, sounds cool :) --Geoff
mod_auth_digest and MSIE
hi all...
the MSIE + query string and mod_auth_digest came up again yesterday in
bugzilla:
http://issues.apache.org/bugzilla/show_bug.cgi?id=27758
the issue was discussed here a while ago, most notably in
http://marc.theaimsgroup.com/?t=10551086801r=1w=2
with most people thinking it was a decent enough idea but with little in
terms of a resoltion.
anyway, I (along with a few others in the two threads) are kind of in favor
of giving admins _some_ way to support MSIE + Digest. I like Paul's
original patch but kind of felt that playing with the comparison algorithm
was, well, messier than messing with the individual components. messy in
either case but at least this way if the comparison ever needs to change
there are less parentheses to worry about ;)
so new patch against HEAD is attached. comments, new or changed opinions,
implementation preferences, etc welcome. if the consensus is that the idea
is decent I'll keep reworking patches until everyone is satisfied with the
details.
--Geoff
Index: modules/aaa/mod_auth_digest.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/aaa/mod_auth_digest.c,v
retrieving revision 1.86
diff -u -r1.86 mod_auth_digest.c
--- modules/aaa/mod_auth_digest.c 21 Feb 2004 00:53:18 - 1.86
+++ modules/aaa/mod_auth_digest.c 19 Mar 2004 18:20:48 -
@@ -1671,8 +1671,34 @@
if (d_uri.path) {
ap_unescape_url(d_uri.path);
}
+
if (d_uri.query) {
ap_unescape_url(d_uri.query);
+}
+else if (r_uri.query) {
+/* MSIE compatibility hack. MSIE has some RFC issues - doesn't
+ * include the query string in the uri Authorization component
+ * or when computing the response component. the second part
+ * works out ok, since we can hash the header and get the same
+ * result. however, the uri from the request line won't match
+ * the uri Authorization component since the header lacks the
+ * query string, leaving us incompatable with a (broken) MSIE.
+ *
+ * the workaround is to fake a query string match if in the proper
+ * environment - BrowserMatch MSIE, for example. the cool thing
+ * is that if MSIE ever fixes itself the simple match ought to
+ * work and this code won't be reached anyway, even if the
+ * environment is set.
+ */
+
+if (apr_table_get(r-subprocess_env,
+ AuthDigestEnableQueryStringHack)) {
+
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, Digest:
+ applying AuthDigestEnableQueryStringHack);
+
+ d_uri.query = r_uri.query;
+}
}
if (r-method_number == M_CONNECT) {
Re: mod_auth_digest and MSIE
Paul Querna wrote: On Fri, 2004-03-19 at 16:59, Geoffrey Young wrote: it probably needs a better name, though :) AuthDigestEnableQueryStringHack is a great name. Its an fugly name for an fugly Hack. I forget who originally suggested the name, but I like it. ok :) Geoff, I like your approach in that patch. It keeps that huge if() from getting any bigger or more complicated. cool. I'll give it a few more days to marinate, but if nobody complains or has a better implementation suggestion I'll check it in around tuesday of next week. --Geoff
Re: add location !~ regex ?
André Malo wrote: * apache [EMAIL PROTECTED] wrote: location !~ regex or location -v regex would be very nice in certain case for exemple, enable client certificat auth for the entire site but 2 locations LocationMatch ^(?!non-location1|non-location2) should do (in 2.x). I played around with implementing this in 1.3 (in perl, of course :) and basically found that it was a bit counterintuitive - not match is far broader than you realize and will include what used to be 404s, images that you probably don't want to mess with, etc. but it was a long time ago and ymmv. --Geoff
Re: mod_auth_digest and MSIE
Geoff, I like your approach in that patch. It keeps that huge if() from getting any bigger or more complicated. cool. I'll give it a few more days to marinate, but if nobody complains or has a better implementation suggestion I'll check it in around tuesday of next week. committed to 2.1 and suggested for review and backport to 2.0. thanks for the feedback. --Geoff
Re: [1.3 PATCH] fix ap_custom_response() memory corruption issue
But with the right combination of modules, it is very easy to see that when a module calls ap_custom_response() on some flow, subsequent requests with no such call will still get the previously-registered response string. While I have not hit crashes myself in testing over in perl-land I maintain Apache-Test skeletons that users can adjust to easily provide self-contained examples when reporting bugs: http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz now, these packages assume that you have mod_perl installed, so if you don't there will be lots of tweaking to do. however, I'd be happy to also maintain a set that are Apache/C-module specific as well. the idea would be that everything you have is already there - just add in your httpd.conf and issue 'make test' and you ought to have enough to reproduce specific behaviors. as both stas and I have been finding, not only are they good for users, but we both use them ourselves as a quick starting point for reproducing user-reported behaviors. I also use it whenever I start to code against Apache internals :) just a thought. --Geoff
returning AUTH_DENIED from a Digest provider
hi all
in 2.1 there is no supported API for a digest provider to deny a user
outright before a password match is tried.
digest providers are currently limited to AUTH_USER_NOT_FOUND or
AUTH_GENERAL_ERROR for errors. recent changes in AUTH_GENERAL_ERROR make it
return 500 to match how Basic auth is handled, and AUTH_USER_NOT_FOUND
releases control to the next provider in the chain. this all leaves digest
providers without a way to return 401 and stop the authentication chain.
basic providers, however, can use AUTH_DENIED to accomplish this.
so, I'd like to support AUTH_DENIED from digest providers as well. this
simple patch is all that is required.
--Geoff
Index: modules/aaa/mod_auth_digest.c
===
RCS file: /home/cvs/httpd-2.0/modules/aaa/mod_auth_digest.c,v
retrieving revision 1.87
diff -u -r1.87 mod_auth_digest.c
--- modules/aaa/mod_auth_digest.c 23 Mar 2004 13:57:48 - 1.87
+++ modules/aaa/mod_auth_digest.c 5 Apr 2004 13:33:10 -
@@ -1777,6 +1777,14 @@
else if (return_code == AUTH_USER_FOUND) {
/* we have a password, so continue */
}
+else if (return_code == AUTH_DENIED) {
+/* authentication denied in the provider before attempting a match */
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ Digest: user `%s' in realm `%s' denied by provider: %s,
+ r-user, conf-realm, r-uri);
+note_digest_auth_failure(r, conf, resp, 0);
+return HTTP_UNAUTHORIZED;
+}
else {
/* AUTH_GENERAL_ERROR (or worse)
* We'll assume that the module has already said what its error
Re: returning AUTH_DENIED from a Digest provider
Justin Erenkrantz wrote: --On Monday, April 5, 2004 9:35 AM -0400 Geoffrey Young [EMAIL PROTECTED] wrote: releases control to the next provider in the chain. this all leaves digest providers without a way to return 401 and stop the authentication chain. basic providers, however, can use AUTH_DENIED to accomplish this. so, I'd like to support AUTH_DENIED from digest providers as well. this simple patch is all that is required. No idea how a provider would figure out that AUTH_DENIED is appropriate when using digest auth (the account itself is disabled is the only thing I can think of right now). well, the idea I had in mind was that you might want to insert a provider that denies auth merely based on the username or realm, maybe query a blacklist or something. I realize you could also do this by simply removing the user from your auth credential mechanism, but if you have a chain of providers you might want to quit early rather than run through them all. Yet, this still seems reasonable to handle - right now, we'd just return 500 rather than 401, so this seems fine by me: +1. -- justin will do. thanks :) --Geoff
restore ErrorDocument to default serer message
hi all today in bugzilla Joshua brought up an interesting point about ErrorDocument - once set on a global or per-server level you can't selectively restore the error response back to the canned server document. http://issues.apache.org/bugzilla/show_bug.cgi?id=28173 while the current userland solution is well known and standard practice, the logic to reset the ErrorDocument is back to the default is trivial: conf-response_code_strings[idx] = NULL; over in mod_perl land we support this through the custom_response() API, but it would be kind of cool to be able to support ErrorDocument 500 default in core httpd, allowing users to effectively restore the canned server response for the scope of the current ErrorDocument. anyway, I'm just tossing the idea out there - if people like it I'll work up a patch. if not, no biggie. --Geoff
Re: restore ErrorDocument to default serer message
Cliff Woolley wrote:
On Mon, 5 Apr 2004, Geoffrey Young wrote:
ErrorDocument 500 default
in core httpd, allowing users to effectively restore the canned server
response for the scope of the current ErrorDocument.
anyway, I'm just tossing the idea out there - if people like it I'll work up
a patch. if not, no biggie.
Seems reasonable to me; +1 on concept.
cool.
patch and self-contained test attached.
--Geoff
Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.270
diff -u -r1.270 core.c
--- server/core.c 25 Mar 2004 14:27:27 - 1.270
+++ server/core.c 6 Apr 2004 04:07:23 -
@@ -271,9 +271,7 @@
sizeof(*conf-response_code_strings) * RESPONSE_CODES);
for (i = 0; i RESPONSE_CODES; ++i) {
-if (new-response_code_strings[i] != NULL) {
-conf-response_code_strings[i] = new-response_code_strings[i];
-}
+conf-response_code_strings[i] = new-response_code_strings[i];
}
}
/* Otherwise we simply use the base-response_code_strings array
@@ -1178,13 +1176,21 @@
RESPONSE_CODES);
}
-/* hack. Prefix a if it is a msg; as that is what
- * http_protocol.c relies on to distinguish between
- * a msg and a (local) path.
- */
-conf-response_code_strings[index_number] = (what == MSG) ?
-apr_pstrcat(cmd-pool, \,msg,NULL) :
-apr_pstrdup(cmd-pool, msg);
+if (strcmp(msg, default) == 0) {
+/* special case: ErrorDocument 404 default restores the
+ * canned server error response
+ */
+conf-response_code_strings[index_number] = NULL;
+}
+else {
+/* hack. Prefix a if it is a msg; as that is what
+ * http_protocol.c relies on to distinguish between
+ * a msg and a (local) path.
+ */
+conf-response_code_strings[index_number] = (what == MSG) ?
+apr_pstrcat(cmd-pool, \,msg,NULL) :
+apr_pstrdup(cmd-pool, msg);
+}
}
return NULL;
errordoc-restore.tar.gz
Description: GNU Zip compressed data
Re: cvs commit: httpd-2.0/server core.c
[EMAIL PROTECTED] wrote: geoff 2004/04/08 17:56:26 Modified:.CHANGES server core.c Log: Enable special ErrorDocument value 'default' which restores the canned server response for the scope of the directive. if this stays in 2.1 it will need some docs. I saw that the 2.1 docs are maintained in HEAD just as with the code, but I'm unsure of whether to edit the .xml, .html.en, or both. --Geoff
Re: cvs commit: httpd-2.0/server core.c
Just edit the .xml. (There is a big ugly note at the top of the .html.en telling you not to touch it.) Then you can build the .html.en using the instructions here: http://httpd.apache.org/docs-project/docsformat.html Or if you don't want to bother, just do the .xml and someone else will take care of building the .html. cool, I'll do that. thanks. (and sorry I didn't see the note :) --Geoff
Re: cvs commit: httpd-2.0/server core.c
[EMAIL PROTECTED] wrote: nd 2004/04/10 11:40:53 Modified:server core.c Log: ErrorDocument default changes broke inheritance. consider: Directory /foo ErrorDocument 404 blah /Directory DIrectory /foo/bar ErrorDocument 500 boo # 404 is now fallen back to default /Directory This patch solves the problem. thanks for catching that. guess my test suite wasn't quite good enough :) --Geoff
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Joshua Slive wrote: I do have one question about this: Is anyone actually using mod_digest? I was under the impression that there doesn't exist any client that can interoperate with this module (as opposed to mod_auth_digest, which supports modern clients). If this is true, why don't we just delete the darn thing? 1.3's mod_digest works with opera, mozilla, konquer, and a few others last time I checked. it does not work with msie, though, which I guess is the big reason it wasn't widely deployed. --Geoff
Re: mod_ext_filter and last-modified header
Craig Sebenik wrote: It looks like mod_ext_filter sets the last-modified http header based on the mod time of the *filter* file and not the actual file represented by the URL. the Last-Modified HTTP header seems to be set based on the timestamp on /web_home/filters/filter.pl and NOT on /web_home/htdocs/file.html I would hope it would be the newer of both, since both contribute to the freshness of the content, which is what is important. if you touch file.html do you get the newer timestamp? --Geoff
Re: cvs commit: httpd-docs-1.3/htdocs/manual/mod mod_digest.html
+(December 2003), most major browsers support digest +authentication. However, the only major browsers which support +the old digest authentication format are a href=http://www.opera.com/;Opera 4.0/a, +a href=http://www.microsoft.com/windows/ie/;MS Internet +Explorer 5.0/a and a href=http://www.w3.org/Amaya/;Amaya/a. that still doesn't sound quite right to me. here is how I recall the state of affairs last I checked all the browsers (admittedly over a year ago, but most browsers don't remove features, and MSIE is still borked by all accounts). feel free to adopt it (or not) or alter the wording/formatting at will - I was just trying to help things a bit. --Geoff Index: htdocs/manual/mod/mod_digest.html === RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/mod/mod_digest.html,v retrieving revision 1.17 diff -u -r1.17 mod_digest.html --- htdocs/manual/mod/mod_digest.html 15 Apr 2004 18:16:58 - 1.17 +++ htdocs/manual/mod/mod_digest.html 15 Apr 2004 19:50:40 - @@ -32,10 +32,12 @@ h2Summary/h2 pThis module implements an older version of the MD5 Digest -Authentication specification which will probably not work with -modern browsers. Please see a +Authentication specification. While suitable for most modern +browsers, mod_digest is known to not work with Microsoft +Internet Explorer. Please see a href=mod_auth_digest.htmlmod_auth_digest/a for a module -which implements the most recent version of the standard./p +which implements the most recent version of the standard +and does not suffer from the same limitations as mod_digest./p h2Directives/h2 @@ -68,12 +70,16 @@ pMD5 authentication provides a more secure password system, but only works with supporting browsers. As of this writing -(December 2003), most major browsers support digest -authentication. However, the only major browsers which support -the old digest authentication format are a href=http://www.opera.com/;Opera 4.0/a, -a href=http://www.microsoft.com/windows/ie/;MS Internet -Explorer 5.0/a and a href=http://www.w3.org/Amaya/;Amaya/a. -Therefore, we do not recommend using this feature on a large +(December 2003) most major browsers, including +a href=http://www.microsoft.com/windows/ie/;MS Internet Explorer/a, +a href=http://www.opera.com/;Opera/a, +a href=http://www.netscape.com/;Netscape/a, +a href=http://www.mozilla.org/;Mozilla/a, and +a href=http://www.w3.org/Amaya/;Amaya/a, +support the Digest authentication scheme. However, of this list +MS Internet Explorer is known to be incompatable with the +older digest authentication format supported by this module. +Therefore, we do not recommend using this module on a large Internet site. However, for personal and intra-net use, where browser users can be controlled, it is ideal./p
Re: Apache 1.3.31 RC Tarballs available
Use of uninitialized value in concatenation (.) or string at
/home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
The single request for /index.html is the framework's ping to see if
the server has started. It is not part of the errordoc tests, which
suggests that these don't get to the server at all.
yes. with 'use warnings FATAL = 'all'' the above error is causing the test
to die before it ever starts.
the problem seems to be in Apache::TestRequest::resolve_url(), but there is
no way for me to tell from here which part isn't being found properly.
are you running ssl? maybe putting this line
Apache::TestRequest::scheme('http');
just prior to the
Apache::TestRequest::module('error_document');
line in t/apache/errordoc.t would help. this appears to be the only
difference between errordoc.t and other modules that use a similar set of
directives to configure the test.
outside of that make sure that it's a fresh, pristine checkout, as if you
have some files hanging around it might collide with some of the
autogenerated stuff.
if neither of these work we'll have to poke around a bit in the internals,
but let's wait and see.
it would be great to have the tests at 100% for current 1.3, 2.0, and
2.1.
if we can get it to that point I volunteer to be the project watchdog
who
will pipe up if some commit causes the framework to suddenly fail (at
least
on the platform I run, currently fedora). but until we get to 100% the
framework is kinda useless for RC testing as far as I'm concerned -
known
failures don't really mean much for this kind of thing.
It has long been one of my desires to do an automated nightly
build/test run on all three branches. As I get my lab set up here
(which should happen in the next couple of weeks), I may be able to
finally get that set up.
cool, that would be great.
When I was testing a product based on httpd 2.0, I would keep a list of
known failures (we had some patches that the framework didn't deal
with) on our internal Wiki, so I would know that a test had been
failing and I wouldn't have to analyze every failure to death every
time.
yeah, that's the problem, wasting time trying to figure out whether the
failure is real or not, then somebody else doing the same thing. and it's
not an easy process, getting gritty with the code to make absolutely sure
whether the failure is in the codebase or the test expectations.
That was stuff like OpenSSL would put the email field name of a
certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
was it the other way around?
it would be great if we could capture that kind of thing in the test itself,
either in the actual test or in the framework (allow for case-insensitive
matches, for instance).
if you're willing (and can share internal knowledge publically, etc), I can
help integrate this particular issue into the framework. really, I'll do
whatever is required to get us at 100% - massive handholding if you know
what the issue is but can't quite grok the framework, verbose non-RTFM
explanations over irc or email, whatever...
Anyway, it would be great to get something like that going on a daily
basis. Kinda like an httpd project interpretation of Gump, like, Httpump.
agreed. well, let's see about what we can do to get the framework at 100%
and we can go from there. it's great to have someone else interested in all
of this :)
--Geoff
Re: Apache 1.3.31 RC Tarballs available
cross-posting to test-dev@, which is probably where we ought to discuss the gory details... Failed Test Stat Wstat Total Fail Failed List of Failed at this point the test part of the perl-framework is largely unmaintained. a few months ago I tried to stir up some interest in cleaning it up: http://marc.theaimsgroup.com/?l=apache-test-devm=107091289914815w=2 some of the issues there were fixed by myself and others, but a few remain outstanding. t/apache/contentlength.t 207 35.00% 2 6 10 14 16 18 20 t/modules/autoindex2.t 32 66.67% 1 3 these (or a subset thereof) have been failing at least since that email, but I just haven't gotten around to looking at them yet. (1 subtest UNEXPECTEDLY SUCCEEDED) IIRC this is from t/apache/include? I suspect this is due to some backported changes that were never updated in the test suite by andre or myself. I'll look at that this week unless andre beats me to it. t/apache/errordoc.t 2 51214 14 100.00% 1-14 I added that test recently and it passes for me on fedora. can you try $ t/TEST t/apache/errordoc.t -v and send that along (along with any relevant error_log messages). that all tests fail probably mean that it's not picking up on a required configuration thingy. t/modules/cgi.t464 8.70% 5-6 13-14 this just hangs for me, but there were some changes introduced recently that may account for this - without looking at the change log it something about STDERR IIRC. t/modules/expires.t924 4.35% 13 21 33 45 fails for me as well. it would be great to have the tests at 100% for current 1.3, 2.0, and 2.1. if we can get it to that point I volunteer to be the project watchdog who will pipe up if some commit causes the framework to suddenly fail (at least on the platform I run, currently fedora). but until we get to 100% the framework is kinda useless for RC testing as far as I'm concerned - known failures don't really mean much for this kind of thing. --Geoff
Re: TR of 1.3.31
Jim Jagielski wrote: I plan to TR 1.3.31 most likely tomorrow... speak now or forever hold your peace. I don't think the mod_digest.html stuff I sent was integrated, even though it seemed people were happy with the wording. but I didn't want to just commit it until the RM officially said so :) not that these docs are all that critical of an issue... --Geoff Index: htdocs/manual/mod/mod_digest.html === RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/mod/mod_digest.html,v retrieving revision 1.17 diff -u -r1.17 mod_digest.html --- htdocs/manual/mod/mod_digest.html 15 Apr 2004 18:16:58 - 1.17 +++ htdocs/manual/mod/mod_digest.html 15 Apr 2004 19:50:40 - @@ -32,10 +32,12 @@ h2Summary/h2 pThis module implements an older version of the MD5 Digest -Authentication specification which will probably not work with -modern browsers. Please see a +Authentication specification. While suitable for most modern +browsers, mod_digest is known to not work with Microsoft +Internet Explorer. Please see a href=mod_auth_digest.htmlmod_auth_digest/a for a module -which implements the most recent version of the standard./p +which implements the most recent version of the standard +and does not suffer from the same limitations as mod_digest./p h2Directives/h2 @@ -68,12 +70,16 @@ pMD5 authentication provides a more secure password system, but only works with supporting browsers. As of this writing -(December 2003), most major browsers support digest -authentication. However, the only major browsers which support -the old digest authentication format are a href=http://www.opera.com/;Opera 4.0/a, -a href=http://www.microsoft.com/windows/ie/;MS Internet -Explorer 5.0/a and a href=http://www.w3.org/Amaya/;Amaya/a. -Therefore, we do not recommend using this feature on a large +(December 2003) most major browsers, including +a href=http://www.microsoft.com/windows/ie/;MS Internet Explorer/a, +a href=http://www.opera.com/;Opera/a, +a href=http://www.netscape.com/;Netscape/a, +a href=http://www.mozilla.org/;Mozilla/a, and +a href=http://www.w3.org/Amaya/;Amaya/a, +support the Digest authentication scheme. However, of this list +MS Internet Explorer is known to be incompatable with the +older digest authentication format supported by this module. +Therefore, we do not recommend using this module on a large Internet site. However, for personal and intra-net use, where browser users can be controlled, it is ideal./p
Re: [PATCH] RFC: Allow modification/deletion of specific headers in apr_table_t
Sumeet Singh wrote: Brian, If you ask me, I can write the new functions (i.e. the apr_table_do - type functions you described) and submit a patch for review. Let me know I have often wanted an apr_table_do-esque interface that allowed for modification of table entries as suggested, so that sounds good to me. --Geoff
Re: Sample code for IPC in modules
I put the new version at http://apache.org/~sctemme/mod_example_ipc.c to save on e-mail bandwidth. if you're interested in this kind of thing, I've wrapped up mod_example_ipc in an Apache-Test tarball: http://perl.apache.org/~geoff/mod_example-ipc.tar.gz for no particular reason except that I know you were at my apachecon talk on Apache-Test but I didn't cover C module integration at all. fwiw. --Geoff
Re: Move apache-1.3 to Subversion
FYI, Fitz did a conversion of apache-1.3, which is now located at http://svn.apache.org/repos/test/httpd/. (in the test repository). wow, that's a lot of data - 10 minutes later and I'm still downloading... I guess it goes without saying that most of the people here are intimate with svn. as someone who just started playing with it about a month ago, will there be httpd developer guidelines and hints someplace, or is the existing (copious) svn documentation about it? for instance, I imagine that for routine patching, etc I'll only need to have a working copy of trunk? --Geoff
Re: Move apache-1.3 to Subversion
This is going to be a recurring problem. Geoff did the intuitive thing, which turned out to be wrong. Not good. Documentation issue... IMO, Sander should have added a note to his conversion notice about how to checkout the trunk of the repository. yeah, I'd agree with this - including trunk/ in the url wherever it appears would probably solve the issue for cut-and-paste types like me, who don't fully grok svn (or grok it just enough to be dangerous :) as an aside, I can't recall if it has been discussed already, but just in case it hasn't, someone ought to take a look at the features listed in http://httpd.apache.org/dev/anoncvs.txt and see what needs to be done to support them (or remove them from the doc) once the migration is offical. my understanding is that the anonymous access bit it taken care of automatically with svn, but a few people I've talked to have wondered whether rsync is going away. --Geoff
dynamic hook ordering
hi all I wanted to ping everyone about an idea I've been throwing around for a few months now. I'd like the ability to shuffle the declared hook ordering around, most likely during the post-config phase. basically what I would like to be able to do is shift a hook from one place (say, HOOK_FIRST) to another. there are a few reasons I want to be able to do this, and most stem from some things I want to be able to do with mod_perl, but I'll go into that rationale later if someone asks :) putting reasons aside for the moment, here is a proof of concept module that kind of does what I'm after. http://perl.apache.org/~geoff/hook_order-test.tar.gz the main logic is in mod_hook_order.c, where it basically takes every mod_perl hook (which are by default registered as REALLY_FIRST) and moves them to HOOK_LAST during post-config. you can run the module if you have a mod_perl enabled server and Apache-Test installed, but the code is fairly straightforward (and largely stolen from mod_info). all in all, it's a fairly simple thing to do, but it makes a few things possible, most interestingly the ability to create a configuration directive that would allow users to choose the ordering of core processing the way they used to be able to in 1.3 (a la ClearModuleList/AddModule and without editing the source). another problem it might help to solve is when module writers encounter a situation where another module is registered REALLY_FIRST or REALLY_LAST and they want the spot. currently, I don't see any formal way to claim those spots for yourself except registering yourself as, say, REALLY_LAST + 10 or something. anyway, what I would like to try to do is take the logic in the prototype and create a formal apr_hook_get()/apr_hook_set() API that allows people access to the data that is there. an additional need would be to require each call to ap_hook_* to have a name for the hook as well, since modules can register mutliple callbacks for the same phase but there is no way to distinguish one callback from another in the current design. so, before I get started down the path of a bit of work, comments appreciated. --Geoff
Re: dynamic hook ordering
Cliff Woolley wrote: On Wed, 9 Jun 2004, Geoffrey Young wrote: I wanted to ping everyone about an idea I've been throwing around for a few months now. I'd like the ability to shuffle the declared hook ordering around, most likely during the post-config phase. There was some discussion about this or something at least vaguely like it a while back, but nobody ever got around to implementing it. See http://marc.theaimsgroup.com/?l=apache-httpd-devm=106637026719893w=2 ah, cool. I totally missed that. thanks. I think I have most of the --list-hooks stuff done already, if in a crude form. the debugging code in the module ends up looking like this: [info] found module mod_unique_id.c scheduled for hook HookPostReadRequestHandler [info] found module mod_setenvif.c scheduled for hook HookPostReadRequestHandler [info] found module mod_perl.c scheduled for hook HookTransHandler so it's just a matter of making it decent. you mention having an option for httpd, so that's a good place for me to start with this. -h is taken, so how about a -k (hooK) command line option that would give something like this post-read request: mod_unique_id.c mod_setenvif.c translation: mod_perl.c and so on. it would need to be an option like configtest to get everything I'd think. But sure, feel free, have at it. :) cool. I'm really intrigued by ben's last comment, the hook-listing API - if anyone has some ideas wrt what the API ought to look like from a user perspective it would be a help. or I could just code something up and we can take it from there :) --Geoff
Re: dynamic hook ordering
Cliff Woolley wrote:
On Wed, 9 Jun 2004, Geoffrey Young wrote:
I wanted to ping everyone about an idea I've been throwing around for a few
months now. I'd like the ability to shuffle the declared hook ordering
around, most likely during the post-config phase.
There was some discussion about this or something at least vaguely like it
a while back, but nobody ever got around to implementing it.
ok, here's a first pass at just a small part - achieve the hook listing by
offering an apr_table_do()-esque iterator just for hooks.
the output of httpd -o (for hOok, I guess) looks something like this:
Registered Hooks:
Pre-MPM
core.c (10)
...
Open Logs
prefork.c (10)
core.c (-10)
mod_log_config.c (10)
...
Map-to-Storage
mod_proxy.c (0)
http_core.c (10)
core.c (30)
etc.
where the number in parentheses is the (untranslated) APR_HOOK_* value.
this is obviously a work in progress (and perhaps ugly as well), so comments
on all aspects very, very welcome. the next step would to make mod_info use
the new hook iterator and pull out the logic that was mostly stolen from
there. but I'll wait for feedback on what I have so far before doing that,
as well as stuff like ap_hook_order_set() or somesuch :)
--Geoff
Index: NWGNUmakefile
===
RCS file: /home/cvs/httpd-2.0/NWGNUmakefile,v
retrieving revision 1.25
diff -u -r1.25 NWGNUmakefile
--- NWGNUmakefile 1 Jun 2004 17:48:21 - 1.25
+++ NWGNUmakefile 11 Jun 2004 04:33:46 -
@@ -238,6 +238,7 @@
$(OBJDIR)/util_md5.o \
$(OBJDIR)/util_nw.o \
$(OBJDIR)/util_script.o \
+ $(OBJDIR)/util_hook.o \
$(OBJDIR)/util_time.o \
$(OBJDIR)/util_xml.o \
$(OBJDIR)/vhost.o \
Index: build/nw_export.inc
===
RCS file: /home/cvs/httpd-2.0/build/nw_export.inc,v
retrieving revision 1.5
diff -u -r1.5 nw_export.inc
--- build/nw_export.inc 20 Jan 2003 21:38:49 - 1.5
+++ build/nw_export.inc 11 Jun 2004 04:34:03 -
@@ -42,6 +42,7 @@
/*#include util_ldap.h*/
#include util_md5.h
#include util_script.h
+#include util_hook.h
#include util_time.h
#include util_xml.h
Index: include/http_config.h
===
RCS file: /home/cvs/httpd-2.0/include/http_config.h,v
retrieving revision 1.110
diff -u -r1.110 http_config.h
--- include/http_config.h 4 Jun 2004 22:40:46 - 1.110
+++ include/http_config.h 11 Jun 2004 04:34:06 -
@@ -768,6 +768,11 @@
AP_DECLARE(void) ap_show_modules(void);
/**
+ * Show registered hooks. Used for httpd -k.
+ */
+AP_DECLARE(void) ap_show_hooks(void);
+
+/**
* Show the MPM name. Used in reporting modules such as mod_info to
* provide extra information to the user
*/
Index: include/http_main.h
===
RCS file: /home/cvs/httpd-2.0/include/http_main.h,v
retrieving revision 1.30
diff -u -r1.30 http_main.h
--- include/http_main.h 9 Feb 2004 20:38:21 - 1.30
+++ include/http_main.h 11 Jun 2004 04:34:08 -
@@ -22,7 +22,7 @@
* in apr_getopt() format. Use this for default'ing args that the MPM
* can safely ignore and pass on from its rewrite_args() handler.
*/
-#define AP_SERVER_BASEARGS C:c:D:d:E:e:f:vVlLtSh?X
+#define AP_SERVER_BASEARGS C:c:D:d:E:e:f:vVloLtSh?X
#ifdef __cplusplus
extern C {
Index: server/Makefile.in
===
RCS file: /home/cvs/httpd-2.0/server/Makefile.in,v
retrieving revision 1.94
diff -u -r1.94 Makefile.in
--- server/Makefile.in 15 Mar 2004 21:49:35 - 1.94
+++ server/Makefile.in 11 Jun 2004 04:36:29 -
@@ -9,7 +9,7 @@
LTLIBRARY_SOURCES = \
test_char.h \
config.c log.c main.c vhost.c util.c \
- util_script.c util_md5.c util_cfgtree.c util_ebcdic.c util_time.c \
+ util_script.c util_md5.c util_cfgtree.c util_ebcdic.c util_time.c util_hook.c \
connection.c listen.c \
mpm_common.c util_charset.c util_debug.c util_xml.c \
util_filter.c exports.c buildmark.c \
@@ -66,6 +66,8 @@
export_vars.h: export_files
$(AWK) -f $(top_srcdir)/build/make_var_export.awk `cat $?` $@
+
+util_hook.c: httpd.exp
# Rule to make def file for OS/2 core dll
ApacheCoreOS2.def: exports.c export_vars.h $(top_srcdir)/os/$(OS_DIR)/core_header.def
Index: server/config.c
===
RCS file: /home/cvs/httpd-2.0/server/config.c,v
retrieving revision 1.177
diff -u -r1.177 config.c
--- server/config.c 25 Apr 2004 17:23:31 - 1.177
+++ server/config.c 11 Jun 2004 04:36:32 -
@@ -50,6 +50,7 @@
#include http_main.h
#include http_vhost.h
#include util_cfgtree.h
+#include util_hook.h
#include mpm.h
@@ -2047,4 +2048,28 @@
AP_DECLARE(const char *) ap_show_mpm(void)
{
return MPM_NAME;
+}
+
+static int list_hooks(char **phase, ap_hook_struct_t *hook)
+{
+if (strcmp(*phase, hook-desc)) {
+ printf
Re: [Patch] Prevent coredump when statically linked module tries to access ap_server_config_defines from register_hooks
Philippe M. Chiasson wrote: The only moment where it's appropriate for a module to push Defines values into ap_server_config_defines is during the register_hook phase. The problem is that this phase is called earlier for compiled-in modules than for loaded modules. So a module trying to add to it thru apr_array_push(ap_server_config_defines) at that time will succeed, only if it's dynamically loaded, and most likely segfault otherwise. The following patches delays ap_setup_prelinked_modules to slightly later, after ap_server_config_defines has been proprely initialized. that all seems reasonable. does anyone know of any historical (or other) reasons why this shouldn't be shuffled a bit? --Geoff
Re: dynamic hook ordering
hi all... any feedback on this? the original patch is here: http://marc.theaimsgroup.com/?l=apache-httpd-devm=108693011011443w=2 --Geoff ok, here's a first pass at just a small part - achieve the hook listing by offering an apr_table_do()-esque iterator just for hooks. the output of httpd -o (for hOok, I guess) looks something like this: Registered Hooks: Pre-MPM core.c (10) ... Open Logs prefork.c (10) core.c (-10) mod_log_config.c (10) ... Map-to-Storage mod_proxy.c (0) http_core.c (10) core.c (30) etc. where the number in parentheses is the (untranslated) APR_HOOK_* value.
Re: Apache HTTP Server 2.0.50-rc2 tarballs available for testing
Sander Striker wrote: Hi, My second attempt at preparing a 2.0.50 rc tarball... I've tagged the tree (STRIKER_2_0_50_RC2) and uploaded associated tarballs to: http://httpd.apache.org/dev/dist/ Please test and report. plays nice with mod_perl-2.0 on fedora core 1. also plays nice with the perl-framework. good work. --Geoff
Re: Apache HTTP Server 2.0.50-rc2 tarballs available for testing
Tom Alsberg wrote: On Tue, Jun 22, 2004 at 10:09:39PM +0200, Sander Striker wrote: Hi, My second attempt at preparing a 2.0.50 rc tarball... OK, I'll be more direct now (my last mail to this list has apparently been ignored). Can you please try to get this: http://issues.apache.org/bugzilla/show_bug.cgi?id=29310 into that release? the process for adding new features to Apache 2.0 is to first integrate the feature into Apache 2.1 (cvs HEAD). after that, the feature is voted upon for inclusion in the stable 2.0 branch. from the bug report, it sounds like not only is the feature not in 2.1, but that it hasn't been decided what its final form will be. so there are a few steps left to overcome for this feature yet. that, and although this is really the call of the release manager, in general I would expect that once a release candidate is tagged changes to the tree should be minimal (doc changes, for example) or extreme (like just-discovered security flaws, in which case the tag is probably tossed and the release number skipped). or something like that :) HTH --Geoff
Re: cvs commit: httpd-2.0/server main.c
[EMAIL PROTECTED] wrote: martin 2004/06/29 07:08:17 Modified:server main.c Log: Add OS and APACHE_MPM_DIR to -V output just FYI, APACHE_MPM_DIR was removed in favor of naming the specific MPM in -V ouput. see http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/main.c?r1=1.147r2=1.148 and the discussion starting here http://marc.theaimsgroup.com/?l=apache-httpd-devm=106920092727368w=2 the decsion to remove it seemed to based on nobody needing it, so I guess if you have a real need that can't be satisfied by the existing information then it's cool to put it back. --Geoff
backport with minor bump
hi all... can somebody just take a quick look at this backport patch to verify that I'm doing the minor bump properly? thanks --Geoff Index: CHANGES === RCS file: /home/cvs/httpd-2.0/CHANGES,v retrieving revision 1.988.2.310 diff -u -r1.988.2.310 CHANGES --- CHANGES 3 Jul 2004 12:48:00 - 1.988.2.310 +++ CHANGES 6 Jul 2004 17:37:44 - @@ -1,5 +1,9 @@ Changes with Apache 2.0.51 + *) initialize server arrays prior to calling ap_setup_prelinked_modules + so that static modules can push Defines values when registering + hooks just like DSO modules can [Philippe M. Chiasson gozer cpan.org] + *) Small fix to allow reverse proxying to an ftp server. Previously an attempt to do this would try and connect to 0.0.0.0, regardless of the server specified. PR 24922 Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.946 diff -u -r1.751.2.946 STATUS --- STATUS 3 Jul 2004 12:48:00 - 1.751.2.946 +++ STATUS 6 Jul 2004 17:37:52 - @@ -73,13 +73,6 @@ [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] -*) initialize server arrays prior to calling ap_setup_prelinked_modules - so that static modules can push Defines values when registering - hooks just like DSO modules can [Philippe M. Chiasson gozer cpan.org] - server/main.c: r1.158 - +1: geoff, nd, stas - nd adds: minor bump. - *) mod_ssl: Remove some unused functions (after CAN-2004-0488 fix is applied) http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_util.c?r1=1.46r2=1.47 +1: jorton Index: include/ap_mmn.h === RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v retrieving revision 1.52.2.11 diff -u -r1.52.2.11 ap_mmn.h --- include/ap_mmn.h 11 Jun 2004 20:46:41 - 1.52.2.11 +++ include/ap_mmn.h 6 Jul 2004 17:38:11 - @@ -80,6 +80,8 @@ * 20020903.7 (2.0.49-dev) added XHTML Doctypes * 20020903.8 (2.0.50-dev) export ap_set_sub_req_protocol and * ap_finalize_sub_req_protocol on Win32 and NetWare + * 20020903.9 (2.0.51-dev) create pcommands and initialize arrays before + * calling ap_setup_prelinked_modules */ #define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */ @@ -87,7 +89,7 @@ #ifndef MODULE_MAGIC_NUMBER_MAJOR #define MODULE_MAGIC_NUMBER_MAJOR 20020903 #endif -#define MODULE_MAGIC_NUMBER_MINOR 8 /* 0...n */ +#define MODULE_MAGIC_NUMBER_MINOR 9 /* 0...n */ /** * Determine if the server's current MODULE_MAGIC_NUMBER is at least a Index: server/main.c === RCS file: /home/cvs/httpd-2.0/server/main.c,v retrieving revision 1.140.2.8 diff -u -r1.140.2.8 main.c --- server/main.c 30 Mar 2004 20:53:06 - 1.140.2.8 +++ server/main.c 6 Jul 2004 17:38:25 - @@ -393,13 +393,13 @@ } #endif -ap_setup_prelinked_modules(process); - apr_pool_create(pcommands, pglobal); apr_pool_tag(pcommands, pcommands); ap_server_pre_read_config = apr_array_make(pcommands, 1, sizeof(char *)); ap_server_post_read_config = apr_array_make(pcommands, 1, sizeof(char *)); ap_server_config_defines = apr_array_make(pcommands, 1, sizeof(char *)); + +ap_setup_prelinked_modules(process); ap_run_rewrite_args(process);
Apache-Test module skeletons
hi all... the bug reporting skeleton has become so useful for me (and others) that I have created two new skeletons: http://perl.apache.org/~geoff/Apache-Test-skeleton-mp1.tar.gz http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz these are essentially the same as the bug reporting skeletons but geared toward new module development - a basic handler exists in lib/Apache/Handler.pm, references to bugs have been removed, etc. enjoy. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Which in turn means that every filter, now blissfully unaware of ranges, is forced to generate a full response for each byterange request. In the case of a downloaded ISO (for example), this means a significant amount of data (many hundreds of MB) is being processed by filters on each request. Thus this discussion. while I'm all for reducing server overhead (who isn't :) playing these kind of games with the filter API seems like such a bad idea. what we have now is a modular design that is simple and works - content handlers generate a response, while various filters adjust that response based on interesting criteria. requiring that one know anything about the other breaks that model and has the potential to get us into a hole from which it is difficult to escape. for an example, see a post I made about the (still present) problems with filter_init, which was an attempt to fix a problem that resulted from a similar attempt at short-circuiting existing logic: http://marc.theaimsgroup.com/?l=apache-httpd-devm=107090791508163w=2 in my mind the filter API works best when everyone is blissfully ignorant of eachother so that the net result is that all requests are handled appropriately with a minimum of programmatic effort. sure, it would be nice to be as svelte as possible when serving large files, but the flip side to that is being svelt means that users of your API are more likely to get things wrong or encounter real-world situations you never thought about. just my $0.02. --Geoff
Re: cvs commit: httpd-2.0/modules/aaa mod_auth_digest.c
[EMAIL PROTECTED] wrote: pquerna 2004/07/10 00:47:23 Modified:.Tag: APACHE_2_0_BRANCH CHANGES STATUS modules/aaa Tag: APACHE_2_0_BRANCH mod_auth_digest.c Log: Backport of AuthDigestEnableQueryStringHack Needs a doc update to explain what it does. something like the attached? corrections, tweaks, or other feedback welcome. --Geoff Index: mod_auth_digest.xml === RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_auth_digest.xml,v retrieving revision 1.5.2.8 diff -u -r1.5.2.8 mod_auth_digest.xml --- mod_auth_digest.xml 17 Apr 2004 18:43:37 - 1.5.2.8 +++ mod_auth_digest.xml 12 Jul 2004 14:16:11 - @@ -72,7 +72,9 @@ browsers. As of November 2002, the major browsers that support digest authentication are a href=http://www.opera.com/;Opera/a, a href=http://www.microsoft.com/windows/ie/;MS Internet -Explorer/a (fails when used with a query string), a +Explorer/a (fails when used with a query string - see the +directive module=mod_auth_digestAuthDigestEnableQueryStringHack +/directive option below for a workaround), a href=http://www.w3.org/Amaya/;Amaya/a, a href=http://www.mozilla.org;Mozilla/a and a href=http://channels.netscape.com/ns/browsers/download.jsp; @@ -81,6 +83,36 @@ in controlled environments./p /note /section + +section id=msietitleWorking with MS Internet Explorer/title +pThe Digest authentication implementation in current Internet +Explorer implementations has known issues, namely that codeGET/code +requests with a query string are not RFC compliant. There are a +few ways to work around this issue./p + +p +The first way is to use codePOST/code requests instead of +codeGET/code requests to pass data to your program. This method +is the simplest approach if your application can work with this +limitation. +/p + +pApache also provides a workaround in the +codeAuthDigestEnableQueryStringHack/code environment variable. +If codeAuthDigestEnableQueryStringHack/code is true for the +request, Apache will take steps to work around the MSIE bug and +remove the request URI from the digest comparison. Using this +method would look like similar to the following./p + +exampletitleUsing Digest Authentication with MSIE:/title +BrowserMatch MSIE AuthDigestEnableQueryStringHack=On +/example + +pSee the directive module=mod_setenvifBrowserMatch/directive +directive for more details on conditionally setting environment +variables/p +/section + directivesynopsis nameAuthDigestFile/name
Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Graham Leggett wrote: Geoffrey Young wrote: while I'm all for reducing server overhead (who isn't :) playing these kind of games with the filter API seems like such a bad idea. what we have now is a modular design that is simple and works - content handlers generate a response, while various filters adjust that response based on interesting criteria. requiring that one know anything about the other breaks that model and has the potential to get us into a hole from which it is difficult to escape. Which is a point I made in part of the post that you didn't quote above. ok, sorry :) please take the rest of this as just a friendly discussion - I don't want it to turn into some kind of bickering match, since that's definitely not what I have in mind :) To try and make my point again more clearly: Content is generated in compliance with the HTTP/1.1 specification. This HTTP/1.1 compliant content is then fed through several filters, which potentially alter the data in compliance with the HTTP/1.1 specification. Eventually the filtered content is sent out over the network in compliance with the HTTP/1.1 specification. ok, that isn't the idea I had about output filters at all. my own concept of how this all worked (or should work) is that content handlers are supposed to just generate content. specifically, they should not care at all about RFC compliance - this is why we have a separate header filter, byterange filter, and so on (and why I think ap_set_last_modified foo should be in its own filter ;) everyone else here is much more intimate with how filters came to be, so I'll accept that I was wrong with that assumption, but a number of factors brought me to that conclusion, such as the removal of the ap_set_byterange/ap_each_byterange API, the C-L filter, etc - all of these things make it possible for content handlers to focus on the simple job of generating content, while relying on core features to make the complete response RFC compliant. If the byte range filter is not capable of receiving and intelligently handling a 206 Partial Content from a content handler, then the byte range filter is not compliant with HTTP/1.1, and is therefore broken. clearly. If any other filter is not capable of processing data that has come from a 206 Partial Content response, AND that filter does not either a) remove itself from the filter stack, or b) remove the Range header from the request, then that filter is not compliant with the HTTP/1.1 specification, and is therefore broken. that's true if I'm wrong about the assumption above. but in my mind, the filter API is the most useful if content handlers (and content-altering filters) can remain ignorant of 206 responses and the byterange filter can bat cleanup. Up until now it has been simplistically assumed that ALL content handlers will only ever generate full responses, and so filters and certain content handlers have ignored the Range part of RFC2616. well, I assumed that was by design for the reason mentioned above, namely that the API set/each_byterange API we used to use in 1.3 was replaced with the byterange filter. With the existance of mod_proxy, mod_jk, mod_backhand (etc) taking this shortcut does not make sense. I don't grok what you're trying to say here, unless you mean that it doesn't make sense to take the long way around, with content handlers always producing the full response (as you have indicated elsewhere). Nowhere in the above is any requirement laid down that one module must depend on another one. The only requirement is that content handlers and filters must behave in a way that is compliant with the HTTP/1.1 specification. sure :) I guess where we have different ideas, then, is in who exactly should be responsible for RFC compliance. I had always assumed that there was (or should be) very little that a content handler needed to worry about in this respect, and that it was the job of the core server engine (via various early or late-running filters) to take care of things like HEAD requests, HTTP/0.9 requests/responses, chunked encoding, range requests, etc. anyway, again, I'm not trying to be belligerant - the main reason I'm trying to flesh this all out (even if I'm the only one who doesn't know it already :) is that if the ideas behind the current API design are clear to me then I can help design the Perl interface to the C API so that it matches the real intent here. --Geoff
Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Graham Leggett wrote: Geoffrey Young wrote: please take the rest of this as just a friendly discussion - I don't want it to turn into some kind of bickering match, since that's definitely not what I have in mind :) Cool no problem - it's quite a complex thing this, and I was struggling trying to make it clear what exactly needed to be done and where (and why). :) In this case, we're not just feeding content up the stack, but content _and_ HTTP headers. Filters cannot ignore the headers, otherwise broken behaviour is the result. hmm, yeah I see it now. A classic example is a filter that changes the length of the content (mod_gzip, or mod_include). These filters need to concern themselves with the HTTP Content-Length header, otherwise a response from mod_proxy going up the stack could get shipped to the browser with the wrong Content-Length. ok. but the difference I think I see here between C-L and Range is that if you are a content-length altering filter, you know it - removing C-L is required because you are the one doing the altering. if I understand things right, Range is slightly different. in this case it seems like every filter would need to ask are we byteserving in order to know what to do about Range. In most cases for filters handling the headers is trivial. mod_gzip might strip off a Content-Length header in the hope that a filter might chunk the response down the line. mod_include should (in the most simple case) strip off any Range headers in the request in the hope that the byte range filter handles the range request down the line. but all of a sudden it's not just mod_include, but every similar output filter, right? as in all those that API users will be writing. But in the case of mod_proxy, mod_jk, etc it is quite valid and very desirable for a range request to be passed all the way to the backend, in the hope that the backend sends just that range back to mod_proxy, which in turn sends it up a filter stack that isn't going to fall over because it received a 206 Partial Content response. yes, I can see that. part of the trouble I find myself in here is that I see some kind of creep going on. right now filters need to handle Content-Length under some circumstances, and you are suggesting Range as well. both of these remove part of the filter abstraction and replace that part with (a few) special cases. how many special cases will be required in the end under the current design, and how much complexity does that add for filter writers? so perhaps we need to be dealing less with Range specifically and more with a second-generation filter design that addresses some of these outstanding issues. for instance, perhaps designate some kind of filter class system, whereby content-altering filters register themselves differently than pass-thru-type filters (as I'll call the current proxy issue I guess), etc? that's true if I'm wrong about the assumption above. but in my mind, the filter API is the most useful if content handlers (and content-altering filters) can remain ignorant of 206 responses and the byterange filter can bat cleanup. For simplicity case the above is a noble goal - but one with some significant performance drawbacks in many real world applications. indeed. the trouble is that by streamlining for the performance of some applications you (possibly) limit (or add sufficient complexity to) the ability of other applications to do other, equally important things. at least if the API isn't sufficiently worked out from all angles :) The problem though is not with the content handlers but with the filters - filters must not make the assumption that all content handlers only serve content and not HTTP headers. good point. When a content handler decides that it wants to handle more of the HTTP spec so as to improve performance, it should be free to do so, and should not be stopped from doing so due to limitations in the output filters. yes, that would be a good design goal. In other words if mod_proxy is taught how to pass Range requests to the backend server, the output filter stack should not stop proxy from doing so by removing Range headers unless it is absolutely necessary. ok, thanks for taking the time to explain it all, if only for me :) do you think that the proxy-specific issue can be boiled down to something more generic? at least from here, it looks like what really needs to happen is that certain headers need to have their origin and end-point known so that filters know their place in the process and how to behave when they see them. is that kind of the issue, and can a user-level API be created around it? --Geoff
Re: question concerning with authentication process
Does it have sence or there is another standrd way (without introducing addtional hooks) to use standard authentication modules with access control modifing at runtime? I would look into the Satisfy directive, specifically whether Satisfy any could be used in conjunction with core access directives to get you where you want. something like (untested, but you get the idea ;) Location /foo Satisfy any require valid-user Limit POST allow from all /Limit ... /Location HTH --Geoff
using APR_STATUS_IS_SUCCESS
hi all I was just in garrett's APR talk here at oscon and he was mentioning the APR_STATUS_IS_SUCCESS macro, which I found interesting since httpd only uses it in a few places, opting for a direct comparison to APR_SUCCESS instead. should we move to APR_STATUS_IS_SUCCESS in all places? can someone who groks the nuances of the macro add some insight here? thanks --Geoff
Re: using APR_STATUS_IS_SUCCESS
cross-posted to [EMAIL PROTECTED] Garrett Rooney wrote: Geoffrey Young wrote: hi all I was just in garrett's APR talk here at oscon and he was mentioning the APR_STATUS_IS_SUCCESS macro, which I found interesting since httpd only uses it in a few places, opting for a direct comparison to APR_SUCCESS instead. should we move to APR_STATUS_IS_SUCCESS in all places? can someone who groks the nuances of the macro add some insight here? This is actually something I was wondering about as I wrote the presentation. Neither Apache or Subversion use APR_STATUS_IS_SUCCESS everywhere, but I wonder if we should, since if you look at the definition of the macro there are cases when it's more than just (s) == APR_SUCCESS. just another note, I grep'd the code for rc == APR_SUCCESS and it looks like not even APR is using the macro everywhere... --Geoff
Re: Suggestion: log request when it happens
Dan Wilga wrote: The information contained in the access log can be quite useful in tracking down problems. However, because the log entry is created only after all output has been sent to the client, there is a problem I sometimes run into: If the child process creating the output (like a CGI script) dies unexpectedly with a core dump, there is no access log entry at all. There is usually an error log entry, but that's just the stderr of the problem, which is nowhere near as useful as the actual request info. Opinions? see mod_log_forensic, now in the standard distribution. --Geoff
Re: cvs commit: httpd-2.0/modules/aaa mod_auth_digest.c
hmm, I guess this fell off the collective radar. any comments? otherwise, I guess it's good enough and I'll just commit it to both 2.0 and 2.1. --Geoff Geoffrey Young wrote: [EMAIL PROTECTED] wrote: pquerna 2004/07/10 00:47:23 Modified:.Tag: APACHE_2_0_BRANCH CHANGES STATUS modules/aaa Tag: APACHE_2_0_BRANCH mod_auth_digest.c Log: Backport of AuthDigestEnableQueryStringHack Needs a doc update to explain what it does. something like the attached? corrections, tweaks, or other feedback welcome. --Geoff Index: mod_auth_digest.xml === RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_auth_digest.xml,v retrieving revision 1.5.2.8 diff -u -r1.5.2.8 mod_auth_digest.xml --- mod_auth_digest.xml 17 Apr 2004 18:43:37 - 1.5.2.8 +++ mod_auth_digest.xml 12 Jul 2004 14:16:11 - @@ -72,7 +72,9 @@ browsers. As of November 2002, the major browsers that support digest authentication are a href=http://www.opera.com/;Opera/a, a href=http://www.microsoft.com/windows/ie/;MS Internet -Explorer/a (fails when used with a query string), a +Explorer/a (fails when used with a query string - see the +directive module=mod_auth_digestAuthDigestEnableQueryStringHack +/directive option below for a workaround), a href=http://www.w3.org/Amaya/;Amaya/a, a href=http://www.mozilla.org;Mozilla/a and a href=http://channels.netscape.com/ns/browsers/download.jsp; @@ -81,6 +83,36 @@ in controlled environments./p /note /section + +section id=msietitleWorking with MS Internet Explorer/title +pThe Digest authentication implementation in current Internet +Explorer implementations has known issues, namely that codeGET/code +requests with a query string are not RFC compliant. There are a +few ways to work around this issue./p + +p +The first way is to use codePOST/code requests instead of +codeGET/code requests to pass data to your program. This method +is the simplest approach if your application can work with this +limitation. +/p + +pApache also provides a workaround in the +codeAuthDigestEnableQueryStringHack/code environment variable. +If codeAuthDigestEnableQueryStringHack/code is true for the +request, Apache will take steps to work around the MSIE bug and +remove the request URI from the digest comparison. Using this +method would look like similar to the following./p + +exampletitleUsing Digest Authentication with MSIE:/title +BrowserMatch MSIE AuthDigestEnableQueryStringHack=On +/example + +pSee the directive module=mod_setenvifBrowserMatch/directive +directive for more details on conditionally setting environment +variables/p +/section + directivesynopsis nameAuthDigestFile/name
