Apache thread creation?
I am new to apache modules and was wondering if its possible / allright to create new threads within a module during the module initialization?. I saw some api that allow child process creation and termination, but is there some equivalent for threads as well? Thanks -Arvind Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Re: [PATCH] modify httpd.conf-dist defaults
On Tue, 24 Jun 2003, Glenn wrote: > Might be too late for 1.3.28, but I'd love some comments. > > - Changes defaults to disallow access to files unless explicitly allowed. Although this is, in general, a good idea, I think it would cause many people to be confused. I don't think it is a good idea to change it this late in the 1.3 series (even if it is only the default config file). > - Turns off CGICommandArgs +1, but only if this directive is documented in the manual. I see nothing on it at the moment. (Obviously that's not your fault.) > - On unix httpd-conf-dist, does not allow Emacs autosave or temporary files > to be served (along with not allowing .ht* files). Emacs keeps the same > permission on its temp files, which is a poor choice. (vi restricts > permission to owner on its .swp files.) Also gives a commented out example > that additionally disallows *.bak, *.old, *.so, *.a, and *.o files. I'm fine with the example, but I don't like enabling that by default. It will cause too much confusion for too little gain. (It is an ugly-looking regex and will inevitably hit some people who don't expect it.) Joshua.
[PATCH] ErrorLogsWithVhost for Apache 1.3.28
This adds a directive ErrorLogsWithVhost that extends the error log format
by adding server name and port to entries in the error logs.
Proof of concept. Are there better ways to do this than using a global?
Cheers,
Glenn
diff -ru apache_1.3.27/src/include/http_conf_globals.h
apache_1.3.27.new/src/include/http_conf_globals.h
--- apache_1.3.27/src/include/http_conf_globals.h 2002-09-27 13:40:24.0
-0400
+++ apache_1.3.27.new/src/include/http_conf_globals.h 2003-05-28 01:21:42.0
-0400
@@ -90,6 +90,7 @@
extern API_VAR_EXPORT int ap_daemons_limit;
extern API_VAR_EXPORT int ap_suexec_enabled;
extern API_VAR_EXPORT int ap_listenbacklog;
+extern int ap_error_logs_with_vhost;
#ifdef SO_ACCEPTFILTER
extern int ap_acceptfilter;
#endif
diff -ru apache_1.3.27/src/main/http_core.c apache_1.3.27.new/src/main/http_core.c
--- apache_1.3.27/src/main/http_core.c 2002-09-30 12:35:21.0 -0400
+++ apache_1.3.27.new/src/main/http_core.c 2003-05-28 01:23:07.0 -0400
@@ -2063,6 +2063,18 @@
return NULL;
}
+static const char *set_error_logs_with_vhost(cmd_parms *cmd, void *dummy)
+{
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+if (err != NULL) {
+return err;
+}
+
+ap_error_logs_with_vhost = 1;
+return NULL;
+}
+
+
static const char *set_send_buffer_size(cmd_parms *cmd, void *dummy, char *arg)
{
int s = atoi(arg);
@@ -3308,6 +3320,8 @@
{ "ErrorLog", set_server_string_slot,
(void *)XtOffsetOf (server_rec, error_fname), RSRC_CONF, TAKE1,
"The filename of the error log" },
+{ "ErrorLogsWithVhost", set_error_logs_with_vhost, NULL, RSRC_CONF, NO_ARGS,
+ "Include the virtual host and port, if available, in error log entries" },
{ "PidFile", set_pidfile, NULL, RSRC_CONF, TAKE1,
"A file for logging the server process ID"},
{ "ScoreBoardFile", set_scoreboard, NULL, RSRC_CONF, TAKE1,
diff -ru apache_1.3.27/src/main/http_log.c apache_1.3.27.new/src/main/http_log.c
--- apache_1.3.27/src/main/http_log.c 2002-05-19 00:55:38.0 -0400
+++ apache_1.3.27.new/src/main/http_log.c 2003-05-28 01:24:38.0 -0400
@@ -388,8 +388,15 @@
* quad is the most secure, which is why I'm implementing it
* first. -djg
*/
- len += ap_snprintf(errstr + len, sizeof(errstr) - len,
- "[client %s] ", r->connection->remote_ip);
+ if (ap_error_logs_with_vhost && r->server) {
+ len += ap_snprintf(errstr + len, sizeof(errstr) - len,
+ "[client %s] [%s:%d] ", r->connection->remote_ip,
+ r->server->server_hostname, r->server->port);
+ }
+ else {
+ len += ap_snprintf(errstr + len, sizeof(errstr) - len,
+ "[client %s] ", r->connection->remote_ip);
+ }
}
if (!(level & APLOG_NOERRNO)
&& (save_errno != 0)
diff -ru apache_1.3.27/src/main/http_main.c apache_1.3.27.new/src/main/http_main.c
--- apache_1.3.27/src/main/http_main.c 2002-09-27 13:40:24.0 -0400
+++ apache_1.3.27.new/src/main/http_main.c 2003-05-28 01:22:09.0 -0400
@@ -257,6 +257,7 @@
API_VAR_EXPORT time_t ap_restart_time=0;
API_VAR_EXPORT int ap_suexec_enabled = 0;
API_VAR_EXPORT int ap_listenbacklog=0;
+int ap_error_logs_with_vhost=0;
struct accept_mutex_methods_s {
void (*child_init)(pool *p);
[PATCH] modify httpd.conf-dist defaults
Might be too late for 1.3.28, but I'd love some comments. - Changes defaults to disallow access to files unless explicitly allowed. - Turns off CGICommandArgs I haven't seen any scripts that still use this, but have come across more than a handful of scripts that were vulnerable. And this is the reason that PHP jumps through so many hoops in its CGI mode. It is counterintuitive that environment variables would override command line arguments in PHP, but the default of CGICommandArgs on is the reason. - On unix httpd-conf-dist, does not allow Emacs autosave or temporary files to be served (along with not allowing .ht* files). Emacs keeps the same permission on its temp files, which is a poor choice. (vi restricts permission to owner on its .swp files.) Also gives a commented out example that additionally disallows *.bak, *.old, *.so, *.a, and *.o files. OAM, would someone please give some feedback on the server-side include patches for Apache2 that I posted last month? Thanks. Cheers, Glenn diff -ru apache_1.3.27/conf/highperformance.conf-dist apache_1.3.27.new/conf/highperformance.conf-dist --- apache_1.3.27/conf/highperformance.conf-dist2001-08-29 09:32:07.0 -0400 +++ apache_1.3.27.new/conf/highperformance.conf-dist2003-06-24 14:00:04.0 -0400 @@ -33,14 +33,18 @@ # this if you need logging. #TransferLog logs/access_log +# Never pass query string arguments as command line arguments to CGI. +# (Args are passed on the command line if the query string does not contain +# an '=' and CGICommandArgs on, the default if omitted for backwards compat) +CGICommandArgs off + # Disable symlink protection and htaccess files, they chew far too much. AllowOverride none Options FollowSymLinks -# If this was a real internet server you'd probably want to -# uncomment these: -#order deny,allow -#deny from all +order deny,allow +deny from all +# you'll need to "allow" access to files you want to serve. see below # If this was a real internet server you'd probably want to uncomment this: diff -ru apache_1.3.27/conf/httpd.conf-dist apache_1.3.27.new/conf/httpd.conf-dist --- apache_1.3.27/conf/httpd.conf-dist 2002-09-04 00:39:41.0 -0400 +++ apache_1.3.27.new/conf/httpd.conf-dist 2003-06-24 14:16:31.0 -0400 @@ -289,6 +289,7 @@ Options FollowSymLinks AllowOverride None +deny from all # @@ -376,7 +377,8 @@ # Also, folks tend to use names such as .htpasswd for password # files, so this will protect those as well. # - +# + Order allow,deny Deny from all Satisfy All @@ -523,6 +525,12 @@ # EBCDICConvertByType Off=InOut */* +# Never pass query string arguments as command line arguments to CGI. +# (Args are passed on the command line if the query string does not contain +# an '=' and CGICommandArgs on, the default if omitted for backwards compat) +CGICommandArgs off + + # # Aliases: Add here as many aliases as you need (with no limit). The format is # Alias fakename realname diff -ru apache_1.3.27/conf/httpd.conf-dist-nw apache_1.3.27.new/conf/httpd.conf-dist-nw --- apache_1.3.27/conf/httpd.conf-dist-nw 2002-09-13 18:02:48.0 -0400 +++ apache_1.3.27.new/conf/httpd.conf-dist-nw 2003-06-24 14:03:58.0 -0400 @@ -249,6 +249,7 @@ Options FollowSymLinks AllowOverride None +deny from all # @@ -469,6 +470,11 @@ # ServerSignature On +# Never pass query string arguments as command line arguments to CGI. +# (Args are passed on the command line if the query string does not contain +# an '=' and CGICommandArgs on, the default if omitted for backwards compat) +CGICommandArgs off + # # Aliases: Add here as many aliases as you need (with no limit). The format is # Alias fakename realname diff -ru apache_1.3.27/conf/httpd.conf-dist-win apache_1.3.27.new/conf/httpd.conf-dist-win --- apache_1.3.27/conf/httpd.conf-dist-win 2002-09-04 00:39:41.0 -0400 +++ apache_1.3.27.new/conf/httpd.conf-dist-win 2003-06-24 14:03:24.0 -0400 @@ -311,6 +311,7 @@ Options FollowSymLinks AllowOverride None +deny from all # @@ -564,6 +565,11 @@ # (Unix behavior) option, and will override this server default option. # +# Never pass query string arguments as command line arguments to CGI. +# (Args are passed on the command line if the query string does not contain +# an '=' and CGICommandArgs on, the default if omitted for backwards compat) +CGICommandArgs off + # # Aliases: Add here as many aliases as you need (with no limit). The format is # Alias fakename realname
Re: "hello world" example module...?
however (I seemed to remember that there was an example module somewhere but couldn't find it yesterday). And it's certainly a lot more to swallow than a "hello world" example. IMO, the more valuable contribution would not be another .c file in the tree somewhere but instead a very minimal "hello world" example documented under http://httpd.apache.org/docs-2.0/developer/, with proper hints on how to compile it (e.g., use apxs instead of libtool on unix-ish platforms), and a reference to mod_example.c for examples of other hooks.
ap_max_requests_per_child isn't part of the API, is it?
Some level of mod_php (presumably recent) won't load with Apache 2 on AIX, and the reason is that the decl of that variable in mpm_common.h isn't formally exported (AP_DECLARE_DATA). PHP should be using ap_mpm_query(), right? See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21046
Re: "hello world" example module...?
Jeff Trawick wrote: Chris Knight wrote: Would there be any interest in including example modules with the Apache source distribution? modules/experimental/mod_example.c Ah, fair enough. I wouldn't have thought of looking in experimental, however (I seemed to remember that there was an example module somewhere but couldn't find it yesterday). And it's certainly a lot more to swallow than a "hello world" example.
Re[2]: [RELEASE CANDIDATE] Apache::Test 1.03-dev
Tuesday, June 24, 2003, 1:51:51 PM, you wrote: JS> Rob Bloodgood <[EMAIL PROTECTED]> writes: JS> [...] >> *** root mode: changing the fs ownership to 'nobody' (99:99) >> /usr/sbin/httpd -X -d /root/.cpan/build/Apache-Test-1.03/t -f >> /root/.cpan/build/Apache-Test-1.03/t/conf/httpd JS> Is the docroot (/root/.cpan/.../t/httpd.conf) inside JS> a directory that "nobody" can read from? Probably JS> not, from the looks of it. JS> Try moving the Apache-Test-1.03 directory to /tmp and JS> see if you have better luck there. Good spot! I changed permissions so 'nobody' could access the .cpan dir, and it immediately worked perfectly. Apache::Test and libapreq-1.2 now installed here! L8r, Rob
Re: "hello world" example module...?
Chris Knight wrote: Would there be any interest in including example modules with the Apache source distribution? modules/experimental/mod_example.c
"hello world" example module...?
Would there be any interest in including example modules with the Apache
source distribution? And/or could a complete example module be included
in the documentation for developers? (Personally I'd prefer it be
included in the source distribution...The web documentation has become
quite out of date in places and it's more likely to be current if it
could be included in the distribution test suite.)
Yesterday, in trying to convey how to implement a module, I developed a
"hello world" example module that has a "handler" hook that responds
with a canned message to all requests. (It demonstrates hooks, and I
have a slightly more complex example showing how to read per-directory
configurations.)
I would have found a barebones example immensely useful and would have
saved me much time and code-grepping.
Anyways, I've attached my "hello world" module. Please
comment/correct/chastise as you see fit, I am by no means an expert. ;^>
/* mod_hello_world.c
* Written by Chris Knight, NASA Ames Research Center
* [EMAIL PROTECTED]
*
* Build using:
* $APACHE_HOME/build/libtool gcc -c -I$APACHE_HOME/include mod_hello_world.c
*
* followed by:
* $APACHE_HOME/build/libtool --mode=link $(CC) -o $@ -fPIC $(INCLUDE) \
*hello_world.lo $(LIBS) $(APACHE_CFLAGS) -rpath /usr/lib -avoid-version
*/
#include "httpd.h"
#include "http_core.h"
#include "http_config.h"
#include "ap_config.h"
#include "http_log.h"
// Forward declaration of the module, see the bottom of this document for
// details.
module AP_MODULE_DECLARE_DATA hello_world_module;
// A struct to hold this module's configuration parameters.
typedef struct conf {
apr_pool_t *p;
char *message;
} conf;
/**
* Instantiate this module's configuration structure.
* This function is called by Apache for each configuration section and is
* passed by Apache to other module functions.
* @param p The memory pool to be used by this module.
* @param d The directory/location for this section?
* @return The configuration block's pointer.
*/
static void *create_conf(apr_pool_t *p, char *d) {
conf *c = apr_pcalloc(p, sizeof(conf));
c->p = p;
c->message = NULL;
return c;
}
/**
* Set the message in this module's configuration. This is called when
* the HelloWorldMsg directive is encountered in a configuration section.
* @param cmd The directive parameters ???
* @param config The section's configuration
* @param arg1 The message.
* @return The error message if there is an error with this directive.
*/
static const char *set_message(cmd_parms *cmd, void *config, const char *arg1) {
conf *c = (conf *)config;
c->message = (char *)apr_pstrdup(c->p, arg1);
return NULL;
}
/**
* Provide the response to the request.
* @param r The request record. (Containing all of the details of the request.)
* @return Flag indicating successful handling of the request.
*/
int handle(request_rec *r) {
conf *conf = ap_get_module_config(r->per_dir_config, &hello_world_module);
// if there is no message declared for this URI (no matching ,
// , etc) then let another hook handle the request.
if (conf == NULL || conf->message == NULL) return DECLINED;
// otherwise, send our message to the client
ap_rprintf(r, conf->message);
// and tell Apache that we've handled the request
return OK;
}
/**
* Connect hook functions to Apache so that Apache will call them at the
* appropriate time.
* @param p The memory pool to use.
*/
static void register_hooks(apr_pool_t *p) {
// The handler hooks are used to provide the response's contents for a
// successful request.
ap_hook_handler(handle, NULL, NULL, APR_HOOK_MIDDLE);
}
// This list details which configuration directives this module understands.
static const command_rec cmds[] = {
// The HelloWorldMsg directive takes one argument, the message to send.
AP_INIT_TAKE1("HelloWorldMsg", set_message, NULL, OR_AUTHCFG,
"specify the message to send clients"),
// Indicates the end of the list of directives.
{NULL}
};
// This module declaration tells Apache which configuration directives this
// module understands and which methods to call to connect the hook functions.
module AP_MODULE_DECLARE_DATA hello_world_module = {
STANDARD20_MODULE_STUFF, // always need this
create_conf, // called for each configuration section
NULL,// called for nested configuration sections (?)
NULL,// called once per server configuration
NULL,// ?
cmds,// which configuration directives do I handle?
register_hooks // function to be called at bind-time
};
Re: 1.3.28
Looking to tag on Friday. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: mod_cgi and free_proc_chain
Lothar ? wrote: does anyone know how to increase the time apache will wait before sending a SIGKILL to cgi-processes? (Or to change the kill-policy used with subprocesses?) problem background: I'm using BerkeleyDB from my perl-cgi-scripts, but I don't know how to close the database in case of signals in an reliable way. I do this in my signal handler(SIGTERM and SIGPIPE), but occasionally this closing takes longer than 3 seconds and then apache uses SIGKILL to *kill* the child. Have you patched the code to use a longer timeout? Does that resolve the entire problem for you? I believe that, since closing the database involves removing handles from shared memory, the cgi-process is waiting for a exclusive lock on the shared memory region. It would probably be good to verify that theory with a patch to Apache. There is nothing you can do about a SIGKILL, and so the shared memory region is left inconsistent. yessir Since this a load-dependend issue, this time values should be set in the config...but any ideas? IMO adding a new config directive is premature...we don't even know if a longer timeout helps you. Reading the source I saw that free_proc_chain invokes the killing of the subprocesses, and this cleanup is invoked before waiting on a new connection. how can I prevent this cleanup from happening? Then what do we do about cgi subprocess that refuse to respond to any signals (except SIGKILL)? I think the logical first step is for you to try a patch with a longer timeout, then tell us if that helps. Greg
Re: 1.3.28
Jim Jagielski wrote: OK, let's get 1.3.28 out the door. I'd like to hear some feedback on whether there is stuff people want to see in this release. I'd also like some feedback on some testing on the latest HEAD. It is likely that 1.3.28 will be out there for quite awhile, so let's get it out soon, but also get it out right. Going once, going twice. Folks have had a week to chime in... are there any remaining issues standing in the way of 1.3.28? Bill
Re: [PATCH] mod_cache RFC compliance
Thomas,
I'm working on getting a patch in to CVS. The answer to question 1 is
that, depending on how it got added, the various values could be in
either err_headers_out or headers_out. I'm adjusting your patch (plus
the other header references) accordingly. Should be done, tested, and
committed soon.
Thanks for the kickstart on this.
Paul J. Reder
CASTELLE Thomas wrote:
Thanks for looking into this Paul !
Concerning the second question, I totally agree with you. I tested it
and it works. It is obviously more logical...
I hope you will be able to integrate this patch in the next apache
release...
Thanks again,
Thomas.
-Message d'origine-
De : Paul J. Reder [mailto:[EMAIL PROTECTED]
Envoyé : mardi 17 juin 2003 05:21
À : [EMAIL PROTECTED]
Objet : Re: [PATCH] mod_cache RFC compliance
I am reviewing this patch and have a few questions for Thomas or someone
in the know.
The first has to do with Thomas' observation that Cache-Control is to be
found in r->err_headers_out rather than in r->headers_out... I looked into
this and ran into the following piece of code in mod_expires.c
(expires_filter):
/*
* Check to see which output header table we should use;
* mod_cgi loads script fields into r->err_headers_out,
* for instance.
*/
expiry = apr_table_get(r->err_headers_out, "Expires");
if (expiry != NULL) {
t = r->err_headers_out;
}
else {
expiry = apr_table_get(r->headers_out, "Expires");
t = r->headers_out;
}
This code later calls set_expiration_fields which adds Cache-Control
to whichever headers t points to.
Question 1:
Does this imply that the cache code needs to look for ETags, Cache-Control,
etc in both places too? Right now the code all looks in r->headers_out.
Thomas is changing some of them to look in r->err_headers_out instead.
Is there a rule of thumb for determining when to check headers_out vs.
err_headers_out?
The second observation is related to the freshness computation referenced
below. I agree with Thomas that the code as it stands isn't quite right,
but I disagree that negating the logic fixes it. If I understand the
RFC correctly (section 13.2.4), max_age and s-maxage take precedence over
an expires header. This would mean that, as Thomas points out, if an
expires header is more liberal than the max_age value then it currently
passes the freshness test even though it should fail.
Question 2:
Am I correct in my belief that the fix requires seperation of the checks
so that the maxage and s-maxage checks/computations happen first and you
only evaluate freshness using the expires value if there are no max-age or
s-maxage values present? (as in the following code)
if (((smaxage != -1) && (age < (smaxage - minfresh))) ||
((maxage != -1) && (age < (maxage + maxstale - minfresh))) ||
((smaxage == -1) && (maxage == -1) &&
(info->expire != APR_DATE_BAD) &&
(age < (apr_time_sec(info->expire - info->date) + maxstale -
minfresh {
/* it's fresh darlings... */
...
}
In other words, if a value is specified for smaxage or maxage, the
freshness
is determined solely based on those values (without regard to any expires
header). If there are no values specified for either maxage or smaxage then
the freshness is determined based on the expires header (if it exists). Is
that correct?
By the way, mod_disk_cache has a lot of issues. If it isn't saving and
retrieving the headers correctly, its a bug in the disk_cache code that
needs to be fixed. I wouldn't look to mod_disk_cache as an example of
how the caching code should be working. :)
Thanks in advance for any insight that Thomas or anyone else has to offer
on these questions. Given a couple of answers I can have something
committed Tuesday. Thanks for the research and patch Thomas.
CASTELLE Thomas wrote:
> Hello,
>
> In order to accelerate the RFC compliance of mod_cache, I propose these
> two patches which fix two problems :
> - It doesn't handle the Cache-Control directives (max-age, max-stale,
> min-fresh...) properly.
> - It doesn't send a "If-Modified-Since" to avoid that the backend server
> sends every time a 200 response where a 304 would be enough.
>
> Actually, we are waiting for these features to be implemented since
> http-2.0.43 so that we could put Apache in our production environment. I
> am not an Apache developper, so this is just a proposition, but I tested
> it and it seemed to work.
>
>
> The cache_util.c patch deals with the first issue. First, the
> Cache-Control directive seems to be in the r->err_headers_out and not in
> the r->headers_out. Second, the following test seems useless :
>
> if ((-1 < smaxage && age < (smaxage - minfresh)) ||
> (-1 < maxage && age < (maxage + maxstale - minfresh)) ||
> (info->expire != APR_DATE_BAD &&
>age < (apr_time_sec(info->expire - info->date) + maxstale -
> minfresh))) {
Re: headers for an input filter in AP_FTYPE_CONNECTION mode ?
Philipp Reisner wrote: Now since I can do input (request) filtering with mod_ext_filter, I tried to set ftype = AP_FTYPE_CONNECTION and expected to get the headers. If you set ftype to AP_FTYPE_CONNECTION on an output filter, it will get the complete response including headers. On output, the headers are already known by the time we get to a connection filter. On input, the connection filter sees the request data from the client before any parsing has been performed. So my point of respecting the astute user's desire to make an input filter something other than AP_FTYPE_RESOURCE probably has some required checks, like forgoing worrying about content type if there is no r/r->headers_in. btw, itching to get to your latest patch... I have to add that I deployed my input filter on a name based vhost. -- Does anyone know it if does work with an IP based vhost ? I don't know why it would matter.
RE: Module help...
Hey again !! Thanks for getting back in touch. I read through the code you have and I'm not sure it does exactly what I'm aiming for, although it is a great start. The caching section I have seen examples for and I'am sure it wouldn't be too much to get it going. I know it is a lot of extra code how ever to catch certain system events but it is possible. I'm still not sure how I can take a varible lets say [char *vconf] and then vconf will contain a httpd.conf styl variable like: ServerAdmin [EMAIL PROTECTED] DocumentRoot /var/www/htdocs ServerName www.aproxity.com ServerAlias * CustomLog logs/www-access.log combined ErrorLog logs/www-error.log ScriptAlias /cgi-bin/ "/var/www/htdocs/cgi-bin/" AllowOverride None Options None Order allow,deny Allow from all php_admin_value open_basedir /var/www/htdocs And then just merge that variable into the conf as it stands ... Not sure how I can go about getting stuff like back into the server current conf and settings ? I mean also stuff like ServerAlias wouldn't be required as the module I have uses the client host request for the lookup anyways...? But there would be other flags to take in account which are handled by other modules, like rewrite or in the example above the php admin values ?? How can I go about merging these returned results into apache2 ? Perhaps if I knew the answer I can convert it over to 1.3 as well ? Anyone on the mailing list knows anything about this ? Anyways, something to think about ... -Original Message- From: Sebastian Abt [mailto:[EMAIL PROTECTED] Sent: 24 June 2003 11:16 To: [EMAIL PROTECTED] Subject: Re: Module help... Hi, * "kibble" <[EMAIL PROTECTED]> wrote: > That would be great if you could send me or if I can see some of the > code... sorry, I was quit busy last time.. > Let's put our heads together and make a really good module!! :D You can find my module attached. As I saw later, you're writing your module for Apache2. Mine is for Apache 1.x, but maybe we can put code together and can build up a module for Apache 1 and Apache 2 with the same or similar "core"? My module works quite well at this moment. Now I'm trying to implement some kind of caching, but that seems not to be that easy as I thought before ;-) regards, sebastian
headers for an input filter in AP_FTYPE_CONNECTION mode ?
Hi, Now since I can do input (request) filtering with mod_ext_filter, I tried to set ftype = AP_FTYPE_CONNECTION and expected to get the headers. If you set ftype to AP_FTYPE_CONNECTION on an output filter, it will get the complete response including headers. I have to add that I deployed my input filter on a name based vhost. -- Does anyone know it if does work with an IP based vhost ? TIA -Philipp -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austriahttp://www.linbit.com :
RE: [PATCH] mod_cache RFC compliance
Title: RE: [PATCH] mod_cache RFC compliance
Thanks for looking into this Paul !
Concerning the second question, I totally agree with you. I tested it and it works. It is obviously more logical...
I hope you will be able to integrate this patch in the next apache release...
Thanks again,
Thomas.
-Message d'origine-
De : Paul J. Reder [mailto:[EMAIL PROTECTED]]
Envoyé : mardi 17 juin 2003 05:21
À : [EMAIL PROTECTED]
Objet : Re: [PATCH] mod_cache RFC compliance
I am reviewing this patch and have a few questions for Thomas or someone
in the know.
The first has to do with Thomas' observation that Cache-Control is to be
found in r->err_headers_out rather than in r->headers_out... I looked into
this and ran into the following piece of code in mod_expires.c (expires_filter):
/*
* Check to see which output header table we should use;
* mod_cgi loads script fields into r->err_headers_out,
* for instance.
*/
expiry = apr_table_get(r->err_headers_out, "Expires");
if (expiry != NULL) {
t = r->err_headers_out;
}
else {
expiry = apr_table_get(r->headers_out, "Expires");
t = r->headers_out;
}
This code later calls set_expiration_fields which adds Cache-Control
to whichever headers t points to.
Question 1:
Does this imply that the cache code needs to look for ETags, Cache-Control,
etc in both places too? Right now the code all looks in r->headers_out.
Thomas is changing some of them to look in r->err_headers_out instead.
Is there a rule of thumb for determining when to check headers_out vs.
err_headers_out?
The second observation is related to the freshness computation referenced
below. I agree with Thomas that the code as it stands isn't quite right,
but I disagree that negating the logic fixes it. If I understand the
RFC correctly (section 13.2.4), max_age and s-maxage take precedence over
an expires header. This would mean that, as Thomas points out, if an
expires header is more liberal than the max_age value then it currently
passes the freshness test even though it should fail.
Question 2:
Am I correct in my belief that the fix requires seperation of the checks
so that the maxage and s-maxage checks/computations happen first and you
only evaluate freshness using the expires value if there are no max-age or
s-maxage values present? (as in the following code)
if (((smaxage != -1) && (age < (smaxage - minfresh))) ||
((maxage != -1) && (age < (maxage + maxstale - minfresh))) ||
((smaxage == -1) && (maxage == -1) &&
(info->expire != APR_DATE_BAD) &&
(age < (apr_time_sec(info->expire - info->date) + maxstale - minfresh {
/* it's fresh darlings... */
...
}
In other words, if a value is specified for smaxage or maxage, the freshness
is determined solely based on those values (without regard to any expires
header). If there are no values specified for either maxage or smaxage then
the freshness is determined based on the expires header (if it exists). Is
that correct?
By the way, mod_disk_cache has a lot of issues. If it isn't saving and
retrieving the headers correctly, its a bug in the disk_cache code that
needs to be fixed. I wouldn't look to mod_disk_cache as an example of
how the caching code should be working. :)
Thanks in advance for any insight that Thomas or anyone else has to offer
on these questions. Given a couple of answers I can have something
committed Tuesday. Thanks for the research and patch Thomas.
CASTELLE Thomas wrote:
> Hello,
>
> In order to accelerate the RFC compliance of mod_cache, I propose these
> two patches which fix two problems :
> - It doesn't handle the Cache-Control directives (max-age, max-stale,
> min-fresh...) properly.
> - It doesn't send a "If-Modified-Since" to avoid that the backend server
> sends every time a 200 response where a 304 would be enough.
>
> Actually, we are waiting for these features to be implemented since
> http-2.0.43 so that we could put Apache in our production environment. I
> am not an Apache developper, so this is just a proposition, but I tested
> it and it seemed to work.
>
>
> The cache_util.c patch deals with the first issue. First, the
> Cache-Control directive seems to be in the r->err_headers_out and not in
> the r->headers_out. Second, the following test seems useless :
>
> if ((-1 < smaxage && age < (smaxage - minfresh)) ||
> (-1 < maxage && age < (maxage + maxstale - minfresh)) ||
> (info->expire != APR_DATE_BAD &&
> age < (apr_time_sec(info->expire - info->date) + maxstale -
> minfresh))) {
>
> because it is always true, no matter if max-age is set or not.
> Let's take an example (I suppose here s-maxage, max-stale and min-fresh
> not set,
> so smaxage = - 1, maxstale = 0 and minfresh = 0) :
> - with age = 20, maxage = -1 (not set) and expire - date = 30, the
> second test
> is FALSE. The thir
Re: response handlers get all requests
[EMAIL PROTECTED] wrote: > Marc M. Adkins wrote: > >> The ap_hook_handler() call >> does not specify the handler key from the corresponding AddHandler >> configuration directive. As a consequence, the specified handler >> function >> must look at and accept or decline each request. > > > yes, you are right. IMO that sucks, for a number of reasons: > > * the Apache 1.3 core was better about it and only called handlers when > the request type matched a type the handler was interested in, > > * we had to change the module API to accomodate this regression in the > core, and > > * now we have a distributed performance hit in 2.x, because the core is > calling all these modules who don't care about the request which makes > the CPU fetch crap instructions into the i-cache. This won't show up as > a hot spot in a profiler, because it is spread among all the different > handlers and other code which is now taking more frequent i-cache misses. > > ...but I'll shut up because I don't have a patch or a design for one yet. > >> By contrast, output filters only see requests in which they have >> interest. > > > Clearly a better situation. The change in handlers was made for a reason. The problem is, I've forgotten the reason! A survey of all the existing handlers might well reveal it - otoh, the reason might simply be that filtering hooks didn't fit neatly with the new hook API. Which is, of course, fixable, at the cost of some complication. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: input filters with mod_ext_filter [patch]
Am Montag, 23. Juni 2003 19:02 schrieben Sie:
> On Mon, Jun 23, 2003 at 10:26:55AM +0200, Philipp Reisner wrote:
> > Am Montag, 23. Juni 2003 03:56 schrieb Jeff Trawick:
> > > (apologies for missing the right mail reference and nasty quoting...
> > > e-mail problems, and luckily I was browsing the archives on daedalus
> > > during my ISP-imposed silence)
> > >
> > > Philip,
> > >
> > > Thanks for submitting the patch. I hope you will fix minor issues and
> > > resubmit for further review?
> >
> > Hi Jeff,
> >
> > Of course! I am happy that you are willing to help me to get it in.
> >
> > Please find the new version of the patch attached.
> >
> > BTW, Please have a close look to the part where I look at the
> > "Content-Type" header. The old code examien r->content_type. I had to
> > find an other way, one that is also possible for request filtering...
>
> You removed
> -apr_bucket_brigade *bb;
> so the later
> APR_BRIGADE_INSERT_TAIL(bb, b);
> is going to fail, won't it?
>
> Cheers,
> Glenn
>
>
> @@ -658,7 +662,6 @@
> apr_size_t len;
> char buf[4096];
> apr_status_t rv;
> -apr_bucket_brigade *bb;
> apr_bucket *b;
>
> while (1) {
> @@ -675,14 +678,9 @@
> if (rv != APR_SUCCESS) {
> return rv;
> }
> -bb = apr_brigade_create(r->pool, c->bucket_alloc);
> -b = apr_bucket_transient_create(buf, len, c->bucket_alloc);
> +b = apr_bucket_heap_create(buf, len, NULL, c->bucket_alloc);
> APR_BRIGADE_INSERT_TAIL(bb, b);
> -if ((rv = ap_pass_brigade(f->next, bb)) != APR_SUCCESS) {
> -ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r,
> - "ap_pass_brigade()");
> -return rv;
> -}
> +return APR_SUCCESS;
> }
> /* we should never get here; if we do, a bogus error message would be
> * the least of our problems
Have a look at the chunk before, there the function gets a new parameter
called "bb".
-Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austriahttp://www.linbit.com :
